Using the generated docker context `desktop-linux`, files are always mounted as root user and not custom user set in Docker file

[TristanPouliquen]

• [x] This is a bug report
• [ ] This is a feature request
• [x] I searched existing issues before opening this one

Expected behavior

Hello, we have a set of containers built with Docker Compose for our code. In our Dockerfile, we create a custom user, assigning it to the 1000 UID.

When running docker compose up in the default context (with the socket in /var/run/docker.sock), our codebase is correctly mounted to the containers using our custom user.

We want to use Docker Desktop for Linux to unify our Docker management through Windows & Linux.

We expected to be able to install Docker Desktop, build our containers, launch them, see them in the interface & be able to continue coding normally.

Actual behavior

When switching to the newly generated desktop-linux context, we correctly see our containers in the application interface.

BUT

When we build & launch our containers with docker compose up, the files from our codebase are mounted under the root:root ownership.

We are then unable to correctly install dependencies through Composer, Yarn, or to navigate in our app as we get permission errors every time we try to acces/write to a file.

Steps to reproduce the behavior

I will try to generate a minimum reproduction example

Output of docker version:

Client: Docker Engine - Community
 Cloud integration: v1.0.24
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        100c701
 Built:             Mon Jun  6 23:02:57 2022
 OS/Arch:           linux/amd64
 Context:           desktop-linux
 Experimental:      true

Server: Docker Desktop 4.10.1 (82475)
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:01:23 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc:
  Version:          1.1.2
  GitCommit:        v1.1.2-0-ga916309
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
  compose: Docker Compose (Docker Inc., v2.4.1)
  extension: Manages Docker extensions (Docker Inc., v0.2.7)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 7
  Running: 5
  Paused: 0
  Stopped: 2
 Images: 15
 Server Version: 20.10.17
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc version: v1.1.2-0-ga916309
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 3.701GiB
 Name: docker-desktop
 ID: I6M7:DU7C:BNS7:YX25:3YWH:UG2U:SA7V:2GYN:WJFB:IKGQ:SWIR:JPWR
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.)

[alec-w]

I'm experiencing the exact same issue (docker desktop for linux on Ubuntu). Attempting chown -R dev:dev . in the working directory in the container gives them the correct ownership in the container, but assigns them to non-existent uid/gid on the host. On the host executing chown -R alec:alec . reverts them to the correct ownership on the host but back to root:root in the container.

Are there any workarounds known for this yet?

[rgegriff]

@alec-w So, as far as I understand it, the fact that the files in bind mounts are being mounted as root:root is a bug in docker desktop for linux. You can also see this related in https://github.com/docker/desktop-linux/issues/81 and various other bugs in the docker-compose repo as well.

The fact that chowned files get a high numbered UID:GID is actually, unfortunately, by design as far as I can tell. Its because of the use of VirtioFS running under a non-root user so it's using user namespaces to map the host user to uid 0 inside the container, and all other userids to whatever mapping is defined in /etc/subuid.

The upshot of this is that if you try to use mounted volumes in Docker Desktop with the containers that you lovingly crafted to avoid running as root by default with, you end up in kind of a mess. I haven't had a chance to test the scenario with Docker Desktop on mac using VirtioFS yet, but I am hoping not, otherwise it's going to be a bit of a mess if they make VirtioFS the only storage driver.

You can find some more info about this behavior at https://docs.docker.com/desktop/faqs/linuxfaqs/#how-do-i-enable-file-sharing

[angelbt91]

Having the exact same problem detailed above. Is there any known fix or workaround for this?

[rgegriff]

The best plan I have is to make a container with a root user, and do docker-in-docker inside THAT container to run the actual service containers with the expected user/file permissions

On Fri, Feb 17, 2023 at 7:15 AM Ángel Blanco @.***> wrote:

Having the exact same problem detailed above. Is there any known fix or workaround for this?

— Reply to this email directly, view it on GitHub https://github.com/docker/desktop-linux/issues/149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB45OVBSWMDOQTQ4AGQJZ3WX5TVJANCNFSM53VZ377A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[VultyDev]

Same issue here. I have to manually switch my docker context to use the "default one" docker context use default But I have to do that on each reboot, and can't use the "beautiful" docker desktop interface

[kashifm14]

I am also running into the same issue. Using VirtioFS leads to better performance but diverges the functionality of Docker desktop in Linux from Windows or Mac. That is not ideal.

While using the docker desktop we get a different way in how the volumes are mounted, in that the host user files are mounted as root (0)user inside the container. But when we use default docker, we do not run into such issues, the host uid is the same as the container user uid when we mount the volume.

Is there any plan to fix this inconsistency?

[thaJeztah]

Let me transfer this ticket to the docker desktop for linux issue tracker

[this-santhoshss]

@thaJeztah where was this issue moved to? I cannot see were it was moved to. I am running into the same issue.

[apederse]

I can confirm that this issue is still present in Docker Desktop for Linux. After spending a lot of time to find the cause and potential work-arounds for the issue, I was very happy to finally find this issue filed by @TristanPouliquen The paradox is that the reason to choose Docker Desktop in the first place was to get a user-friendly way of dealing with root-less Docker.... I am really surprised that this issue has not attracted more attention as it makes Docker Desktop on Linux useless. I guess people are just reverting to the Docker Engine. @thaJeztah Have there been any efforts or plans to solve the issue??