Folder permission for docker containers

Insight & Feedback
1

Hi,

I’m having trouble with various docker container where they cannot write in directories.

Best example is handbrake.
I want it to be able to encode files from and to the /media/sda2 ssd in my server.

I tried changing the PUID & PGID in the docker settings, to 0, to 1000, to 999 but I still get the same error of an non-writable output folder.

I’ve had similar issues with other containers

I’m not exactly an expert, and chose ZimaOS to avoid to much terminal use, but here I am now, trying to chmod my way out of no-encoding hell, and it does not work.

I’ve seen a few other subject with similar issues, and clearly it seems a way to see wich user have which permissions on a folder would be a nice addition to the Files app.

In the mean time, if someone has a workaround…

2

This is what drove me away from ZimaOS. I am now running Unraid on the same platform. Not super happy with Unraid, I’m not convinced it’s a good fit for me long term, but it is much more mature and has better support. I’m keeping an eye on ZimaOS though. I want to love it but I need things to work.

3

You’re not hitting a Docker issue, it’s host disk permissions on /media/sda2.

Most common causes on ZimaOS:

  • Disk is NTFS/exFAT (mount-level permissions override chmod)
  • Folder owned by root
  • Container user doesn’t match folder owner

Quick checks:

lsblk -f
ls -lah /media/sda2
mount | grep sda2
docker inspect <handbrake-container> | grep -i user

If the disk is ext4, fix ownership:

chown -R 1000:1000 /media/sda2
chmod -R 775 /media/sda2
docker restart <handbrake-container>

If it’s NTFS, chmod won’t help. It must be mounted with proper uid/gid or reformatted to ext4.

Post the outputs and we’ll pinpoint it fast.

1 Like
4

Hi gelbuilding !

Thanks for your answer.

It seems to be a format issue as you say.
The Drive is in exFAT:
sda
└─sda2 exfat

drwxr-xr-x 8 root root 1.0M Feb 3 20:21 Media

/dev/sda2 on /media/sda2 type exfat

"Env": [
                "PGID=1000",
                "OPENAI_API_KEY=sk-xxxxxx",
                "PUID=1000",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/base/sbin:/opt/base/bin",
                "ENV=/root/.docker_rc",
                "USER_ID=1000",
                "GROUP_ID=1000",
                "SUP_GROUP_IDS=",
5

Perfect, that explains it.

Your disk is exFAT:

/dev/sda2 on /media/sda2 type exfat
drwxr-xr-x  root root

exFAT does not use real Linux ownership.
chown and PUID/PGID changes won’t affect it.

Your container runs as:

PUID=1000
PGID=1000

But the mount is effectively owned by root, so writes fail.

Clean Solutions

Option 1 (Recommended)

Backup > reformat to ext4 > restore.

ext4 fully supports Linux permissions and avoids this problem permanently.

Option 2 (Mount-level fix)

The disk must be mounted with:

uid=1000,gid=1000,umask=002

On ZimaOS, mounts are system-managed, so this is harder and not always persistent.

Reality

If this is a working server disk used by containers >
ext4 is the correct format.

exFAT is fine for USB portability, not for Docker workloads.

6

You mentionned that the mounting with permission is not persistent.
Is that also the case in a server which is very rarely shut down ?

If so you’re right and it would be better to format, I imagine I can do that directly with the formating tool inside ZimaOS. I’ll first have to back up all my stuff though.

Thanks :slight_smile:

Well, I tried to format via ZimaOS…

image

7

Yes, even if the server is rarely shut down, exFAT permissions are applied at mount time. If the disk ever remounts (reboot, cable reseat, service restart), the uid/gid mapping resets. That’s why ext4 is the proper long-term solution for Docker workloads.

About the exit status 1 when formatting, that almost always means the disk is still mounted or in use.

Before trying again, check:

mount | grep sda2

If it’s mounted, see what’s holding it:

fuser -m /media/sda2

Stop any containers using it, then:

umount /media/sda2

Once it’s fully unmounted, the ZimaOS formatter should work.

If it still fails, post the output of:

mount | grep sda2
fuser -m /media/sda2

and we’ll see exactly what’s blocking it.

8

Hi !

I have already stopped all containers with volumes on the concerned drive.

grep gives:

$ mount | grep sda2
/dev/sda2 on /media/sda2 type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro)
/dev/sda2 on /var/lib/casaos_data/.media/sda2 type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro)
/dev/sda2 on /DATA/.media/sda2 type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro)

and fuser

$ fuser -m /media/sda2
1355

unmount still says that the target is busy.

EDIT for Take 2:
I tried again after a reboot. fuser indicated the PID 1356 which seems to be:
root@ZimaOS:/DATA ➜ # ps -ef | grep 1356
root 1356 1 0 21:39 ? 00:00:04 /usr/bin/icewhale-files
root 17298 6970 0 21:48 pts/1 00:00:00 grep 1356
So i guess what’s blocking the unmount is just the file system ?