EACCES: permission denied, mkdir '/tmp/vsch

[hholst80]

• VSCode Version: 1.42
• Local OS Version: Arch (Linux)
• Name of Dev Container Definition with Issue: Try node example

Steps to Reproduce:

1. Run VSCode + example as user id=1000
2. Run VSCode + example as user id=1001
3. VS Code server is downloaded (attempted) to /tmp/vsch/... but /tmp/vsch is not owned by uid=1001 which does not have permissions to write to that directory. This would be fixed if each user had its own tmp directory.

Suggested fix:

Use mktemp with a template prefix of /tmp/.vsch-#########.

Note from the future: This will not be a problem in a better world where each application and each user has its own /tmp directory.

[chrmarti]

We could try to use fs.mkdtemp. The problem with that is that it appends a random prefix and we want to use the folder as a cache across sessions.

It seems we should move the cache folder to the user data dir since we want it to persist across system restarts.

[hholst80]

That seems like a much reasonable approach. It must be fair to make some assumptions on the environment inside the Docker, like XDG Base Directory compliance.

[kapsner]

+1

Still happens with VSCode 1.60.2 on Ubuntu.

Any updates on this?

[xuyq19]

Still happens with VSCode 1.62.2 on Windows.

[tepene]

Having the same issue. Are there any plans to move the cache folder to the user dir?

[tlzAny]

Same issue here.. Would be great to have a fix for this!

[Uguudei]

Same issue in 1.63.0. Multiple users can not reopen container from Remote-SSH. I see that vscode-typescript has following directories in /tmp.
vscode-typescript1001
vscode-typescript1004
vscode-typescript1005

It seems a neat solution:
vsch-1001
vsch-1002

Any update on this?
Anyone has workaround for this? like changing permission of directory?

[mcw8d]

I ran into this issue earlier in the year while supporting a group of developers logging in to a shared server through VNC and using the Remote Containers extension. At the time, I figured out that VSCode honors the linux TMPDIR environment variable, so I had the developers set up a custom launcher that created a /tmp/$USER directory and set TMPDIR=/tmp/$USER before launching code. The full launcher command looks like bash -c "mkdir -p /tmp/$USER; TMPDIR=/tmp/$USER /usr/share/code/code --unity-launch %F"
As of Remote Containers 0.205.50 it looks like if you are using a remote docker host, then the creation of /tmp/vsch now happens through ssh on the remote server. We use a shared server as a docker host and have now run into this issue again there. I was able to workaround it with TMPDIR again by adding

mkdir -p /tmp/$USER
export TMPDIR=/tmp/$USER

to my .bashrc on the remote docker host.

I hope these workarounds help anyone else running into this issue while we wait for a permanent fix. I don't have much experience with running this extension on Windows, so I don't know how well this translates to that environment.

[maciek16180]

I also have this issue. A fix would be welcome.

[OliverWannenwetsch]

Hello, we also have this issue. We are sharing workstations and we like to run different VSCode containers concurrently with different users.

[Christopher22]

I would love to see that fixed, too! Our team just ran into the same issue.

[chuanqisun]

+1, please fix.

I'm using vscode over SSH connection. It worked just fine for myself but after adding another user to the host, we ran into this permission error. I feel this would block people from sharing their dev environment. It feels reasonable for the server-client architecture to handle multiple clients by different users.

[fredheidrich-aurizon]

Running into this issue on a remote shared server as well. Changing TMPDIR to something for every user worked as a workaround for us as well.

[OXINARF]

Really hopping this doesn't continue slipping through milestones and gets fixed, it is a quite annoying bug.

[AngelOnFira]

Same as @mcw8d, I have a group of students that are all using the same host for dev projects this summer. I'm going to try some of these solutions, but I'd love a fix :)

[vasudev-sharma]

Encountered same error, a fix to this issue would be really appreciated.

[akanwischer]

I add a +1 for me, as I was now facing the same problem with a colleague.

[chrmarti]

Fixed in Remote-Containers v0.241.1-pre-release. Let me know if that works for you. Thanks.

[aeschli]

Verified that I now get a temp folder with my user id: /tmp/vsch-martin/