Troubleshooting Immich When Mounted Drive Paths Change After Reboot

Immich is often trusted with a large and valuable photo library, so a storage path that changes after a reboot can quickly become more than a minor inconvenience. If your mounted drive appears under a different path, Immich may fail to start, show missing assets, stop processing uploads, or display broken thumbnails. The issue is usually not Immich itself, but the way the operating system mounts disks and how Docker or Docker Compose references those paths.

TLDR: If Immich stops seeing photos after a reboot, first confirm whether the host mount path changed. Mount drives by UUID or another stable identifier instead of relying on names such as /dev/sdb1. Then update your Docker Compose bind mounts, Immich external library paths, and permissions so they match the permanent location. Finally, restart Immich only after confirming the drive is mounted correctly.

Why mounted drive paths change after reboot

Linux does not guarantee that device names such as /dev/sdb, /dev/sdc, or /dev/nvme1n1 will remain the same after every boot. These names are assigned dynamically depending on the order in which devices are detected. A USB drive, SATA disk, NAS mount, or external enclosure may appear under one name today and another name tomorrow.

This becomes a problem when Immich is configured to use a path that depends on that shifting device name, or when a desktop environment automatically mounts a drive under a user-specific path such as /media/user/DriveName. After reboot, the drive may mount as /media/user/DriveName1, fail to mount at all, or mount only after login. For a server application such as Immich, this is unreliable.

Immich usually runs in containers, so there are two paths to consider: the host path and the container path. The host path is where the drive is mounted on the server. The container path is what Immich sees inside Docker. If the host path changes, Docker may still start, but it may mount an empty directory instead of the real photo storage location.

Common signs that the path has changed

When the mounted drive path changes, the symptoms can look like application corruption, but they are usually storage related. Watch for the following signs:

• Missing assets: Photos and videos appear unavailable, broken, or fail to load.
• Upload failures: New uploads fail because Immich cannot write to the expected storage directory.
• Empty external libraries: Library scans complete but find no files.
• Container errors: Logs mention missing directories, permission denied errors, or unexpected empty folders.
• Duplicate mount folders: Paths such as /media/user/photos and /media/user/photos1 both exist.

A particularly dangerous situation occurs when Docker creates the missing host directory automatically. For example, if your Compose file references /mnt/photos, but the drive is not actually mounted there, Docker may bind an empty local folder into the container. Immich then writes new data into the wrong location, creating confusion and possible data separation.

Step 1: Confirm the current mount location

Begin by checking where the operating system mounted the drive. Run:

lsblk -f

This command shows block devices, filesystems, labels, UUIDs, and mount points. Look for the disk or partition that contains your Immich library. Also run:

findmnt

or filter for a suspected path:

findmnt /mnt/photos

If findmnt returns nothing for the path Immich expects, the drive is not mounted there. If lsblk shows the drive mounted somewhere else, you have found the cause.

Next, inspect your Docker Compose file, usually named docker-compose.yml or compose.yml. Look for volume mappings under services such as immich-server, immich-microservices, or any current Immich service names in your deployment. A typical bind mount may look like this:

volumes:
  - /mnt/photos/immich:/usr/src/app/upload

The left side is the host path. That path must exist and must be the actual mounted drive location before the container starts.

Step 2: Choose a permanent mount point

The best practice is to mount storage at a stable, deliberate location such as:

• /mnt/immich
• /mnt/photos
• /srv/immich/library

Avoid relying on automatic desktop mounts under /media, especially for a server. Automatic mounting may depend on a user session, graphical login, or removable-drive behavior that is not appropriate for a service expected to start at boot.

Create the mount point if it does not already exist:

sudo mkdir -p /mnt/immich

Then identify the drive UUID:

sudo blkid

You will see output similar to this:

/dev/sdb1: UUID="1234abcd-5678-ef00-9999-abcdef123456" TYPE="ext4" LABEL="photos"

The UUID is the stable identifier you should use. Unlike /dev/sdb1, the UUID does not change when devices are detected in a different order.

Step 3: Use fstab for reliable mounting

To mount the drive consistently at boot, add an entry to /etc/fstab. Before editing this file, make a backup:

sudo cp /etc/fstab /etc/fstab.backup

Open it with a text editor:

sudo nano /etc/fstab

For an ext4 filesystem, an entry might look like this:

UUID=1234abcd-5678-ef00-9999-abcdef123456 /mnt/immich ext4 defaults,nofail 0 2

For an NTFS drive, it may look more like:

UUID=1234ABCD5678EF00 /mnt/immich ntfs3 defaults,nofail,uid=1000,gid=1000,umask=002 0 0

The exact options depend on your filesystem and user IDs. The nofail option can prevent the entire boot from failing if the disk is temporarily unavailable, but it does not solve application timing by itself. Immich should still only start after the mount is present.

After editing fstab, test it safely:

sudo mount -a

If there is no error, verify the mount:

findmnt /mnt/immich

Do not reboot until mount -a succeeds. A syntax error in fstab can cause boot problems, so treat this step carefully.

Step 4: Update Docker Compose paths

Once the drive has a permanent mount point, update your Immich Compose file to use that location. For example:

volumes:
  - /mnt/immich/upload:/usr/src/app/upload

If you use external libraries, you may also have mappings such as:

volumes:
  - /mnt/immich/external:/mnt/external:ro

Be precise. The path before the colon is on the host. The path after the colon is inside the container. If you change the host path but leave Immich configured to scan an old internal path, the problem will continue.

After editing the Compose file, restart the stack:

docker compose down
docker compose up -d

Then inspect logs:

docker compose logs -f immich-server

If your deployment uses different service names, adjust the command accordingly. Look for errors involving missing files, denied permissions, or failed directory access.

Step 5: Check permissions and ownership

A path can be correct and still fail if Immich cannot read or write to it. Check ownership and permissions on the host:

ls -lah /mnt/immich

If the upload directory must be writable by the container, ensure the user running inside the container has appropriate rights. Many Docker setups rely on specific user and group IDs. If your Compose file defines PUID and PGID, match the host directory ownership to those values.

For example, if the intended user ID and group ID are both 1000:

sudo chown -R 1000:1000 /mnt/immich/upload

Use recursive ownership changes cautiously. Do not run broad commands against the wrong directory. Before using chown -R, confirm that the drive is mounted and that you are not modifying an empty placeholder directory created during a failed mount.

Step 6: Verify Immich external library settings

If the issue involves external libraries rather than the primary upload directory, open the Immich web interface and inspect the external library configuration. Immich scans the path visible inside the container, not the original host path.

For instance, if Compose contains:

- /mnt/immich/archive:/mnt/media/archive:ro

then Immich should reference:

/mnt/media/archive

not:

/mnt/immich/archive

This distinction is a frequent source of confusion. The host path and container path are related, but they are not interchangeable.

Step 7: Prevent Immich from starting before the drive is mounted

Even with fstab configured, Docker may start before a slow external drive, network share, or encrypted volume is ready. If that happens, containers can bind to empty directories. The safest approach is to ensure your storage is mounted before Docker starts or before the Immich stack is launched.

For systemd-managed Docker, advanced users can create a dedicated systemd mount unit or service dependency. For network mounts, use options such as _netdev where appropriate. For local drives, a correctly configured fstab entry is often enough, but USB disks may still need extra attention.

At minimum, after every storage-related change, reboot once and verify:

1. The drive is mounted at the intended path.
2. The expected Immich folders are visible there.
3. Docker containers are using the correct bind mounts.
4. Immich can read existing media and write new uploads.

Step 8: Check for accidental duplicate directories

If Immich has run while the drive was not mounted, you may have an accidental directory at the mount point. For example, /mnt/immich may contain files when the real disk is not mounted. Later, when the disk mounts successfully, those files disappear from view because the mount hides the underlying directory.

To investigate safely, stop Immich first:

docker compose down

Then unmount the drive:

sudo umount /mnt/immich

Now inspect the underlying directory:

ls -lah /mnt/immich

If you find unexpected Immich files there, they may have been written during a failed mount situation. Do not delete them immediately. Compare timestamps, confirm whether they contain real uploads, and back them up before merging or removing anything.

Recommended recovery checklist

Use this checklist when Immich breaks after reboot and you suspect a path problem:

• Stop the stack: Prevent further writes until storage is confirmed.
• Identify the disk: Use lsblk -f and blkid.
• Confirm the mount: Use findmnt on the expected path.
• Fix permanent mounting: Use UUID-based fstab entries.
• Update Compose: Ensure bind mounts reference the permanent host path.
• Check permissions: Verify read and write access for the container user.
• Validate Immich paths: External libraries must use container-visible paths.
• Restart carefully: Bring containers up only after the drive is mounted.
• Review logs: Confirm there are no storage or permission errors.

Final thoughts

Mounted drive path changes are a common cause of Immich failures after reboot, especially on systems using removable drives, desktop auto-mounting, or device names such as /dev/sdb1. The reliable solution is to treat storage as a formal server dependency: mount it at a stable path, reference it consistently in Docker, and verify permissions before restarting the application.

Because Immich manages personal media that may be irreplaceable, avoid quick fixes that you do not fully understand. Confirm the actual mount point, keep backups, and make changes deliberately. Once the mount is stabilized with UUID-based configuration and the Docker paths are aligned, Immich should behave predictably across reboots and continue serving your library without unexpected missing-file errors.