Code-server: Failed to run docker container

[hibare]

Getting following error when try to run docker command specified in README.md file.

error EACCES: permission denied, mkdir '/home/coder/.local/share/code-server/extensions'

Tried on elementary os and on actual UBUNTU server

[realthk]

Same here. Seems the reccommended Docker command from the readme

docker run -it -p 127.0.0.1:8080:8080 -v "${HOME}/.local/share/code-server:/home/coder/.local/share/code-server" -v "$PWD:/home/coder/project" codercom/code-server:v2

creates ~/.local/share/code-server folder with root user and drwxr-xr-x, so no other user can write into it.

Therefore a simple solution is

sudo chown $USER ~/.local/share/code-server/

[githubsaturn]

Why this is happening:
This is the result of unnecessary result of user demotion in the Dockerfile:
https://github.com/cdr/code-server/blob/master/Dockerfile#L45

When the source directory doesn't exist, Docker automatically creates it and the "owner" will be the root user. Due to the user demotion mentioned above, code-server isn't able to put any content inside that folder.

I'd like to ask maintainers of code-server to fix this, as this is definitely an annoying problem because it simply prevents users to use simple named volumes.

Solutions:
1- Why do we demote the user to a non-root inside the container? There is nothing inside the container that it's accessible by root but not the non-root. It only cause problems.

2- Change the CMD script such that it checks if the permissions isn't correct, it sudo changes it.

I am happy to help out with this.

The main benefit of using Docker is portability, but this permission assumption breaks the portability principal of Docker containers.

[githubsaturn]

As you can see this issue has been encountered by many users:
https://github.com/cdr/code-server/issues/1243
https://github.com/cdr/code-server/issues/992
https://github.com/cdr/code-server/issues/673
https://github.com/cdr/code-server/issues/1188
and many more.

[demyxco]

The simplest fix would be to create the directories before switching user. If you look at their Dockerfile at lines 48-50, it's being created as root without chowning to the coder user.

Scratch what I said, I didn't read between the lines. code-server works fine if using named volumes but if you use bind mounts (aka mount a directory from host to container), then that directory has to be chowned by uid:guid 1000.

[sr229]

Why this is happening:
This is the result of unnecessary result of user demotion in the Dockerfile:
https://github.com/cdr/code-server/blob/master/Dockerfile#L45

When the source directory doesn't exist, Docker automatically creates it and the "owner" will be the root user. Due to the user demotion mentioned above, code-server isn't able to put any content inside that folder.

This is incorrect. whatever runs in USER will run anything in below it as the user. The reason of this is because the bind mounted folder has a different permission scheme than in the container. This is why we'll need to add chmod -R g+rw in the project mount folder (which was multiple times were rejected, but I'll be taking over the Dockerfile maintenance from now on).

Solutions:
1- Why do we demote the user to a non-root inside the container? There is nothing inside the container that it's accessible by root but not the non-root. It only cause problems.

This will create a "close to a real environment" scenario for beginning users. Not everyone has done Linux/Unix before so we should teach them best practices - and that starts with that root is always dangerous to use if you're ignorant of how powerful the superuser account is. This also increases compatibility with Kubernetes and OpenShift - which enforces user-only containers. This is considered best practices.

[githubsaturn]

This is incorrect. whatever runs in USER will run anything in below it as the user. The reason of this is because the bind mounted folder has a different permission scheme than in the container. This is why we'll need to add chmod -R g+rw in the project mount folder (which was multiple times were rejected, but I'll be taking over the Dockerfile maintenance from now on).

It's not incorrect. Remove the line that highlighted and things work fine.

Regardless, offloading the responsibility of fine tuning the directory permissions to the user in Docker environment isn't considered a fix.

With regards to root user, I agree. But any dangerous action, should be contained within the container. Having said that, it'd be suboptimal solution. It'd be better to fix the root cause which is the permission for the directory.

[sr229]

@githubsaturn this is considered BAD practice. It might not be for you but it is bad practice.

This is not a fix, we know it works already but the problem is the permissions we need to apply to the folder, because even if we own them, the bindmounted folder inheirts the host folder's permissions.

We're not discussing about this any further. Whether you like it or not, your solution is NOT a solution. This is non-compliant and is considered insecure.

[githubsaturn]

You misread what I said:

Having said that, it'd be suboptimal solution. It'd be better to fix the root cause which is the permission for the directory.

[code-asher]

There might be some confusion here because that's not the Dockerfile
used to deploy in the CI. We need to add the missing mkdir line to the
Dockerfile used by the CI then the directory will be owned by coder.

The reason it was split out was so we could just deploy with the binary
built in the CI rather than having to build it yet again, mostly because
nothing was getting cached inside the Docker container so the build was
taking a long time.

We should definitely do something about the duplication. Let's take a
look at this while we work on the Drone migration.

[code-asher]

And to be clear that would just fix the need to run chown inside the
container. It doesn't do anything for the separate issue of the user
outside of Docker having an ID other than 1000 which I think is what
some of these other issues are about?

[hibare]

What would be the best workaround to get the container up and running?

[code-asher]

Could you try out the 2.1698 image and see if it works?

[sandercuppen]

I tried 2.1698, and it works fine for me, with named volumes.
Before, with named volumes or bind mounts i had permission issues.

[haliliceylan]

@code-asher

another error...

[sr229]

@code-asher

another error...

It does not show the full extent of the error.

[nhooyr]

Given the amount of people that have had this issue, I think we need a FAQ entry on what exactly is going on. I'll dedicate some time tomorrow.

[sr229]

Marking as docs.

[haliliceylan]

@code-asher

another error...

It does not show the full extent of the error.

There is no other error output on my console.

[nhooyr]

So we need to get rid of -v from the docker command since it doesn't make sense as the container runs as uid 1000 but the cache directory is created as root by default.

I think it's fine if the container command we advertise keeps the cache in the container so its sandboxed but we ought to have a FAQ entry to document where code-server keeps its state.

[sthulb]

@code-asher

another error...

It does not show the full extent of the error.

There is no other error output on my console.

I think this is a different issue! I've been trying to run the latest binary on an Ubuntu EC2 instance and receive the same error.