Best Way to Use a Remounted External Drive with Immich Server

If you run Immich Server at home, an external drive can be a practical place to store a large photo and video collection. But when that drive is remounted, renamed, or moved to a different mount point, Immich may suddenly appear to “lose” files, fail scans, or create confusing duplicates. The best approach is to make the drive’s path predictable, expose it consistently to Immich, and choose the right Immich storage strategy for your use case.

TLDR: Mount your external drive to a stable, permanent path using its UUID, then bind that path into the Immich containers with a consistent container path. For existing photo collections, use an External Library rather than moving everything into Immich’s upload directory. Make sure permissions, backups, and scan settings are correct before you let Immich index the entire drive.

Why Remounted Drives Cause Problems

External drives are convenient, but they are also easy to accidentally mount in different places. One day the drive might appear at /media/alex/Photos, and after a reboot it might become /media/alex/Photos1. If you are using Docker, the host path might also change while the path inside the container remains the same, or vice versa.

Immich does not simply think in terms of “a drive.” It sees file paths. If those paths change, Immich may no longer be able to find images it previously indexed. This is especially important for external libraries, where Immich references files that live outside the normal upload storage location.

The goal is to remove uncertainty. Your external drive should always mount at the same host location, and your Immich containers should always see it at the same internal location.

Step One: Choose a Permanent Mount Point

The first best practice is to avoid relying on desktop auto-mount paths such as /media/username/DriveName. These paths are convenient for casual use, but they are not ideal for a server service that needs to run reliably after reboots.

Instead, create a dedicated mount point such as:

• /mnt/immich-photos
• /srv/photos
• /data/media/photos

A path under /mnt, /srv, or /data is usually clearer and more server-friendly than a user-specific auto-mount location. For example:

sudo mkdir -p /mnt/immich-photos

Then identify the drive’s UUID:

lsblk -f

Using the UUID is important because device names such as /dev/sdb1 can change depending on boot order, USB ports, or other attached drives. A UUID points to the specific filesystem, making it much more reliable.

Step Two: Mount by UUID Using fstab

On many Linux systems, you can configure persistent mounts in /etc/fstab. A typical entry may look like this:

UUID=xxxx-xxxx /mnt/immich-photos ext4 defaults,nofail 0 2

The exact filesystem type may be ext4, xfs, btrfs, exfat, or ntfs, depending on how the drive is formatted. For a Linux-based server, ext4 is often the simplest and most reliable choice. If the drive must also be read by Windows or macOS, you may choose another filesystem, but you should be aware that permissions and performance can be more complicated.

The nofail option is useful because it allows the system to boot even if the external drive is unplugged. However, this also means Immich might start while the drive is missing. For a more polished setup, you can configure Docker or systemd so Immich starts only after the mount is available.

After editing fstab, test it with:

sudo mount -a

If there are no errors, check the result:

df -h
ls -la /mnt/immich-photos

Step Three: Decide Between Upload Storage and External Library

Immich has two common ways to interact with files on storage:

• Upload library: Immich manages files that are uploaded through the app, web interface, or CLI.
• External library: Immich indexes existing files in a location you specify, without moving them into Immich’s normal upload structure.

If your external drive already contains years of organized photos, the External Library feature is usually the best option. It allows Immich to scan your existing folder structure while leaving the original files in place. This is ideal if you already have folders like:

• Photos/2018/Vacation
• Photos/2020/Family
• Photos/Camera Imports/Sony

If, however, you want Immich to fully manage new uploads, then your Immich upload storage itself can live on the external drive. In that case, the entire Immich upload location should be placed on the mounted drive from the beginning, rather than moved casually later.

Important: Do not point an external library at Immich’s internal upload directory unless you know exactly what you are doing. Mixing these concepts can cause confusion, duplicate indexing, or unexpected behavior.

Step Four: Bind Mount the Drive into Docker

Most Immich installations run through Docker Compose. Docker containers cannot automatically see every folder on the host. You must explicitly bind mount the host directory into the container.

For an external library, you might add something like this to the Immich server service:

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

This means:

• /mnt/immich-photos is the path on the host machine.
• /external/photos is the path Immich sees inside the container.
• ro makes it read-only, which is safer for existing photo archives.

Using ro is strongly recommended for external libraries if you do not want Immich or a misconfigured process to alter your original files. Immich can still index, thumbnail, and display the media, but the source files remain protected.

If you are using the external drive for Immich upload storage, the volume might instead be writable. For example:

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

Be careful here. If you mount the wrong empty folder over an existing container path, it can look as if your files disappeared. They may not be gone, but Docker may be seeing a different directory than before.

Step Five: Keep the Container Path Stable

Once Immich has indexed an external library, avoid changing the path inside the container. For example, if Immich sees your library as /external/photos, keep it that way.

You may change the host-side physical storage later, but preserve the container-side path whenever possible. This gives you flexibility. You could move from a USB drive to a NAS, update the host mount, and still present the same path to Immich:

/external/photos

That stable internal path is what keeps your Immich configuration clean. It also makes troubleshooting much easier because you always know where Immich expects the files to be.

Step Six: Fix Permissions Before Scanning

Permissions are one of the most common reasons Immich cannot read a remounted external drive. The container user must be able to access the mounted folders and files. On the host, check ownership and permissions:

ls -la /mnt/immich-photos

For Linux filesystems such as ext4, you can set ownership and permissions normally. For example, you might assign the files to a media group and allow read access. For NTFS or exFAT, permissions are often controlled through mount options rather than traditional Linux ownership.

A practical permission model for an external library is:

• The host can read and manage the files.
• The Immich container can read the files.
• Immich does not need write access unless you are using the drive for upload storage.

Before scanning in Immich, test from inside the container if necessary:

docker exec -it immich_server ls -la /external/photos

If the container cannot list the directory, Immich will not be able to scan it either.

Step Seven: Add the External Library in Immich

Once the drive is mounted and visible inside Docker, open the Immich web interface and configure an external library. Use the container path, not the host path. If your Docker bind mount is:

/mnt/immich-photos:/external/photos:ro

then the path you add in Immich should be:

/external/photos

This distinction is critical. Immich runs inside the container, so it does not know or care that the host path is /mnt/immich-photos. It only sees the path you provided inside Docker.

After adding the library, run a scan. For very large collections, start with a smaller subfolder if possible. This lets you confirm that permissions, metadata extraction, thumbnails, and video transcoding work correctly before indexing hundreds of thousands of files.

Avoiding Duplicates and Broken References

When remounting or reorganizing a drive, duplication can become a serious annoyance. If the same files are scanned under a different path, Immich may treat them as new assets, depending on the situation and configuration. This is why stable paths matter so much.

To reduce duplicate risk:

• Do not change library paths casually.
• Do not scan both a parent folder and its child folder as separate libraries.
• Do not expose the same files through two different Docker paths.
• Run a test scan before indexing the whole drive.

If you truly need to migrate to a new path, plan it carefully. Stop Immich, update mounts, verify the container path, then restart and rescan. The safest migration is one where the path Immich sees remains unchanged, even if the storage behind it has moved.

Backups Still Matter

An external drive connected to Immich is not a backup by itself. It is active storage. If the drive fails, is accidentally formatted, or gets corrupted, your photo library may be at risk.

A good Immich backup plan includes:

• The original photo and video files.
• The Immich database.
• Configuration files, especially Docker Compose and environment files.
• Any custom storage templates or library settings.

For external libraries, backing up the source files is essential. For uploaded Immich assets, backing up the upload directory and database together is especially important because the database contains metadata and relationships that make the library usable.

Performance Tips for External Drives

External drives vary greatly in performance. A USB SSD will feel very different from an older portable hard drive. Immich performs background jobs such as thumbnail generation, metadata extraction, machine learning, and video processing. These tasks can create heavy disk activity.

For better performance:

• Use a reliable USB 3 or faster connection.
• Avoid cheap hubs for important storage.
• Disable sleep settings that disconnect the drive too aggressively.
• Use an SSD for the database and application data if possible.
• Consider keeping thumbnails and database files on internal storage while media lives externally.

If your external drive spins down, the first access after inactivity may be slow. That is normal, but frequent disconnects are not. If the drive drops offline under load, check cables, power supply, filesystem health, and system logs.

The Best Overall Setup

For most home users with an existing photo archive, the best setup looks like this:

• Mount the external drive permanently at /mnt/immich-photos using UUID.
• Bind mount it into Immich as /external/photos:ro.
• Add /external/photos as an Immich External Library.
• Keep Immich’s database and configuration on reliable internal storage.
• Back up both the photo archive and the Immich database.

This approach is clean, safe, and easy to understand. Your existing files stay where they are, Immich gets consistent read-only access, and future remounts are less likely to break your library.

Final Thoughts

The best way to use a remounted external drive with Immich Server is to treat storage paths as part of your server infrastructure, not as temporary conveniences. A stable mount point, a stable Docker path, correct permissions, and a clear distinction between upload storage and external libraries will prevent most problems.

Immich is excellent at turning a folder full of memories into a fast, searchable, modern photo experience. Give it a reliable path to your external drive, protect your originals, and you will have a setup that is both powerful and maintainable.