ljufa.iz.rs

Leaving Google Photos: Self-Hosted Immich on a Home NAS, Public Through a VPS Tunnel

2026-10-15T00:00:00+00:00

My wife and I had two Google Photos accounts, a NAS full of older photos synced from our phones with Syncthing, and a growing Google One bill. This post is about getting everything into one self-hosted Immich instance: the setup, the import, and the many small traps along the way.

The short version: the hard part is not installing Immich, it is importing years of overlapping photos without creating duplicates.

The Setup

phone (Immich app) ──HTTPS──> VPS: Traefik ──> socat relay
                                                  │
                                       WireGuard 10.13.13.0/24
                                                  │
                         home NAS: WireGuard client + socat relay ──> Immich :2283
                                                  │
                                 /data/PHOTO/SORTED/YYYY/MM  (read-only external library)
                                 /data/PHOTO/IMMICH          (uploads from phones)

NAS (an old, slow box): Immich server, Postgres and Redis in Docker. The existing photo archive (SORTED/YYYY/MM) is mounted read-only and added as an Immich External Library. Phone uploads go to a separate folder, never inside the external library (otherwise every upload gets imported twice).
Workstation (temporary, only for the initial import): the first scan of tens of thousands of photos (thumbnails, metadata, face detection, smart search, transcoding) would take days on the NAS CPU. For that period only, a second immich-server container with IMMICH_WORKERS_INCLUDE=microservices, plus machine learning, runs on my workstation. It connects to the NAS database and Redis and mounts the same NFS paths at the same absolute paths, because the database stores absolute paths. Once the backlog is done, it is switched off and the NAS handles the trickle of new phone uploads on its own.
VPS: Traefik terminates TLS for the public photos hostname and relays the traffic through a WireGuard tunnel to the NAS.

Why a tunnel instead of port forwarding

The NAS dials out to the VPS and keeps the tunnel open (PersistentKeepalive). Nothing at home listens on the internet, the router has no forwarded ports, and it works behind CGNAT.

Both ends use linuxserver/wireguard, and each published service is just a tiny socat relay that shares the WireGuard container's network namespace. On the VPS:

wireguard:
  image: lscr.io/linuxserver/wireguard
  environment:
    - PEERS=nas
    - SERVERURL=vps.example.com
    - ALLOWEDIPS=10.13.13.0/24     # only the tunnel subnet, never 0.0.0.0/0
    - PERSISTENTKEEPALIVE_PEERS=all
  sysctls:
    - net.ipv4.ip_forward=0          # relays end each connection; no routing into either network
  ports:
    - '51820:51820/udp'
  labels:
    - "traefik.http.routers.photo_https.rule=Host(`photos.example.com`)"
    - "traefik.http.services.photo.loadbalancer.server.port=2283"

photo:
  image: alpine/socat
  network_mode: service:wireguard
  command: ["TCP-LISTEN:2283,fork,reuseaddr", "TCP:10.13.13.2:2283"]

At home, the mirror image: a WireGuard client with the peer config generated on the VPS, and a relay from the tunnel to the port Immich publishes on the host:

photo:
  image: alpine/socat
  network_mode: service:wireguard
  command: ["TCP-LISTEN:2283,fork,reuseaddr", "TCP:host.docker.internal:2283"]

The relays only move bytes; Immich does its own authentication. On the VPS, Traefik adds rate limits: 10 requests per minute per IP on /api/auth/login (Immich has no login lockout of its own), and a loose per-IP limit on the whole site.

Two lessons from running this:

Restart the whole stack, never just wireguard. The relays share its network namespace. Restart only the WireGuard container and the relays stay attached to the old, dead namespace: the tunnel is up, but every request ends in a 502.
If the NAS runs a VPN client, the WireGuard packets to the VPS need a policy routing rule to bypass it.

Accounts: Decide Before You Import

Immich's duplicate detection works per user. The same photo in two accounts is stored twice and nobody warns you. This drives everything else:

One "Shared" account owns the external library (the family archive on the NAS). Everyone sees it through Partner Sharing or shared albums.
Each person has a personal account for phone backup and private stuff (scanned documents, receipts, the electronics parts I photograph for my DIY projects).

Two things I learned the hard way:

An external library's owner cannot be changed later. I had attached the library to my first (admin) account. Instead of recreating the library, which would have meant new asset IDs, lost albums, lost face names and days of reprocessing, I simply renamed that account to "Shared" and created a new personal admin account.
Logging the phone app into a different account re-uploads the whole camera roll. After switching my phone to the personal account, I removed the old copies from the Shared account by comparing Immich's SHA-1 checksums between the two accounts (more on that below).

Getting the Data Out: Google Takeout

Takeout gives you a pile of independent zip files (not a split archive), 2 to 10 GB each:

for f in ~/Downloads/takeout*.zip; do
  echo "$f"
  unzip -o -q "$f" -d . || echo "FAILED: $f" >> unpack_failures.log
done

Check the numbering first. One of our exports was missing two parts out of 96 and nobody noticed for a while.

What is inside:

Takeout/Google Photos/Photos from 2019/ and so on: the actual library, one folder per year.
One folder per album. These contain copies of photos from the year folders, not different photos.
*.supplemental-metadata.json next to every file: capture time (UTC), GPS, description. Google often does not write this back into the image's EXIF.
*-edited.jpg: Google's edited version next to the original.
.MP files: the video half of Pixel motion photos.
Trash/, Archive/ and a lot of Google-generated "memories" albums ("Friday afternoon in Berlin", "5 years ago").

Folder names follow the account language. My wife's account is in Serbian, so it was Google слике/Слике из 2019./ with Отпад instead of Trash and -измењено instead of -edited. Any script that hard-codes the English names silently does the wrong thing.

Why I Did Not Just Run immich-go

immich-go is the standard tool for importing Takeout into Immich, and it is good. I ran it with --dry-run on one small album first, and that saved me:

For a month whose photos were all already on the NAS, it wanted to upload 336 of 402 as new and to "upgrade" the other 66.
Comparing by hand showed why: her Google library was in "Storage saver" quality, so the Takeout copies were 1.2 MB recompressions of 6 MB originals. Different bytes, so Immich's checksum dedup cannot match them, and immich-go's name+date matching failed on details like DSC_0308.JPG versus DSC_0308.jpg.
The "upgrade" would have replaced the NAS originals in Immich with Google's smaller copies.

Always dry-run on a small sample that you know overlaps with what is already on the server. A sample of only new photos (my first test) looks perfect and proves nothing.

Matching Locally: Metadata First, Then Image Content

So I wrote a small matcher that runs locally. No photos leave the network. The slow part is reading metadata over NFS (about an hour for 52,000 files on the NAS, ten minutes for a local Takeout); the matching itself takes minutes.

Scan both sides once into JSON lines: EXIF DateTimeOriginal, camera model, dimensions, size; for videos ffprobe creation time and duration; for Takeout files the time from Google's JSON sidecar.
Same capture time (to the second) + same file name (case-insensitive, ignoring -edited and (1) suffixes): already there.
Same capture time but different name, or no EXIF at all: compare the actual pixels with a perceptual hash.
Videos: recording time ± 2 s and duration ± 1 s.
Everything else is new.

A perceptual hash is a 64-bit fingerprint of what an image looks like. It survives recompression and resizing, which is exactly what Google's Storage saver does:

from PIL import Image, ImageOps
import imagehash, pillow_heif

pillow_heif.register_heif_opener()

def phash(path):
    with Image.open(path) as im:
        im.draft("RGB", (256, 256))          # JPEG: decode at 1/8 size, much faster over NFS
        im = ImageOps.exif_transpose(im).convert("RGB")
        return imagehash.phash(im)

same = phash(google_copy) - phash(nas_original) <= 10   # Hamming distance of 64 bits

Only the uncertain cases get hashed, and only against candidates with a nearby capture time. Of about 5,900 content matches in my wife's library, 5,641 had distance 0, and only 16 were near the threshold.

Sanity checks that caught real problems:

About 1,100 "new" DSC_* photos had a same-named file on the NAS. Spot checks showed different photos: the camera's counter had wrapped around. Name alone is not identity.
A camera with a dead clock produced a batch of photos and videos dated 1980.

The Results

	My wife's Takeout	My Takeout
Unique assets (album copies collapsed, trash excluded)	25,813	45,061
Already on the NAS	~14,900	~42,400
Really new	~10,500	~2,500

Before copying, I also filtered out things that do not belong in a family archive: FB_IMG_* (images saved from Facebook), screenshots, WhatsApp/Viber/Messenger images, and Google's auto-generated animations and collages. I missed some of these in the first pass and had to delete 228 files afterwards, so put the filter in from the start.

Copying Into the Archive, and an NFS Surprise

New files go into SORTED/YYYY/MM/ like the rest of the archive, named after the original, with the file time set to the capture time (Immich falls back to it for files without EXIF).

Then the timeline showed hundreds of photos dated today. Every copied file had the copy time, even though the script had called os.utime() and a check right afterwards showed the correct date. The NFS client had cached the attributes; when the dirty data was flushed to the server later, the server stamped its own modification time over mine.

The fix: flush before setting the time, re-apply at the end, and verify through a second mount of the same export so the client cache cannot lie to you:

shutil.copyfile(src, tmp)
fd = os.open(tmp, os.O_RDONLY); os.fsync(fd); os.close(fd)   # push the data to the server first
os.utime(tmp, (capture_time, capture_time))
os.rename(tmp, dst)
# ... after all files: wait a minute, re-check via the other mount point, fix what is still wrong

Even with the fsync, a later batch still had 332 of 351 copies overwritten, so the final verify-and-reapply pass is not optional. Moves within the same export (rename) are not affected: they never touch the file's data.

Recreating Albums

Copying files into an external library loses Google's albums. I recreated the meaningful ones (people, trips, events) through the Immich API and skipped the "memories" noise. For each album, every member is either a newly copied file or the NAS original it was matched to, so I can look up its Immich asset ID by path:

api("POST", "/albums", {"albumName": name, "assetIds": ids})
api("PUT", "/assets", {"ids": favourite_ids, "isFavorite": True})   # Google's favourites

Personal Photos Out of the Shared Library

My Takeout had albums of scanned documents, contracts and electronics parts. They had also reached the NAS through Syncthing years ago, so the whole family could see them. I:

uploaded them to my personal account through the API (POST /api/assets), using the NAS originals where they existed, because they are better than Google's copies,
checked that every one of them arrived (status created, then SHA-1 against Immich's stored checksums),
only then moved them out of SORTED into a holding folder, and deleted that folder after another verification.

Switching the Phone to the Personal Account

Immich stores a SHA-1 checksum of every asset. The phone uploads byte-identical files, so deduplicating across accounts is exact, not a guess:

shared   = [a for a in all_assets(SHARED_KEY) if not a.get("libraryId")]   # uploads only, not the NAS library
personal = {a["checksum"] for a in all_assets(PERSONAL_KEY)}
dups = [a["id"] for a in shared if a["checksum"] in personal]
api(SHARED_KEY, "DELETE", "/assets", {"ids": dups, "force": False})        # to trash, restorable

1,406 of 1,453 old uploads matched and went to the trash. The other 47 stayed.

Cleaning Up Old Folders on the NAS

The NAS also had a separate VIDEO/ tree and an UPLOAD/ folder with Syncthing targets from several old phones. The same matcher, pointed at those folders, found 1,822 files missing from the archive and about 3,000 duplicates (including 1,118 copies of each other). Two warnings:

Do not move files out of an active Syncthing folder. With a send-receive share, a move is a delete, and Syncthing deletes the photo on the phone too. I copied from those folders instead, and stopped the shares before deleting anything.
Before deleting a folder, check that every file in it has a safe counterpart, following duplicate chains to the end. "A copy of a copy" is only safe if the last copy survives.

Deleting From Google Photos

When you select photos on photos.google.com and press delete, Google asks:

Remove from your Google Account, devices with backup turned on, and places shared within Google Photos?

That middle part is the trap: every phone with Google Photos backup turned on deletes those photos from its gallery too. Turn off backup in the Google Photos app (or uninstall it) on every device first.

There is no "delete everything" button. Select the first photo, scroll far down, Shift+click the last one, delete, repeat. Then empty the trash, or Google keeps everything for 60 more days. Also check Archive and Locked Folder, which are not in the main view.

Keep the unpacked Takeout (or the zips) on a backup disk. Everything you filtered out (screenshots, edits, chat images) exists only there.

Lessons Learned

Design the accounts before importing. Dedup is per user, and a library's owner is fixed.
Dry-run every bulk operation on a small sample that overlaps with existing data.
Google's Storage saver means byte-level dedup cannot work. Match by capture time and name, and confirm with a perceptual hash.
Never trust file times on NFS right after writing. Verify through a second mount.
Keep a record of every copy, move and upload (one JSON line per file). It made every later step (albums, cleanup, the final deletion) a lookup instead of guesswork.
Move instead of delete, verify, then delete. Anything you cannot undo, do last.
Immich's job queues are heavy on a small NAS during the initial import: temporarily offloading the microservices to a faster machine works well, but the NAS still briefly fell over when a library scan, 1,500 metadata jobs and a storage migration ran at once. Lower the job concurrency during big imports.

The result: one family archive on the NAS, a personal library per person, phones backing up to Immich, everything reachable from anywhere with no open port at home, and no more Google One subscription.

Fix Severe SSD Write Speed Degradation on Pop!_OS / Linux (LUKS + LVM)

2026-02-17T00:00:00+00:00

The Symptom

Your Linux desktop (especially Pop!_OS or Ubuntu) randomly freezes under heavy write loads. Browsers lock up when downloading files, IDEs (like IntelliJ or VS Code) stutter during indexing, and compiling code brings the system to a halt.

Before You Start: Benchmark Your Drive

Before applying this fix, test your raw SSD write speed. We will write a 5GB file using direct I/O to bypass your RAM cache and measure the actual silicon speed.

Run this command in your terminal:

dd if=/dev/zero of=test_write_file bs=1G count=5 oflag=direct

(Don't forget to delete the test file afterward: rm test_write_file)

The Reality Check: If you are using a modern QLC-based SSD (like the Samsung 870 QVO) rated for 500 MB/s, you might see this benchmark return something like 30 MB/s (slower than a 15-year-old mechanical hard drive).

The Root Cause

If you enabled Full Disk Encryption during your OS installation, your drive is likely suffering from a blocked TRIM command.

QLC drives rely on a fast "SLC Cache" (using empty storage space) to achieve high speeds. When you delete a file on Linux, the OS normally sends a TRIM command to tell the SSD it can reuse those blocks for its fast cache.

However, Linux blocks TRIM commands through LUKS encryption by default for security reasons. Because the SSD never receives the TRIM command, the hardware thinks the drive is 100% full of undeleted data. The fast cache shrinks to zero, and the drive is forced to write directly to the slow QLC memory, causing your entire OS to freeze while it waits for the disk.

How to Diagnose

Run this commands to confirm you are affected:

1. Check if TRIM is blocked:

sudo fstrim -v /

If this returns fstrim: /: the discard operation is not supported, proceed to step 2.

2. Check if your root drive is encrypted:

lsblk -f

Look at your root partition (/). If it is nested under a crypto_LUKS tree, this fix applies to you.

The Fix

To fix this, we need to explicitly allow the discard (TRIM) command to pass through the encryption layer. (Note: This has a minor security tradeoff, as an attacker with physical access to your drive could theoretically determine exactly how much free space you have based on empty blocks. For 99% of desktop users, this is worth the massive performance gain).

Step 1: Edit your Crypttab Open the cryptography table configuration file:

sudo nano /etc/crypttab

Find the line corresponding to your encrypted drive (usually named cryptdata). Add ,discard to the end of the options string.

It should look something like this:

cryptdata UUID=xxxx-xxxx-xxxx none luks,discard

(Save and exit: Ctrl+O, Enter, Ctrl+X)

Step 2: Rebuild the Boot Image Because the drive is unlocked during boot, you must update the initial ramdisk so the system knows about the new rule before the OS loads:

sudo update-initramfs -u -k all

Step 3: Reboot You must restart your computer for the encryption layer to reload with the new rules.

Step 4: Dump the Garbage Once you log back in, manually trigger the TRIM command to clear out months/years of dead data:

sudo fstrim -v /

Note: This might take a few minutes. It should report back that it trimmed many Gigabytes of data! In my case it was ~570Gb!

Step 5: Enable Automatic Weekly Maintenance Ensure the background systemd timer is enabled so Linux does this for you automatically in the future:

sudo systemctl enable --now fstrim.timer

The Result

Run the dd benchmark from the beginning of this guide one more time:

dd if=/dev/zero of=test_write_file bs=1G count=5 oflag=direct

On a 1TB Samsung 870 QVO, this fix took write speeds from 30.9 MB/s back up to 498 MB/s (a 1,600% increase), completely eliminating all system stuttering and lockups.