Starting an app changes ACL permissions?

TrueNAS General
1

i’m in the process of converting a 2 drive mirror pool into a 4 drive Raid Z2 pool. i backed up my data, disabled all the apps and shares that used the old pool, and created a new one with the same datasets as the old one. i’m still copying the backed up data back into the new pool, but while that’s running, i decided to work on getting some of the apps up and running again.

i have a qbittorrent client running through dockge, which has a “downloads” folder in my main pool mounted. it worked just fine before, and since i’d set up the same datasets in this new pool as i had in the old one, i thought it would just work when i turned it on. however, when i did that and opened the web ui, i noticed it had read only access to the folder. and when i went to check the ACL permissions to investigate the problem, i noticed they had changed since i started the app.

i’ve tested this several times, and it keeps happening. when i start qbittorrent in dockge, the ACL changes. i can’t figure out how to fix that, or how to get qbittorrent the write access to this dataset that it needs (and which it had before).

here’s the docker compose for it i run in dockge

version: "3"
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: container:gluetun
    volumes:
      - /mnt/Apps/dockge/containers/qbittorrent/config:/config
      - /mnt/RAID/admin/downloads:/downloads
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=CST
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    restart: unless-stopped
networks: {}

here’s what the ACL for the downloads folder looks like before i start the app

2024-11-26_08-56
2024-11-26_08-56704×745 20.4 KB

and here’s what it changes to after i start launch qbittorrent in dockge.

2024-11-26_08-57
2024-11-26_08-57702×688 19.4 KB

these changes persist - stopping qbittorrent doesn’t cause them to revert. i can edit the ACL to make admin the dataset’s owner again, but that goes away whenever i start qbittorrent. what is going on here?

2

Yeah, many applications running in docker when run as root will attempt to chown their data directory. Some may also attempt to chmod, but it’s mostly chown.

3

… okay? so what do i do about that? do i need to make the datasets apps will use be owned by root instead of admin?

edit - just tried that, and it didn’t change anything. i made root the owner of the folder in the ACL instad of admin, but when i launched qbittorrent, that still got removed. and qbittorrent still doensn’t have write access to the folder.

4

Do you even have a user 1000 created in your TrueNAS? If you don’t have a user created for qbitorrent:

  1. Create a user and note the user id and group id
  2. Set the PUID to the user id and PGID to the group id in your yaml
  3. Give permission for the created user to the dataset
5

i swear i had a user 1000, group 1000 before, but apparently i don’t anymore? this compose worked before, and i didn’t upgrade truenas as part of this change, though my old 2 drive mirror pool hadn’t been upgraded to the latest version of ZFS yet.

regardless, creating a user for qbittorrent, listing it’s ID’s in the YAML, and giving it ownership of the downloads dataset seems to have fixed the issue. thank you.

i may re-open this if i run into similar issues with other apps. all my other ones are the stock version from IX’s repo though, so hopefully they just work once i turn them on again.

1 Like
6

There wasn’t necessarily anything wrong with the compose, you can use any number as user id or group id (doesn’t matter if they “exist” or not). But you do run into issues with UI (like showing ? marks because the user id is not known).

7

FYI - i’ve run into another issue with permissions and apps. it was different enough that i created a separate thread for it, but i since you were so helpful here, i wanted to share it with you.

i’d really appreciate your help again if you’re willing and able.