Creating a new Stack makes directory owned as ROOT

[day-mon]

⚠️ Please verify that this bug has NOT been reported before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

Description

When creating a stack with Dockge the directory on the host is owned by root

Ideally passing in the user param into a docker compose should be the fix for this

user: 1001:1001

👟 Reproduction steps

Create a stack using dockage

👀 Expected behavior

Folder should be owned by the user thats passed in (in this case 1001)

😓 Actual Behavior

Folder owned by root

Dockge Version

1.1.1

💻 Operating System and Arch

Arch x64

🌐 Browser

Any

🐋 Docker Version

No response

🟩 NodeJS Version

No response

📝 Relevant log output

No response

[trythatagain]

I noticed that as well, I tend to use PUID= and PGID=, would be nice to not have to keep chowning the compose folder and it's contents.

[trythatagain]

Just did a check and for me it's the group (PGID) that needs write permission to allow me to delete dir, when using NFS from OMV

[marinierb]

Yes, please! Owning the files would make my life a lot easier!

[thetredev]

That's a docker (compose) problem. Folders have the correct permissions if you create them first before running docker run/compose. If they don't exist yet, the docker daemon (which runs as root in your case) creates the folders for you and starts the containers afterwards. The fact that non-root user xyz is in the Docker group doesn't make a difference. Being in the Docker group and therefore being able to run docker commands without sudo only tells Linux "user xyz is allowed to talk to the docker socket", communicating with the root user who actually controls the docker daemon and does as xyz says, so to speak.

So as long as the Dockge container itself is running as your desired user's UID and has access to the parent folders, Dockge could manage folder permissions. But my guess is this will not be the case for all your other containers.

Easiest fix: Have the folders ready with correct permissions before starting the containers.

[sabamimi]

Thanks for this easiest fix recommendation, I will do so (and start my migration from Portainer)

[Carlosgrr]

In my case, the dockge web interface creates a folder, compose.yaml and the .env file, with the "root:root" ownership, while this ownership is great for 'secrets' files, all other files/dirs could be created with my own "$PUID:$GUID". As it currently is, I have to access the console and change them manually every time (sudo chown $PUID:$GUID $folderpath -Rfv). It would be great if there was some option in the creation/editing menu to set these, and since every new container could be created using a different "$PUID:$GUID" every time, the default values could be defined per user in their respective 'global' configs, just like language currently is, but even if there wasn't any visible menu options in the web interface, just creating the environment variables PUID and GUID inside the dockge docker-compose.yaml to use as system defaults, would help greatly.

[thetredev]

Unfortunately dockge can't easily change the permissions to PUID:GUID, because the dockge container itself doesn't know about that PUID:GUID. It could be implemented, but as Docker itself sees it, that's something for user to manage. It would be better to have Docker itself manage user permissions "correctly", but there's currently no way for that AFAIK.

What I'm trying to say is: if dockge would provide such mechanism, many other unforseen issues regarding that feature would pop up and instead of adding new features, the development of the project is gonna be stuck in a loop trying to fix something that's never gonna be 100% what everybody wants/needs, which is why I believe Docker itself doesn't provide that mechanism. Just my 2 cents.

[BakermanLP]

I think, when the processes inside the container would run as a user (e.g. PUID, PGID), then the files outside the container have the same permissions. Of course should the UID und GID have write permissions in the folder. Many of the linuxserver.io images work like this. On many systems the user, that starts the container, has the uid 1000 and the group id 1000 , which belongs to the first created user on the system.

[thetredev]

Yeah but if you want that, the dockge container itself would have to run as 1000/1000 and I'm not so sure if that would work well. No harm in trying tho

[ChristopherHaws]

In docker compose you can specify the user and group like this:

services:
  service-name:
    user: "99:100"    # "${UID}:${GID}"

I use this when the containers don't expose an env variables for UID and GID. It's hit or miss depending on how the startup process works for the app, but might be worth a try. I use this on my unraid nas server when I want a container to run as the built-in "nobody:users" user/group.

[thetredev]

I know that you can, but dockge itself talks to the host's docker daemon and controls it via the root user. If the user 99:100 in your case is allowed to control the docker socket, i.e. the user is present on the host and is in the docker group, then yeah, that will work. Otherwise it won't. That's my point.

Edit: Also, the dockge container image has to be prepared to work with 99:100 as well. A docker-entrypoint.sh could chown everything relevant to 99:100 at container startup, but that would require dockge to be started up as root, i.e. in docker-compose user: 0:0, and then use gosu or something else to switch to 99:100 afterwards. It's just a question of whether it's worth the effort.

[OptimusGREEN]

yeah it would be nice just to have a setting in dockge to set a default user and group for creating stacks so that all directories and files are created using that user.

[thetredev]

Maybe creating the volume on the docker host and chowning it to the container's user UID/GID before starting it for the first time would suffice? Assuming the container user's UID and GID are both 1000:

# on the host
mkdir -p /path/to/persistent/container/data
chown -R 1000:1000 /path/to/persistent/container/data

and setting the container volume to be /path/to/persistent/container/data from within dockge afterwards.

I haven't tried it yet, so this theory needs some verification.

[OptimusGREEN]

yeah thats what i'm having to do just now but would be nice if dockge could do it for you and save some steps seeing as its creating the directory and compose file etc anyway.

[thetredev]

I guess that's not possible for every single scenario because dockge or docker for that matter can't specifically figure out which user (uid/git) will definitely be running the targeting application. Entrypoints can be run as root and then switch to UID/GID 1000 to replace PID1 with the target application, for example. Such cases are impossible for docker to know I'm afraid.