Hi, @caiodelgadonew
In the built-in docker template, we switched to a docker image resource to pull a pre-built image instead of building from the Dockerfile. This pre built image has a user with the name coder.

@phorcys420 can you take a look?

Hi, @caiodelgadonew In the built-in docker template, we switched to a docker image resource to pull a pre-built image instead of building from the Dockerfile. This pre built image has a user with the name coder.

@phorcys420 can you take a look?

That makes a lot of sense, I was checking also the terraform providers for coder & docker and couldn't find anything related, codercom/enterprise-base and assumed on 2.17 was the same.

hey @caiodelgadonew, thanks for the heads-up.

The fact that the user is not being created is intended since we've switched to the generic coder user to avoid having to rebuild the image for every user.

See #15504 for the change that caused the issue, by switching from building a Dockerfile with a USER parameter to our enterprise-base image with the generic coder user, we kept persisting /home/<coder username> instead of the new /home/coder, so the persistent volume is not being created for the right folder.

I will be rolling out a fix soon, but in the meantime you can replace L198's contents by container_path = "/home/coder" in your template like this:

resource "docker_container" "workspace" {
  # [...]

  volumes {
-   container_path = "/home/${local.username}"
+   container_path = "/home/coder"
    volume_name    = docker_volume.home_volume.name
    read_only      = false
  }
}

@phorcys420 that fix on line 198 was what I did to fix it temporarily, not sure about the approach of the generic user, I personally like the idea of the username to match the container user

@phorcys420 that fix on line 198 was what I did to fix it temporarily, not sure about the approach of the generic user, I personally like the idea of the username to match the container user

I agree that it feels more personalized but building the image in-template caused an anti-pattern and made things slower overall.

The issue with having a user created after the build time is that the tools are installed as the coder user in the image.
This causes:

• Slow build times
• Impossible to use cache for the layers coming after ARG USER because every command will depend on that specific username, which will also end up polluting the image storage

Now you could say that the coder user could then be renamed at runtime, and you'd be right, but the issue with this is that the software that's being installed in the image will likely still refer to /home/coder so you'd have to either create a symlink that points to /home/<username>, or do a find-and-replace, both approaches are hacky and will likely cause problems.

Another thing, how do you handle a user changing their username without running into the same problems?

All these are reasons that make it unsuitable for an example template, because it will cause issues if the template admin is unaware of it.
That said, you are free to edit the template to do this.

Gotcha @phorcys420 , all valid points.

I think your solution makes more sense.

Thanks!

Thanks, @caiodelgadonew, for reporting this. This is going to be live in the upcoming release 2.19 (4th of Feb.) and the 2.18.4 patch (Date to be decided).