Immich can work very well with external disks, network shares, and remounted storage, but it depends on a stable and predictable storage layout. Because Immich stores important references to files and volumes, administrators should treat drive configuration as part of the application’s infrastructure rather than as a temporary convenience.
TLDR: External or remounted drives in Immich should use stable mount points, reliable permissions, and a clear Docker volume mapping strategy. Drives should be mounted by UUID or another persistent identifier so paths do not change after reboot. Administrators should avoid moving libraries without planning, keep backups, and verify that Immich containers can consistently read and write to the expected locations.
Why External and Remounted Drives Require Care
Immich is often used to manage large photo and video collections, so it is common for administrators to store libraries on external USB drives, NAS shares, secondary internal disks, or remounted paths. This is a practical approach, especially when the main system disk is small. However, problems can occur when a drive appears under a different path, mounts too late during boot, loses permissions, or is disconnected while Immich is running.
In a typical Docker-based Immich installation, the application does not simply “see” the host filesystem. Instead, storage locations are exposed to the containers through volume mappings. If the host path changes or becomes unavailable, the container may see an empty folder, an incorrect directory, or no directory at all. This can lead to failed uploads, missing thumbnails, broken library scans, or confusion when files appear to vanish from the interface.
[ai-img]external drive, photo server, storage setup[/ai-img]
Use Stable Mount Points
The most important best practice is to mount external or secondary drives at a consistent location. A path such as /mnt/photos, /mnt/immich-library, or /media/storage/immich is better than relying on automatically generated desktop paths such as /media/user/DriveName. Auto-mounted paths may change depending on the user session, device order, or drive label.
For Linux servers, administrators should usually configure the drive in /etc/fstab. The device should be referenced by UUID rather than by names like /dev/sdb1, because device names can change after reboot or when another disk is connected. A UUID-based mount ensures that the intended disk is mounted to the intended path every time.
- Good: Mounting a drive by UUID to
/mnt/immich-library. - Risky: Depending on
/dev/sdb1always being the same drive. - Risky: Letting a desktop environment auto-mount the drive only after login.
Make Docker Volume Mappings Predictable
Immich deployments commonly use Docker Compose. In that case, the host directory must be mapped into the correct container directory. The host path should be stable, readable, and writable by the service that needs it. For example, an administrator might map /mnt/immich-library on the host to a directory used by Immich inside the container.
Once the mapping is chosen, it should not be casually changed. Immich records paths and expects them to remain valid. If the host path changes from /mnt/photos to /media/photos, Docker Compose must be updated accordingly, and the administrator should confirm that the application still points to the intended location. A small path mismatch can make a real library look empty from inside the container.
Consistency is more important than elegance. A simple, permanent mount path is better than a complex layout that changes depending on which storage devices are currently attached.
Check Permissions Before Starting Immich
Permissions are one of the most common causes of problems with external or remounted drives. The Immich containers must be able to access the mounted directory according to the needs of the deployment. Upload storage generally requires write access, while external libraries may require only read access unless Immich is expected to modify files.
Administrators should verify ownership and permissions from the host and, when necessary, from inside the relevant container. If a directory is mounted from a Linux filesystem such as ext4 or XFS, standard ownership and permission tools such as chown and chmod may apply. If the drive uses NTFS, exFAT, SMB, or NFS, permissions may be controlled by mount options instead.
- For upload locations: Immich needs reliable write access.
- For external libraries: read access may be sufficient, depending on the setup.
- For network shares: mount options should define the correct user, group, and access mode.
- For removable drives: the system should prevent Immich from writing to a fallback empty mount directory if the drive is absent.
Avoid Empty Mount Directory Problems
A subtle but serious issue occurs when a mount point exists but the drive is not actually mounted. For example, /mnt/immich-library may exist as an empty directory on the host. If the external drive fails to mount, Docker may still bind that empty directory into the container. Immich may then start normally, but it will not see the expected files.
To reduce this risk, administrators can use systemd mount dependencies, Docker startup ordering, or health checks. Another practical approach is to place a small marker file on the mounted drive, such as DRIVE_IS_MOUNTED.txt, and check for it before starting Immich. This helps confirm that the correct storage is present.
[ai-img]server dashboard, mounted storage, file paths[/ai-img]
Be Careful with External Libraries
Immich supports external libraries, which allow existing folders of photos and videos to be indexed without importing them into the main upload structure. This is useful for large collections already organized on a separate disk. However, external libraries should be treated as a stable source location. If the drive path changes, Immich may no longer be able to locate those assets.
Before adding an external library, an administrator should decide whether the storage is intended to be permanent. A USB drive used occasionally for transfers is not ideal as a long-term external library. A permanently mounted disk, a reliable NAS share, or a stable internal drive is a better choice.
It is also important to understand that deleting files from the external source can affect what Immich displays after scanning. Immich’s index depends on the availability of the referenced files. Therefore, administrators should manage external library folders carefully and avoid reorganizing large directory trees without planning a rescan strategy.
Plan for Reboots and Power Loss
Storage that works immediately after manual mounting may fail after a reboot if the boot process is not configured correctly. External drives and network shares may become available later than Docker. If Immich starts before the storage is mounted, it may encounter missing paths or empty directories.
For local drives, /etc/fstab should include suitable options that allow the system to mount the drive automatically. For network storage, systemd automount or explicit network dependencies may be appropriate. Administrators should test a full reboot, not just a manual restart of Immich, to confirm that the storage comes online correctly.
- Reboot the host after configuring mounts.
- Confirm that the external or remounted drive is available before Docker starts.
- Check container logs after reboot for storage-related errors.
- Open Immich and verify that uploads, thumbnails, and external libraries behave normally.
Use Reliable Filesystems and Connections
The filesystem and connection method matter. A high-quality internal SATA or NVMe disk is generally more reliable than a loosely connected USB drive. USB storage can work, but administrators should use good cables, stable power, and avoid hubs that may disconnect under load. Photo and video libraries produce sustained reads and writes, especially during imports, thumbnail generation, machine learning jobs, and backups.
For Linux-based Immich servers, native filesystems such as ext4 or XFS are often preferable for local storage. NTFS and exFAT can be useful for portability, but they may introduce permission limitations or recovery concerns. For NAS storage, SMB and NFS can work well if mounted correctly, but network reliability becomes part of the Immich storage chain.
Performance should also be considered. Large video files, facial recognition, and thumbnail generation can put heavy load on storage. Slow external drives may not break Immich, but they can make library processing noticeably slower.
Do Not Treat External Drives as Backups
An external drive attached to Immich is storage, not automatically a backup. If Immich writes to it, indexes it, or depends on it for daily operation, it is part of the live system. Accidental deletion, filesystem corruption, ransomware, hardware failure, or an incorrect mount can still cause data loss.
Administrators should maintain a separate backup strategy. This may include another offline disk, a remote server, cloud storage, or a NAS snapshot system. The Immich database is especially important because it stores metadata, albums, users, and application state. Backing up only the photo files is not the same as backing up the full Immich environment.
- Back up uploaded media.
- Back up the Immich database.
- Back up configuration files, including Docker Compose files and environment files.
- Test restoration occasionally.
[ai-img]backup drives, photo archive, data protection[/ai-img]
Document the Storage Layout
Good documentation prevents confusion later. The administrator should record where each drive is mounted, what UUID it uses, which Docker volumes map to it, and whether Immich uses it for uploads, thumbnails, profile data, or external libraries. This documentation is especially valuable when replacing a drive, migrating to a new server, or troubleshooting after an update.
A simple note file can include the mount path, filesystem type, capacity, backup schedule, and any special mount options. If multiple people maintain the server, clear documentation reduces the chance that someone will disconnect or rename a critical drive.
Best Practice Checklist
- Use a permanent mount point such as
/mnt/immich-library. - Mount drives by UUID or another persistent identifier.
- Configure mounts before starting Immich or Docker.
- Verify permissions from both the host and container perspective.
- Avoid relying on desktop auto-mount behavior.
- Use reliable filesystems and stable physical connections.
- Do not let Immich start against an empty fallback directory.
- Keep Immich media, database, and configuration backups.
- Document the storage layout and update it after changes.
Conclusion
External and remounted drives can be an excellent way to expand Immich storage, especially for large personal photo and video collections. The key is to make the storage behave like a permanent, dependable part of the server. Stable mount points, correct permissions, careful Docker mappings, and tested backups make the difference between a reliable setup and a fragile one. When administrators treat storage configuration with the same care as the Immich application itself, the system is far more likely to remain consistent, recoverable, and easy to maintain.
FAQ
Can Immich use an external USB drive for photo storage?
Yes. Immich can use an external USB drive if it is mounted reliably, mapped correctly into Docker, and available whenever Immich starts. The drive should use a stable mount point rather than a temporary auto-mounted path.
Should an Immich drive be mounted by UUID?
Yes. Mounting by UUID is strongly recommended because device names such as /dev/sdb1 can change. A UUID helps ensure that the correct drive always mounts to the correct location.
What happens if the drive is not mounted when Immich starts?
Immich may see an empty directory or fail to access expected files. This can cause missing assets, upload failures, or library scanning issues. Administrators should ensure that storage mounts before Immich starts.
Can a NAS share be used with Immich?
Yes. SMB or NFS shares can be used, provided they are mounted consistently and with correct permissions. Network reliability and mount timing are important factors.
Is an external library the same as imported Immich storage?
No. An external library lets Immich index files in an existing location, while imported uploads are stored in Immich’s configured upload location. External library paths must remain stable for Immich to continue finding those files.
Does an external drive count as a backup?
Not if it is part of the live Immich setup. A proper backup should be separate from the active storage and should include media files, the database, and configuration files.
