Greetings,
I’ve recently discovered that none of my media server containers are able to delete files from an attached USB drive used for their library. I’ve checked the PGID and PUID of both the Emby and Plex containers and both are set to 1000.
Not sure what else I should check. Is there a limitation on permissions for USB drives? Any guidance on getting this resolved would be great. It’s a bit annoying to have to go into the files app to delete something from my media libraries.
Hi mate,
There is no general restriction preventing Docker containers from deleting files on USB drives. PUID/PGID 1000 alone does not confirm that the mounted filesystem is writable by that user.
Could you post the output of:
findmnt -T "/path/to/your/media"
ls -ldn "/path/to/your/media"
Replace the path with the actual media folder mounted into Plex or Emby.
This will confirm the filesystem type, mount options, ownership and permissions. If the drive is NTFS or exFAT, permissions may be controlled by the USB mount options rather than normal chmod or chown.
Thanks for your help, sorry it took me a couple of days to get back to this. Here is a screenshot capturing the output of the two commands you recommended.
The drive is exFAT. Is that “errors=remount-ro” something I should be worried about?
Thanks, the output shows the likely cause.
The drive is mounted read/write, but the Movies directory appears as:
drwxr-xr-x uid 531 gid 0
Only UID 531 has write/delete permission. Plex and Emby are configured as UID/GID 1000, so they can read the library but cannot delete from it.
Because this is exFAT, normal Linux ownership is assigned by the drive’s mount options. chmod or chown will not provide a persistent fix.
errors=remount-ro is normal protection. It means the drive will be remounted read-only only if filesystem errors are detected. Your current mount shows rw, so it is not presently read-only.
Before changing the mount configuration, please post:
sudo docker inspect plex --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'
sudo docker inspect emby --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'
Use the actual container names if they differ. This will confirm that both containers are using /media/Expansion_1 and not another mount path.
It does appear that most of the media folder for both Emby and Plex are pointing to the /media/Expansion_1 location, apart from the music folder. I haven’t tried deleting from that location, but I rarely delete music, so I’ll disregard that anomaly for now. Here’s the output of the two commands.
Also, I can’t express how much I appreciate you taking the time to help and to explain in a way that both gets me to where I want to be but also teaches me why each step matters.
Thanks, and you’re very welcome. The mount output confirms both containers are using the expected folders on /media/Expansion_1.
The issue is now clear:
Drive filesystem: exFAT
Drive owner: UID 531
Drive group: GID 0
Directory mode: 755
Plex/Emby: UID 1000, GID 1000
UID 1000 can read the folders but cannot create, rename or delete files because only UID 531 has write permission.
Before changing the USB mount options, let’s verify the failure directly from each container:
sudo docker exec -u 1000:1000 plex sh -c 'touch /Movies/.permission-test && rm /Movies/.permission-test'
sudo docker exec -u 1000:1000 emby sh -c 'touch /Movies/.permission-test && rm /Movies/.permission-test'
These only attempt to create and immediately remove a harmless hidden test file. Please post the output.
The likely permanent solution will be mounting the exFAT drive with group ownership 1000 and group-write permission, while retaining UID 531 so the ZimaOS Files app can also manage the drive. I would not change the containers to UID 531, because that could create ownership problems inside their /config folders.
Here’s the output from both. It looks like your hunch was right about the read/write permissions for those containers. On both containers it returns a ‘permissions denied’ error.
That makes total sense about creating the group write permissions for UID 1000, when setting up each server I’d seen other folks have issues when the UID was set to anything other than 1000.
Exactly. The test confirms this is an exFAT mount-permission issue, not a Plex or Emby configuration problem.
I would keep both containers on 1000:1000. Changing their PUID to 531 could create separate permission problems in their configuration directories.
The safer arrangement is:
uid=531
gid=1000
fmask=0002
dmask=0002
That would keep ZimaOS as the owner while giving group 1000 write access, allowing Plex and Emby to delete files. exFAT does not store normal Linux ownership and permissions, so these must be applied when the drive is mounted.
Before we change anything, please show how ZimaOS is currently managing this mount:
grep -R "Expansion_1\|sda2" /etc/fstab /etc/systemd/system /DATA 2>/dev/null | head -100
findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /media/Expansion_1
Please post the output. I do not want to give you a temporary remount command that works only until the next reboot or conflicts with ZimaOS automatic mounting.
It doesn’t seem to like the first commend you recommended. Whenever I try it I don’t get a response and they command line just hangs. Here is a screenshot of the second and then the first commands. I asked an AI assistant if something was wrong with the command and it mentioned that grep -R isn’t compatible with the \| alternation operator unless I enable extended regex, not that I know what that means…
The first command produced no output because it was still recursively searching the entire /DATA tree. . The findmnt result already gives us what we need.
The drive is dynamically mounted by ZimaOS with permissions that block UID/GID 1000. Apply the corrected options to the current mount:
sudo mount -o remount,rw,uid=531,gid=1000,fmask=0002,dmask=0002,iocharset=utf8,errors=remount-ro /dev/sda2 /media/Expansion_1
Then verify Plex can create and remove a file:
sudo docker exec -u 1000:1000 plex sh -c 'touch /Movies/.permission-test && rm /Movies/.permission-test && echo "Plex write/delete test passed"'
This keeps ZimaOS as owner UID 531 while granting group 1000 write access. This remount is a live test and may not survive a reboot. Once it passes, we can make the corrected mount options persistent without changing the Plex or Emby PUID/PGID.
That confirms the live remount did not apply, so the second test was expected to remain denied.
The exFAT driver will not accept changing these ownership options on the existing active mount. The drive must be unmounted and mounted again with the new options. Because Plex and Emby are actively using it, we should not force that while the containers are running.
First, check whether anything else is using the drive:
sudo fuser -vm /media/Expansion_1
Then stop only Plex and Emby:
sudo docker stop plex emby
Please post the fuser output before we unmount anything.
Here are the outputs for this step. It kicked back an error on the fuser command, indicating the v was an invalid option for fuser. I tried it with just the -m to see if that would return anything.
You can see toward the end of the screen shot, I tried the fuser command again after stopping the two containers, and then I restarted the Plex container and ran the fuser command a couple more times to see if the output changed.
Thanks for sticking with this. We have now confirmed the cause.
There is no general limitation preventing Plex or Emby from deleting files on a USB drive. The issue is that ZimaOS mounted this exFAT drive as UID 531, while both containers are running as UID 1000.
Open the settings for Plex first and change only:
PUID: 531
Leave:
PGID: 1000
Save the app, allow it to restart, then test deleting a file through Plex. If that works, apply the same PUID change to Emby.
There is no need to reformat the drive or continue changing its mount configuration.
No need to thank me, It’s I that owes you a debt of gratitude for helping me work through this with such patience.
I changed the PUID as you indicated, restarted the container, and then tried a deletion which unfortunately failed. I then tried adding the fmask and dmask you mentioned earlier as additional environmental variables, but that didn’t make a difference.
Just to be sure, I also made the change to the Plex UID and it also displayed an access denied error on the deletion attempt.
To avoid such headaches in the future, how should I have formatted the drive after connecting it to my ZimaOS server?
I have now spotted why changing the PUID did not work.
We misread this earlier output:
drwxr-xr-x 531 0 0 262144 ...
531 is the directory link count, not the UID. The actual ownership is:
UID: 0
GID: 0
Permissions: 755
So the exFAT folder is owned by root:root, and neither UID 1000 nor UID 531 can write to it. Please return Plex and Emby to:
PUID: 1000
PGID: 1000
Also remove the fmask and dmask environment variables. Those are host filesystem mount options and have no effect inside Plex or Emby.
For a drive permanently attached to ZimaOS, EXT4 would have been the better format because it supports normal Linux ownership and permissions. If the drive must remain exFAT, the permissions must be corrected through the host’s mount options, not through the container settings.
The things we learn after we cause ourselves a world of hurt. haha! That drive was blank when it was first plugged into the server! Now I have 12TB of files I need to account for.
I’m still working on finalizing my backup strategy, so I’ll hurry that along so that I can reformat the drive as EXT4 and just have it done the right way from the start. It might take me a couple of weeks to get things set up and moved around. If I still have permissions issues after reformatting the drive, I may be back to ask your help again.
Thanks again for all of your help and putting up with a noob like me. It’s been a great learning experience.