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:
#1243
#992
#673
#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.