The Power Couple: Immich + Pixel 5 for Home Backup

The Ultimate Homelab Hack: Unlimited Google Photos, Immich, and the 0KB Server Trick

If you run a homelab, you probably know the holy grail of photo backups: The Google Pixel 1-5 Unlimited Backup loophole.

My setup was seemingly perfect. I run Immich via Docker (using Portainer) on a Linux home server to collect all my family's photos. From there, I use Syncthing to push those original, high-resolution photos over to an old Google Pixel 5, which then automatically uploads them to Google Photos for free, unlimited cloud storage.

But a few days ago, my clever setup completely crashed my Immich server. Here is the story of what went wrong, how I rescued a corrupted Linux virtual drive, expanded my storage, and perfected the "0KB Hack" to keep Immich running smoothly.

The Disaster: "Error -74" and the Bad Message

Because my Pixel 5 is handling the actual cloud backup, I don't need my home server hoarding the original, massive multi-megabyte photo files. My server was running on a restricted 20GB virtual drive partition (.img loop device), and it was filling up fast.

To save space, I wrote a simple bash script to shrink all my synced photos to 0 bytes using the truncate command. The idea was simple: delete the heavy file contents to free up space, but keep the empty files on the drive so Immich’s database wouldn’t freak out about missing files.

I ran the script. Suddenly, my Immich container crashed. The logs spit out this terrifying line:

ERROR [Microservices:StorageService] Failed to read (/usr/src/app/upload/encoded-video/.immich): Error: Unknown system error -74

When I went to the terminal to check the folder, Linux hit me with: Bad message.

What Happened?

"Bad message" is Linux-speak for EBADMSG (Error -74), which means filesystem corruption.

My aggressive cleanup script had blindly shrunk everything in the Immich data folder to 0KB—including the hidden .immich system integrity files that Immich relies on to ensure the storage drive is actually mounted. When Immich couldn't read its own safety files, it panicked and shut down to prevent data loss. Worse, because my 20GB drive was completely maxed out right before I ran the script, the filesystem index itself got corrupted.

The Rescue: Fixing the Filesystem and Upgrading to 100GB

My Immich data was sitting on a loop device (a virtual hard drive file named immich_disk.img mounted as a physical drive). Before I could start Immich again, I had to fix the corruption and give the server some breathing room.

Here is the exact terminal sequence I used to repair the broken filesystem and expand my server from 20GB to 100GB:

# 1. Unmount the corrupted virtual drive
sudo umount /home/chinadmin/immich-data

# 2. Repair the filesystem directly on the image file
sudo e2fsck -D -y /home/chinadmin/immich_disk.img

# 3. Expand the raw file size to 100GB
sudo truncate -s 100G /home/chinadmin/immich_disk.img

# 4. Tell the ext4 filesystem to grow and use the new space
sudo resize2fs /home/chinadmin/immich_disk.img

# 5. Remount the drive
sudo mount /home/chinadmin/immich-data

# 6. Delete the broken 0-byte hidden files so Immich can recreate them
find /home/chinadmin/immich-data -type f -name ".immich" -delete

I went back to Portainer, started the Immich stack, and boom—it immediately grabbed an IP, passed its integrity checks, and came back online with 99GB of free space.

Why Not Just Delete Files via Syncthing?

You might be wondering: If the photos are safely backed up to Google Photos, why not just set Syncthing to two-way sync? When the Pixel deletes the photo to free up space, it will delete it from the server automatically!

Do not do this. It will break Immich.

Immich is built on a complex PostgreSQL database. If Syncthing silently deletes a photo straight off your hard drive, Immich’s database has no idea it is gone. It will constantly throw "File Not Found" errors, create ghost entries in your timeline, and eventually destabilize your app. Immich expects you to delete photos via its own UI, not behind its back.

The Perfected "0KB Hack" Script

This brings us back to the truncate hack. Shrinking the files to 0KB is brilliant because the file technically still exists on the hard drive. Immich's database stays perfectly happy, Syncthing doesn't panic, and Immich's UI continues to load your photos beautifully using the separate thumbs folder (which holds the compressed thumbnails).

To make sure my script never deletes Immich's hidden system files again, I modified the find command to specifically exclude any file starting with a dot (! -name ".*").

Here is my final, perfected script:

#!/bin/bash
# TARGET is the main library folder containing all user ID folders
TARGET_DIR="/home/chinadmin/immich-data/library"

echo "Starting ghost cleanup in $TARGET_DIR..."

# This finds all files inside library, EXCLUDING hidden files (like .immich), 
# and shrinks them to 0KB
find "$TARGET_DIR" -type f ! -name ".*" -exec truncate -s 0 {} +

echo "Cleanup complete! All original photos are now 0KB 'ghosts'."
echo "Your disk space is now free for the next batch."

(Note: You must run this script with sudo bash clean_immich.sh so it has the root permissions necessary to modify Docker's files!)

🚨 The Golden Rule of the 0KB Hack: Never run this script while your Pixel is syncing. If you truncate the file before Syncthing finishes pushing it to the phone, your Pixel will upload a blank 0-byte file to Google Photos, and your original memory is gone forever. Let the backup finish completely, then run the script.

Conclusion

Setting up a homelab is all about tinkering, breaking things, and learning how to put them back together better than before. Thanks to a terrifying "Bad message" error, I now have a deeply optimized, 100GB Immich server that happily feeds my Pixel 5 unlimited cloud storage, all while using practically zero disk space for my old photos.

Happy self-hosting!