When chown and chmod appear to do nothing on a USB drive, first identify the filesystem. The source community reply suspected NTFS or exFAT, which is a reasonable explanation because those filesystems do not behave like ext4/Btrfs with native Unix ownership and mode bits.
The source does not tell us which filesystem MikeFrizz actually used, and the original poster never returned with a confirmed result. Therefore this should remain a filesystem-aware troubleshooting guide, not a statement that every ZimaOS USB drive ignores permissions.
Identify the USB Filesystem Before Changing Permissions
Check the disk format in ZimaOS Storage or from a read-only command such as:
lsblk -fCurrent ZimaOS supports read/write access to NTFS, exFAT, ext4, and Btrfs among other formats, but “read/write supported” does not mean all filesystems persist Unix UID/GID/mode metadata in the same way.
Use the current supported-disk-format matrix.
NTFS and exFAT Commonly Present Permissions Through Mount Options
On Linux, exFAT and many NTFS mount configurations present files with ownership/mode values derived from mount options rather than storing ordinary POSIX permission changes exactly like ext4. As a result, chown or chmod can appear ineffective or revert on remount.
That does not mean the drive is read-only or broken.
A Linux Filesystem Gives Docker the Most Predictable POSIX Permissions
If the USB disk is dedicated to ZimaOS/Linux and you need real UID/GID/mode control, ext4 or Btrfs is a more natural fit. Reformatting is destructive, so copy the data elsewhere before changing filesystems.
Avoid Using a Host Symlink as the Primary Docker Storage Migration
The source user copied Immich data to USB and created a symlink from the old location. Containers do not automatically follow host symlinks outside their mounted volume namespace. The symlink may point to a path the container cannot see.
A direct bind mount/volume is clearer and easier to audit.
Map the USB Folder Directly into Immich
Instead of keeping an old host path and redirecting it with a symlink, edit the Immich app/container volume so the real USB folder is mounted at the container path Immich expects.
Current IceWhale documentation explains that the host path can be changed without changing the container-side path.
Use the current ZimaOS Docker volume-path model.
Do Not Move Every Immich Component to Arbitrary USB Storage Blindly
Immich media libraries and upload storage have different requirements from the PostgreSQL database and application state. Before moving directories, identify exactly which host volume is being relocated and follow current Immich deployment/migration guidance.
Do not move a live database directory with a symlink while containers are running.
Fix the Mapping Before Broad chmod 777
If the container cannot see the correct host folder, changing permissions will not fix the path. Verify the mount first, then adjust only the minimum user/group access needed by the container.
USB Permission FAQ
Does ZimaOS support NTFS and exFAT read/write?
Yes, current IceWhale documentation lists both as read/write supported.
Why can chmod/chown still behave differently?
Those filesystems do not use native Linux POSIX ownership/mode semantics in the same way as ext4 or Btrfs.
Was the source user's filesystem and final fix confirmed?
No. The filesystem was inferred by a community reply and the original poster did not report a result.
