2

I'm using the gcloud compute instances create-with-container tool to create a VM in GCE where I want to run a docker image. For this i'm using one of google's container-optimized OS images. I'm trying to attach a disk because I need to have persistent data in my docker container. For that, i'm using the --container-mount-disk flag.

The problem I'm having is that the disk gets mounted as a folder owned by root inside the docker container (and in the host VM) and my container process cannot write to it. Is there a way to fix this? I tried using --container-mount-host-path as well without luck. I tried connecting to the docker host and chowning the folder to the uid of the user in the docker container, but the moment the VM gets recreated, the folder is again owned by root so this is not a permanent solution.

In short, how is this --container-mount-disk feature supposed to be used with non-root users inside the docker container?

Hilikus
  • 9,954
  • 14
  • 65
  • 118
  • In your tests, assuming you mounted to /app ... did the directory /app already exist? If so, who owned it and with what permissions? If you don't already have a /app directory, what if you created it in your image and used that for your container? Would that make a distinction? – Kolban Oct 16 '19 at 03:23
  • when you say "did the directory already exist" you mean as part of the image? or you mean in the running container in my test? If the former, I don't know, I think it's defined as a volume in the dockerfile. If the latter, yes, the folder does exist. Owned by root with permissions drwxr-xr-x – Hilikus Oct 16 '19 at 03:30
  • this is the image https://hub.docker.com/r/sonatype/nexus3 – Hilikus Oct 16 '19 at 03:31
  • My thinking is that if you mount a volume at /app in the container and that directory (/app) doesn't exist, docker may create it, owned by root with permissions 755. What I think I'm hearing you say is that you either want /app owned by a different user with permissions 755 or still owned by root with more permissive permissions (eg. 777). What I'm wondering ... does the mount point (/app) need to pre-exist with the desired permissions in the image from which the container instance is created? – Kolban Oct 16 '19 at 04:08
  • 1
    How did you partition and format the Google disk that you are attaching with the `container-mount-disk` command? Most likely the file system on the disk is owned by root and you have not set up the permissions on the file system for additional users (non-root users). Connect to the container with bash. Run `ls -l` and check the owner, group and permissions. Use sudo chmod, etc. and change them. Create working directories with the correct ownership and permissions. Reboot the compute instance and verify that the changes stick. – John Hanley Oct 16 '19 at 04:08
  • thank you @JohnHanley. what you are suggesting is what i mentioned in OP: "I tried connecting to the docker host and chowning the folder to the uid of the user in the docker container, but the moment the VM gets recreated, the folder is again owned by root" So it does work but it doesn't stick. as for your question of how i created the partition and format. i attached an empty disk and as per the docu "With no initial file system, the container startup agent formats the disk to ext4, and only read/write attachment and mounting are supported." – Hilikus Oct 16 '19 at 15:21
  • The permission on the folder that the volume is mounted on do not matter. That folder's inode is replaced during the mount. The permissions of the file system (root directory, and subdirectories) that you are mounting are what matters. Since you are using a blank file system the default is "root". That is what is breaking your user access. – John Hanley Oct 16 '19 at 15:30
  • Now that you know why, what is the solution? Create a persistent disk, format the file system. Create a subdirectory, set the correct owner, group and permissions. Now when you attach that disk to your container, you will have access. This sounds goofy and it is. In the old days containers ran as "root". That, of course, creates a security hole. Now permissions are more controlled and you must do more work. – John Hanley Oct 16 '19 at 15:33
  • I think I understand what you're saying. If I do, I tried that yesterday as well with --container-mount-host-path since --container-mount-disk mounts a whole disk in the folder specified.Because i need a folder in the first level /nexus-data, i can't create a folder nexus-data in the root of the disk and then bind mount my disk to / , which sounds bad so what i did was created the folder with the right permissions in my disk and used mount-host-path to mount the folder with the proper permissions set. Even then, inside the container the folder was owned by root. will try again though – Hilikus Oct 16 '19 at 16:03
  • @Hilikus any updates on this issue? I stumbled across the same issue with the Container-optimized OS. It would be great if you could share your findings if you have new ones. – maxarndt Apr 17 '20 at 10:53

0 Answers0