Ubuntu 24.04 docker container permissions to shared drives

I'm trying to create a decent user/group permission structure for my docker containers but perhaps i don't understand groups and docker access as well as i should The actual use case is I am running multiple docker containers through a single docker compose file and each has some access into a few or more of the drives and I'm trying to sort that access out into what permissions each should have correctly, its a physical pc running ubuntu server 24.04 I've got it to the point where the users and groups work fine on the host OS so i can write and read when using sudo su user1, user2 and so on, I'll just focus on one account and container for the rest of the post once that's working i can replicate for the others The drives have their own groups, there is an individual users for each docker container, each one contains the drive groups it needs the permissions are now 775 for directories and 664 for files within every drive All drives exist in /mnt/ on the host ls /mnt -al total 52 drwxrwxr-- 7 admin alldrives 4096 Jun 26 07:15 . drwxr-xr-x 23 root root 4096 Jun 29 01:12 .. drwxrwxr-x 3 admin drivea 4096 Jul 1 04:18 drivea drwxrwxr-x 1 admin driveb 64 Jun 12 2021 driveb drwxrwxr-x 1 admin drivec 34 May 19 2021 drivec drwxrwxr-x 16 admin drived 4096 Apr 21 00:54 drived They are mounted in fstab UUID=auuid /mnt/drivea auto defaults 0 0 UUID=auuid /mnt/driveb btrfs defaults 0 0 UUID=auuid /mnt/drivec btrfs defaults 0 0 UUID=auuid /mnt/drived auto defaults 0 0 Some are btrfs others are just ext4 single drives There is a group containing all drives - alldrives The reason for that is I identified that the root root default /mnt ownership was blocking access earlier, changing that to admin alldrives allowed the accounts to then see the files However in the docker containers they don't work they can view but not write, I think this is because the user/group mapping is not translating correctly between host os and docker container If i change the chmod access to 777 then it works from within the containers so i assume this means the account in the container isn't correctly linking to the group or user outside? The accounts intended to be used for the docker containers are like so id user1 uid=1006(user1) gid=1008(user1) groups=1008(user1),1002(driveb),1005(drivea),1007(alldrives) the main os user account is id admin uid=1000(admin) gid=1000(admin) groups=1000(admin),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),101(lxd),1001(docker),1007(alldrives) All the docker containers use environment variables to set the PGID and PUID .env file has ServicePUID=1006 ServicePGID=1008 paths to drives DRIVEA=/mnt/drivea DRIVEB=/mnt/driveb DRIVEC=/mnt/drivec DRIVED=/mnt/drived TMP=/tmp/afolder The docker compose script has PUID, PGID set and I've tried setting a UMASK and a user with little success - PUID=${ServicePUID} # default user id, defined in .env - PGID=${ServicePGID} # default group id, defined in .env - TZ=${TZ} # timezone, defined in .env - UMASK=002 user: ${ServicePUID}:${ServicePGID} My understanding of this is if i don't set the user property the container runs as root id 0 which allows it to read and write in the folders, if i connect to it over bash. The actual runtime of the service within the container however still uses the supplied puid and pgid which has the same permission issues, it just means its harder to verify since it looks like its working when you connect to troubleshoot. The volumes for the container are defined as volumes: - /etc/localtime:/etc/localtime:ro - ${DRIVEA}:/data - ${DRIVEB}:/config - ${TMP}:/tmp if i sudo in as that user on the host OS sudo su user1 I can run ls on the relevant drives ls /mnt/drivea/ -al drwxrwxr-x 15 admin drivea 4096 Jun 29 03:53 . drwxrwxr-x 3 admin drivea 4096 Jun 30 11:24 .. drwxrwxr-x 2 admin drivea 4096 Mar 29 23:31 afolder And create files touch /mnt/drivea/afolder/testfile $ ls /mnt/drivea/afolder/ -al drwxrwxr-x 15 admin drivea 4096 Jul 1 03:54 . drwxrwxr-x 3 admin drivea 4096 Jun 30 11:24 .. -rw-rw-r-- 1 user1 user1 0 Jul 1 03:54 testfile The files are created with the correct user and group with the correct permissions 664 So from the OS level i think I'm ok? The docker compose script is run using the admin account, I'm not sure if that has a bearing on this but the admin account has membership for alldrives and is the owner of them when i connect to the container to test these permissions sudo docker exec -t -i service /bin/bash id uid=1006 gid=1008 groups=1008 ls /data/afolder -al total 128 drwxrwxr-x 15 1000 1005 4096 Jul 1 13:54 . drwxr-xr-x 4 root root 4096 Jul 1 09:37 .. -rw-rw-r-- 1 1006 1008 0 Jul 1 13:54 testfile touch /data/afolder/aaafile touch: cannot touch '/data/afolder/aaafile': Permission denied whoami: cannot find name for user ID 1006 Does anyone know where I've missed a step please? I did go down the ACL route briefly but then backed out of it as it seemed easier and accomplishable through just group memberships and it didn't work either at least at the point i was at then The docker container looks like its running as the correct user but that it cant map back out to the user outside of the container I've looked up and tried many fixes which could be causing issues I've changed the names of alot of this to generic sounding account names and groups, hopefully i haven't introduced any typos or red herrings Could this be because the user in the host os has these group memberships groups=1008(user1),1002(driveb),1005(drivea),1007(alldrives) But in the docker container they only have the one? groups=1008