[Feature] Per-user storage locations (separate directories / drives / partitions per user)

[SmcBoyardee]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Feature request

Please add official support for assigning each user their own storage location, so different users' uploaded libraries can live in different directories, drives, partitions or storage devices.

A concrete example of what I want to do: I have a single large HDD split into one partition per user (for example /mnt/alice, /mnt/bob, /mnt/carol), and I want each user's Immich library to be stored on their own partition. I want to be able to do this natively in Immich, without bind-mount or symlink hacks.

Problem

All users' uploads currently live under a single UPLOAD_LOCATION, with a per-user subfolder inside it. For a shared instance (family, friends, small team) there is no supported way to put one user's library on a different disk or partition from another's.

Why per-user partitions or disks matter:

• Hard capacity limits: a partition has a fixed size, so one user can never fill the disk and break uploads for everyone else. Immich quotas are a soft limit and don't protect against other things writing to the disk. A partition does.
• Isolation: each user's data is physically separate, so a filesystem problem or full partition on one doesn't touch the others.
• Per-user encryption: each partition can have its own LUKS volume and key, so one user's library can be locked or unlocked on its own.
• Per-user filesystem features: different filesystems, mount options, snapshots (ZFS/btrfs datasets or LVM volumes), and different backup and retention policies per user.
• Easier handover or retirement: a user's whole library can be unmounted, copied, archived or deleted without touching anyone else's data.
• Incremental growth: add a new disk or partition and point new users at it, without migrating everyone.
• Mixed hardware: put one user on an SSD, another on a large HDD, another on a NAS share.

What exists today, and why it doesn't cover this

• Storage label: lets an admin rename a user's library/<label> folder, but the folder is still inside the one UPLOAD_LOCATION. It doesn't change which disk or partition is used.
• Storage template: only controls folder and file naming inside that single root.
• Folder location env vars (thumbs, encoded video, etc.): can move those sub-folders to another drive, but globally. They cannot be set per user, and originals still go to the single root.
• External libraries: can live on any disk or partition, but are read-only imports. Uploads and mobile backup cannot target them (see discussions [Feature] External library upload #5453 and Upload and External library in same folder #19853), so they don't solve where a user's uploaded assets are stored.
• Bind mounts / symlinks on library/<user-id>: the only way to do this today. It is unsupported, depends on the internal folder layout, and is easy to break on upgrade. Immich doesn't know about it, so storage checks and the folder checks can misbehave. If a partition fails to mount, Immich can silently write that user's uploads to the parent disk instead.
• Multiple Immich instances: works, but loses shared albums and partner sharing.
• One big pool (LVM / mergerfs / ZFS): works, but gives no per-user physical isolation, capacity limits or independent backup/encryption.

Proposed solution

Add an optional per-user storage root alongside the existing global default.

1. Named storage locations defined by the admin (env var or config file), each pointing at any mounted path (a directory, a separate disk, or a partition):
   default: /data/upload
   alice-part: /mnt/alice/immich
   bob-part: /mnt/bob/immich
   bulk-hdd: /mnt/hdd/immich
2. Per-user assignment: Admin > Users gets a "Storage location" dropdown (default = global). New uploads for that user go to the chosen root.
3. Migration job when the assignment changes, similar to the Storage Template Migration job: move existing assets, update DB paths, verify before deleting the originals.
4. Mount safety: the .immich mount verification runs per location. If a partition isn't mounted or is unavailable, uploads for that user fail safely and the admin UI shows a clear error. Immich must never silently fall back to another location, or write into an unmounted mount point on the parent disk.
5. Per-location disk usage in Server Stats, so each partition's free space is visible. Ideally the per-user storage usage in Admin > Users is shown against its partition's capacity.

A minimal first version could support one root per user for newly uploaded assets only, with no migration, and build on that.

Considerations

• Thumbnails and encoded video could follow the user's root or stay on a separate global fast root (e.g. thumbs on SSD, originals on HDD). An option for this would be useful.
• Docker users must mount each location as a volume; docs should cover this, including a per-partition compose example.
• Shared albums and partner sharing should be unaffected, since access is resolved in the DB, not the filesystem.
• Backup docs would need to say which paths belong to which users.

Thanks for considering this, and for all the work on Immich!

Platform

• Server
• Web
• Mobile

[bo0tzz]

#5984