Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filesystem user mapping different than Docker Desktop #2514

Open
jsedano-emobg opened this issue Jul 11, 2022 · 15 comments
Open

Filesystem user mapping different than Docker Desktop #2514

jsedano-emobg opened this issue Jul 11, 2022 · 15 comments
Labels
area/volume Access to host volumes from inside the VM or containers kind/bug Something isn't working parity/project Feature is available from other projects platform/macos triage/need-to-repro Needs to be reproduced by dev team

Comments

@jsedano-emobg
Copy link

Actual Behavior

When using the VSCode remote-container plugin to open a project in-container, the files are owned by the external user instead of root. That is: file owning is not mapped from outside to inside.

I am creating this as a bug because in Docker Desktop for Mac the filesystem user is mapped from the local user to root, but in Rancher Desktop for Mac, it is not; since I understand we want to mimic this kind of behaviours from DD, I think it may be a bug

Also, it MAY be a bug in VSCode remote-container extension, but since it works on Docker Desktop, looks like the problem is in Rancher Desktop.

Steps to Reproduce

I have created a simple test repository reproducing the error at https://gitlab.com/javier-sedano/user-map/-/tree/master

  1. Clone the repo
  2. Install VSCode (I am using 1.69.0 for Mac) and "remote - containers" (I am using 0.241.3)
  3. Open the cloned folder in VSCode
  4. It will offer to "Reopen in container"; do it

Result

I see the following in a VSCode terminal:

root@61970ae95f98:/app# ls -lan
total 16
drwxr-xr-x 1 502 20  160 Jul 11 10:09 .
drwxr-xr-x 1   0  0 4096 Jul 11 10:07 ..
drwxr-xr-x 1 502 20  192 Jul 11 10:09 .devcontainer
drwxr-xr-x 1 502 20  384 Jul 11 10:10 .git
-rw-r--r-- 1 502 20    0 Jul 11 10:09 README.md
root@61970ae95f98:/app# git checkout
fatal: unsafe repository ('/app' is owned by someone else)
To add an exception for this directory, call:

        git config --global --add safe.directory /app
root@61970ae95f98:/app# 

Notice how files are owned by 502, which is my user in the host (my Mac).

This causes modern git to fail (causing the git view of VSCode to fail), for example, but other things fail as well.

My files in the host, outside the container:

javier.sedano@MacBook-Pro-de-admeis user-map % ls -lan
total 0
drwxr-xr-x   5 502  20  160 Jul 11 12:09 .
drwxr-xr-x  10 502  20  320 Jul 11 12:09 ..
drwxr-xr-x   6 502  20  192 Jul 11 12:09 .devcontainer
drwxr-xr-x  12 502  20  384 Jul 11 12:10 .git
-rw-r--r--   1 502  20    0 Jul 11 12:09 README.md
javier.sedano@MacBook-Pro-de-admeis user-map % 

Expected Behavior

When using Docker Dektop for Mac, and following the same procedure, the following is shown in the terminal:

root@0036fc4efb35:/app# ls -lan
total 4
drwxr-xr-x  5 0 0  160 Jul 11 10:20 .
drwxr-xr-x  1 0 0 4096 Jul 11 10:21 ..
drwxr-xr-x  6 0 0  192 Jul 11 10:20 .devcontainer
drwxr-xr-x 12 0 0  384 Jul 11 10:20 .git
-rw-r--r--  1 0 0    0 Jul 11 10:20 README.md
root@0036fc4efb35:/app# git checkout
Your branch is up to date with 'origin/master'.
root@0036fc4efb35:/app#

And outside the container:

➜ user-map git:(master) ls -lan
total 0
drwxr-xr-x  [5 1425016936](tel:51425016936) 686672032 160 11 jul 12:20 .
drwxr-xr-x  [7 1425016936](tel:71425016936) 686672032 224 11 jul 12:20 ..
drwxr-xr-x  [6 1425016936](tel:61425016936) 686672032 192 11 jul 12:20 .devcontainer
drwxr-xr-x [12 1425016936](tel:121425016936) 686672032 384 11 jul 12:22 .git
-rw-r--r--  [1 1425016936](tel:11425016936) 686672032  0 11 jul 12:20 README.md

Additional Information

No response

Rancher Desktop Version

1.4.1

Rancher Desktop K8s Version

Disabled (1.22.7)

Which container runtime are you using?

moby (docker cli)

What operating system are you using?

macOS

Operating System / Build Version

12.3.1 Monterey

What CPU architecture are you using?

arm64 (Apple Silicon)

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

No response

@jsedano-emobg jsedano-emobg added the kind/bug Something isn't working label Jul 11, 2022
@jsedano-emobg
Copy link
Author

Anybody any news about this topic?

@jsedanoj
Copy link

I have upgraded to Rancher Desktop 1.5.1 and VSCode 1.71.1 with "remote - containers" 0.251.0and nothing has changed, the problem is still there.

@jandubois jandubois added platform/macos area/volume Access to host volumes from inside the VM or containers labels Sep 16, 2022
@jandubois
Copy link
Member

Anybody any news about this topic?

Sorry, there is no news yet; we haven't gotten around to looking into this issue yet.

@jandubois jandubois added this to the Later milestone Sep 16, 2022
@jsedanoj
Copy link

I have simplified the test case, definitely it has nothing to do with VSCode.

When I run this command using Docker Desktop for Mac (M1), using the straightforward Next-Next-Next setup, I get:

javier.sedano@MacBook-Pro-de-admeis test-user-map % docker run -v /Users/javier.sedano/tmp/test-user-map/test-dir/:/test-dir --rm -ti alpine ls -lan /test-dir
total 4
drwxr-xr-x    3 0        0               96 Sep 16 09:57 .
drwxr-xr-x    1 0        0             4096 Sep 18 09:50 ..
-rw-r--r--    1 0        0                0 Sep 16 09:57 hello.txt
javier.sedano@MacBook-Pro-de-admeis test-user-map % 

When I run the same command in Rancher Desktop for Mac (M1) 1.5.1, using dockerd/moby (docker cli), I get:

javier.sedano@MacBook-Pro-de-admeis test-user-map % docker run -v /Users/javier.sedano/tmp/test-user-map/test-dir/:/test-dir --rm -ti alpine ls -lan /test-dir
total 8
drwxr-xr-x    1 502      20              96 Sep 16 09:57 .
drwxr-xr-x    1 0        0             4096 Sep 18 09:58 ..
-rw-r--r--    1 502      20               0 Sep 16 09:57 hello.txt
javier.sedano@MacBook-Pro-de-admeis test-user-map % 

Switching to containerd (nerdtcl cli) does not change the result:

javier.sedano@MacBook-Pro-de-admeis test-user-map % nerdctl run -v /Users/javier.sedano/tmp/test-user-map/test-dir/:/test-dir --rm -ti alpine ls -lan /test-dir
total 8
drwxr-xr-x    1 502      20              96 Sep 16 09:57 .
drwxr-xr-x    1 0        0             4096 Sep 18 10:00 ..
-rw-r--r--    1 502      20               0 Sep 16 09:57 hello.txt
javier.sedano@MacBook-Pro-de-admeis test-user-map % 

What is surprising to me is... this looks like a pretty straightforward run... I can't believe I am the first person finding the issue...

@jsedano-emobg
Copy link
Author

After updating to Rancher Desktop 1.6.0, still no change.

@jsedano-emobg
Copy link
Author

Updated to 1.7.0 still no change.

Is anybody tracking the bug?

@jsedano-emobg
Copy link
Author

I have upgraded to 1.8.1, it still fails.

@jsedanoj
Copy link

Upgraded to 1.9.1... it still fails

@jandubois jandubois added parity/platform Feature is available on other supported platforms triage/need-to-repro Needs to be reproduced by dev team labels Jul 31, 2023
@jandubois jandubois removed this from the Later milestone Sep 15, 2023
@jsedano-emobg
Copy link
Author

I Tested 1.10.1... no change.

I bet nobody is working on it. I see @jandubois has tagged with "need-to-repro"... Do you want us to have a meeting so I show you the failure?

@jandubois
Copy link
Member

I see @jandubois has tagged with "need-to-repro"... Do you want us to have a meeting so I show you the failure?

The label means it is in the queue for somebody from the team to reproduce it locally (and ideally write a BATS test for it), but you are correct, in that nobody has worked on it yet. Once we repro it, it will be put into the backlog. If we can't repro it, we'll be asking more questions here.

Sorry for the long delay, it is definitely something I would like to see addressed, but we didn't have somebody available to repro/analyze it yet. 😞

@jandubois jandubois added parity/project Feature is available from other projects and removed parity/platform Feature is available on other supported platforms labels Oct 27, 2023
@jsedano-emobg
Copy link
Author

Tested 1.11.1, no difference.

@jsedano-emobg
Copy link
Author

Tested 1.13.1, no change, it still fails.

@jsedano-emobg
Copy link
Author

Tested with 1.14.2, no change, it still fails.

@christopherb
Copy link

This appears to be due to the default volume mount type. I had the same issue when using the default rancher desktop settings. I changed the emulation to VZ and the volumes to virtiofs and it now correctly remaps.

@jsedano-emobg
Copy link
Author

Cool!

I thinks this is "only" a workaround, because I think the default behaviour should be "like-DockerDektop". Also, the 2 features you name ara tagged as "experimental" in RancherDesktop, which makes it a little scary. But it works:

javier.sedano@WMACBCN069001 test-user-map % docker run -v /Users/javier.sedano/tmp/test-user-map/test-dir/:/test-dir --rm -ti alpine ls -lan /test-dir
total 4
drwxr-xr-x    3 0        0               96 Sep 16  2022 .
drwxr-xr-x    1 0        0             4096 Sep 20 06:32 ..
-rw-r--r--    1 0        0                0 Sep 16  2022 hello.txt
javier.sedano@WMACBCN069001 test-user-map % 

It seems to work for Visual Studio Code dockerized environment, because it was my initial report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/volume Access to host volumes from inside the VM or containers kind/bug Something isn't working parity/project Feature is available from other projects platform/macos triage/need-to-repro Needs to be reproduced by dev team
Projects
None yet
Development

No branches or pull requests

4 participants