Container's user does not have write permissions in bind-mounted folde

Splashy3852 · 2024-11-17 21:58:05

Hi everyone, I am trying to solve an issue with containers on my personal laptop. I have both Docker and Podman installed. I installed docker via the procedure on its website (no pacman or AUR packages). The problem is that when I launch a container and I bind mount a folder, the user in the container cannot write in the folder, whether the container manager is docker or podman.

For instance, here's a very simple Dockerfile, which does not work (uid is the same as my user in the host):

FROM debian:latest
ARG username=stduser
RUN useradd -u 1000 ${username}
USER ${username}

What I've tried to do:
1. checked that the user ID and the group ID for the container user are the same as the host user
2. tried to add the flag

--security-opt label:disable

3. chown-ed the folder that I try to bind mount with my non-root user
but nothing changed

I really don't know what to do: I had another laptop (at work) with Ubuntu 22.04, and I do not encounter this issue. However, given the procedure I followed on my Arch (really straightforward, I followed the instructions at letter), I am surprised that I was unable to find other users with the same issue as me.

I also tried with the docker package in the AUR, and that produces the same result.

Before concluding the message, I'd like to give you a bit of context on the use case, because I have found a workaround for it, but it's not very optimal. The use case consists of running an image of Debian, defined in a Dockerfile, pulled from the vscode repository for C++ development. In fact, devcontainers are the use case for my setup, but to reproduce the problem, it is sufficient that I run the container via CLI, so it is an issue of docker and podman. The workaround I found is to use distrobox (relying on podman), which somehow manages to deal well with sharing folders; but this means that I have multiple copies of vscode: one for each distro in distrobox, and that the result is not exactly the same as the one I'd have with a devcontainer.

Please, any help will be highly appreciated! I'm struggling with this since 3 months ? and I don't want to dual boot with another distro just to be able to work properly at some point ?

Last edited by Splashy3852 (2024-11-17 21:59:34)

Lone_Wolf · 2024-11-18 10:30:16

Upstream devs usually target distros using .deb or rpm and their code often need adjustments to work correctly on archlinux .

Archlinux packages do those things for you, but if you install outside of pacman you are responsible for making those adjustments.

Read https://wiki.archlinux.org/title/Docker#Installation , verify you do have those services running and basic docker functionality works .

The problem is that when I launch a container and I bind mount a folder, the user in the container cannot write in the folder, whether the container manager is docker or podman.

What is the exact command that you use to bind-mount the folder and what does it output on terminal/log-files ?

Splashy3852 · 2024-11-19 19:14:30

Lone_Wolf wrote:

Upstream devs usually target distros using .deb or rpm and their code often need adjustments to work correctly on archlinux .
Archlinux packages do those things for you, but if you install outside of pacman you are responsible for making those adjustments.
Read https://wiki.archlinux.org/title/Docker#Installation , verify you do have those services running and basic docker functionality works .
The problem is that when I launch a container and I bind mount a folder, the user in the container cannot write in the folder, whether the container manager is docker or podman.
What is the exact command that you use to bind-mount the folder and what does it output on terminal/log-files ?

Hi, thanks for the reply. I've been trying to check yesterday about some things you asked, but unfortunately I did not have much time. I will provide a precise answer during the weekend. However, I wanted to point out some things:

1. I've been imprecise while saying that docker has not been installed with pacman. In fact, I tried with both installation method (manual and pacman), and nothing changed. I will do a clean installation this weekend to see what happens.

2. The same issue applies to podman, so for the sake of completeness, I will post the commands that I use also for podman, since its installation has been clean since the beginning (by using pacman), and (most importantly) it does not rely on system services to run, which may be another source of problem.

3. Doing a chmod 777 . -R, or running my IDE as sudo are things that solve the issue, but it's very unsafe to do. We can conclude that the superuser in the container can access and modify the files: the problem must be related to the "normal" user.

So, I will write again soon, and integrate the additional info to the original post, so that it will be easier to read

Splashy3852 · 2024-11-25 18:29:12

Lone_Wolf wrote:

Upstream devs usually target distros using .deb or rpm and their code often need adjustments to work correctly on archlinux .
Archlinux packages do those things for you, but if you install outside of pacman you are responsible for making those adjustments.
Read https://wiki.archlinux.org/title/Docker#Installation , verify you do have those services running and basic docker functionality works .
The problem is that when I launch a container and I bind mount a folder, the user in the container cannot write in the folder, whether the container manager is docker or podman.
What is the exact command that you use to bind-mount the folder and what does it output on terminal/log-files ?

Hi, I've uninstalled docker, and now I have only podman installed via pacman. I reproduce here the steps and the output of what I have with podman. In case, tell me and I will try to install docker via pacman and try also with that, but I seriously doubt that the result will change (since I had the exact same output.

Configuration:
- my user on host has id 1000
- the folder I want to bind mound is called "data", and contains 2 files "titi", "toto":

$ ls data -la
total 8
drwxr-xr-x 2 marco marco 4096 21 ott 22.20 .
drwxr-xr-x 3 marco marco 4096 25 nov 19.22 ..
-rw-r--r-- 1 marco marco    0  4 set 10.55 titi
-rw-r--r-- 1 marco marco    0 20 ago 13.09 toto

- my host user can access the folder and read/write on it and its files. For instance, this is some exampleo utput

$ mkdir data/try && ls -la data && rm -r data/try && echo && ls -la data
total 12
drwxr-xr-x 3 marco marco 4096 25 nov 19.26 .
drwxr-xr-x 3 marco marco 4096 25 nov 19.22 ..
-rw-r--r-- 1 marco marco    0  4 set 10.55 titi
-rw-r--r-- 1 marco marco    0 20 ago 13.09 toto
drwxr-xr-x 2 marco marco 4096 25 nov 19.26 try

total 8
drwxr-xr-x 2 marco marco 4096 25 nov 19.26 .
drwxr-xr-x 3 marco marco 4096 25 nov 19.22 ..
-rw-r--r-- 1 marco marco    0  4 set 10.55 titi
-rw-r--r-- 1 marco marco    0 20 ago 13.09 toto

- Output of "ls" in the folder containing the Dockerfile and the "data" folder

$ ls
bindmount.sh  data  Dockerfile

- content of the Dockerfile

FROM debian:latest
ARG username=stduser
RUN useradd ${username}
USER ${username}

- content of the script

#!/bin/bash
podman build -t trymount:v1.0 .
podman run -ti --mount type=bind,src=./data,target=/home/stduser --name c1 trymount:v1.0

What I do:
- I launch the script, so a shell opens in the container. These are the commands I run, with their output

stduser@66d455349cf3:/$ cd ~
stduser@35cb8d38c5e8:~$ ls -la
total 4
drwxr-xr-x 2 root root 4096 Oct 21 20:20 .
drwxr-xr-x 1 root root   14 Nov 25 18:22 ..
-rw-r--r-- 1 root root    0 Sep  4 08:55 titi
-rw-r--r-- 1 root root    0 Aug 20 11:09 toto
stduser@66d455349cf3:~$ mkdir trial
mkdir: cannot create directory 'trial': Permission denied
stduser@66d455349cf3:~$ whoami
stduser
stduser@66d455349cf3:~$ id 
uid=1000(stduser) gid=1000(stduser) groups=1000(stduser)
stduser@66d455349cf3:~$

I cannot detect anything suspicious that justifies the "Permission denied" error when I try to create a folder. I suspect this is something beyond docker/podman because it applies to both. Maybe it is system-wide, but it does not apply to distrobox (a sort of container manager that uses podman as backend). If you have any suggestion, I am all ears

seth · 2024-11-26 18:37:25

You mean besides "stduser" tries to write into a directory that is 755 and owned by the root?

Does

podman run -ti --mount type=bind,src=./data,target=/home/stduser,U=true --name c1 trymount:v1.0

help?
https://man.archlinux.org/man/extra/pod … n-run.1.en

Splashy3852 · 2024-11-29 18:49:13

seth wrote:

You mean besides "stduser" tries to write into a directory that is 755 and owned by the root?
Does
podman run -ti --mount type=bind,src=./data,target=/home/stduser,U=true --name c1 trymount:v1.0
help?
https://man.archlinux.org/man/extra/pod … n-run.1.en

Thanks! This helps! Let me show you the outcome:

$ podman run -ti --mount type=bind,src=./data,target=/home/stduser,U=true --name c1 trymount:v1.0
stduser@2974baeaf1b9:/$ cd ~
stduser@2974baeaf1b9:~$ ls
titi  toto
stduser@2974baeaf1b9:~$ mkdir trial
stduser@2974baeaf1b9:~$ touch example
stduser@2974baeaf1b9:~$ ls -la
total 8
drwxr-xr-x 3 stduser stduser 4096 Nov 29 18:44 .
drwxr-xr-x 1 root    root      14 Nov 29 18:43 ..
-rw-r--r-- 1 stduser stduser    0 Nov 29 18:44 example
-rw-r--r-- 1 stduser stduser    0 Sep  4 08:55 titi
-rw-r--r-- 1 stduser stduser    0 Aug 20 11:09 toto
drwxr-xr-x 2 stduser stduser 4096 Nov 29 18:44 trial
stduser@2974baeaf1b9:~$

Now the question is, why do I need to specify U=true here, while on the other installation I do not?
I am sorry if the question sounds silly: I am using containers since not so long, and the documentation only talks about ports, so I am not sure why this is realted to folder/file permissions.
Also, do you know by any chance how can I enable automatically this option in visual studio? I am not sure how to do it (and if you do, I would be very grateful )

Last edited by Splashy3852 (2024-11-29 18:50:37)

seth · 2024-11-29 19:05:36

Sorry, I've never used visual studio (well, ok I did: 25 years ago) but if you're comparing the behavior of it amongst the installations, it stands to reason that most likely one of them will pass that - or ubuntu has simply patched podman to flip some defaults.

Does ubuntu chown the directory to "stduser" w/o explicitly setting "U=true"?

Splashy3852 · 2024-11-29 19:19:45

Yes, in Ubuntu 22.04 it worked out of the box, and also the Visual studio setup.

Basically, in Visual studio, a container is launched starting from a dockerfile to develop inside the container, with the folder of the project bind-mounted. Therefore, your suggestion works great for the general use case. However, now I need to figure out if there is a way to set tue U=true behaviour on all containers somehow; in order for visual studio not need any specifications, as they're not needed in Ubuntu 22.04 for both the use cases.

I hope my message is clear: let me know if you have any question concerning my issue

seth · 2024-11-29 19:36:56

I understand your message but have really no idea how to configure VS.
What I've asked though is whether Ubuntu actually ended up w/ a chowning the directory or maybe does sth. entirely different.

However: https://stackoverflow.com/questions/762 … permission

Splashy3852 · Today 11:05:31

seth wrote:

I understand your message but have really no idea how to configure VS.
What I've asked though is whether Ubuntu actually ended up w/ a chowning the directory or maybe does sth. entirely different.
However: https://stackoverflow.com/questions/762 … permission

Hi, I'm sorry if my answer was not clear. I meant that yes,on Ubuntu I do not have to specify that I chown the directory. Also, on the sources from which I learned docker (at least, my limited knowledge), people were bind-mounting folders without that option, so I thought it was something not to worry about.

My point was that I do not know what happens in Arch and Ubuntu, but I'd like to have a configuration in which each container manager (podman or docker) can bind mount folders giving for granted that the user in the container has chown permissions on the directories. This would solve the issue with VScode (and also CLion, since I tried also that, with the same outcome).

P.S. I think I solved the issue. I will test the configuration for a few days, then, mark it as solved and put the solution in the first message. I followed the suggestions in the URL you provided, by adding:

"remoteUser": "vscode",
"containerUser": "vscode",

(vscode is the rootless user in the image) in

devcontainer.json

Then, I installed docker:

sudo pacman -S docker docker-compose
sudo dockerd
docker context use default
docker info # checking if it works properly

Next, I made VScode to rebuild the container by using docker. It built the container, and the permissions were fine. After the build, it edited the

devcontainer.json

by adding

"--mount type=bind,src=.,target=/home/vscode,U=true",

to the

runArgs

list.

I will test this configuration for a few days, and a few containers, and finally close this issue Thanks for the insights! Still, if anyone has a clue why this works effortlessly on Ubuntu, I'd like to hear that

Last edited by Splashy3852 (Today 11:10:47)

seth · Today 15:08:43

if anyone has a clue why this works effortlessly on Ubuntu, I'd like to hear that

Different container, posix incompatible filesystem or ubuntu applied some downstream patch to get the ",U" in there by default?

on Ubuntu I do not have to specify that I chown the directory

does not address

seth wrote:

What I've asked though is whether Ubuntu actually ended up w/ a chowning the directory or maybe does sth. entirely different.

Look at the actual file and directory permissions - it's impossible to tell why things might be different w/o even knowing *what* is different.

Splashy3852 · Today 16:41:33

Sorry again for misunderstanding the question. I think that I misunderstood because I cannot answer now: in fact I do not have anymore that laptop with Ubuntu to check that information; for that I can only tell that I did not have to worry about explicitly chowning before.

Last edited by Splashy3852 (Today 16:42:14)

Arch Linux

#1 2024-11-17 21:58:05

Container's user does not have write permissions in bind-mounted folde

#2 2024-11-18 10:30:16

Re: Container's user does not have write permissions in bind-mounted folde

#3 2024-11-19 19:14:30

Re: Container's user does not have write permissions in bind-mounted folde

#4 2024-11-25 18:29:12

Re: Container's user does not have write permissions in bind-mounted folde

#5 2024-11-26 18:37:25

Re: Container's user does not have write permissions in bind-mounted folde

#6 2024-11-29 18:49:13

Re: Container's user does not have write permissions in bind-mounted folde

#7 2024-11-29 19:05:36

Re: Container's user does not have write permissions in bind-mounted folde

#8 2024-11-29 19:19:45

Re: Container's user does not have write permissions in bind-mounted folde

#9 2024-11-29 19:36:56

Re: Container's user does not have write permissions in bind-mounted folde

#10 Today 11:05:31

Re: Container's user does not have write permissions in bind-mounted folde

#11 Today 15:08:43

Re: Container's user does not have write permissions in bind-mounted folde

#12 Today 16:41:33

Re: Container's user does not have write permissions in bind-mounted folde

Board footer