Permission issues inside container despite proper PUID/PGID settings

[BLucky]

So I just set up a couple of LSIO containers (I’ll use transmission as an example but there’s 6 LSIO containers with the same issue) and all of them have permission issues:
all the mounted volumes show proper perms (775, owned by abc:abc (1001:1001, matches host user)), but trying to create a file, to ls inside a mounted folder, read a file, etc just results in a permission denied error.

Here’s a snippet from my docker-compose:

transmission:
    container_name: transmission
    image: linuxserver/transmission
    restart: unless-stopped
    logging:
      driver: json-file
    network_mode: bridge
    ports:
      - '9091:9091'
      - '51413:51413'
      - '51413:51413/udp'
    environment:
      - 'PUID=${PUID}'
      - 'PGID=${PGID}'
      - 'TZ=${TZ}'
      - TRANSMISSION_WEB_HOME=/flood-for-transmission/
    volumes:
      - '/var/mediarr/config/transmission:/config'
      - '/var/mediarr/data/torrents:/downloads'
      - '/var/mediarr/data/watch:/watch'

Also here’s the output when trying to do stuff on the host (output shortened for readability)

[mediarr@mediarr data]$ id
uid=1001(mediarr) gid=1001(mediarr)
[mediarr@mediarr data]$ ls -l
total 0
drwxrwxr-x. 2 mediarr mediarr 6 Feb 13 02:57 torrents
[mediarr@mediarr data]$ touch ./torrents/foobar #no errors
[mediarr@mediarr data]$ rm ./torrents/foobar #no errors
[mediarr@mediarr data]$ echo $?
0

and here’s output from docker exec-ing into the container and trying to do the same thing (torrents on host is mounted to /downloads in container):

abc@b28bf18ce937:/$ id
uid=1001(abc) gid=1001(abc) groups=1001(abc)
abc@b28bf18ce937:/$ ls -l
drwxrwxr-x   2 abc  abc     6 Feb 13 03:15 downloads
abc@b28bf18ce937:/$ ls ./downloads/
ls: cannot open directory './downloads/': Permission denied
abc@b28bf18ce937:/$ touch ./downloads/foobar
touch: cannot touch './downloads/foobar': Permission denied

note: I can cd into said directory, but can’t do anything in it

Also note: this is all running on Fedora CoreOS and the containers were set-up with portainer (which is running in privileged mode) in case that’s relevant.

Is this something I messed up or is there an issue here?

[driz]

if i had to make a wild guess, i would assume selinux is the culprit, but i never pass up the opportunity to blame portainer for all things weird and unexplained (it’s quite horrible for deployment of containers and we do not support deploying our containers using it)

anyway, i would check the selinux contexts and correct those to work with docker since you explain this issue is not just affecting a single container.

[BLucky]

Yeah I did read up that portainer causes issues sometimes but I figured if I keep it simple there would be less opportunities to mess up, and considering that portainer seems to straight up use dokcer-compose I decided to trust it

As for the selinux contexts:
drwxrwxr-x. 2 mediarr mediarr system_u:object_r:user_home_t:s0 6 Feb 13 03:15 torrents
I have no idea what those contexts mean, any hints?

If this is too complicated to be wortwhile to fix I’ll just switch to good old debian, but I kind of wanna try out fcos so I’m still looking for a solution.

[driz]

you could spin up a debian deriv vm and test there, if your same setup works there, it’s likely the selinux contexts. I’ve not messed with selinux contexts in a very long time, so you’d need to dig into them or just set permissive

– also few things to note, portainer only uses docker compose on x86, not arm (libcompose there) and it doesnt respect many settings in docker-compose that gets input. just pretend portainer doesnt use docker-compose and you’ll have a better time

[BLucky]

Thanks, in that case I"ll just switch to debian server