The container is an isolated environment which has its own process namespace and processes in the container often run as root even if you don’t use the Docker client as root, since the daemon is still running as root.
When you create a volume, it is just metadata until you refer to it in a docker run command or in any way when you run a container. Then what happens with the volume depends on where you mount it in the container. If there is data in th folder already, it will be copied to the volume with the same ownership and permissions as it had in the image. If there is no data in it, the volume will be created as root.
I wrote about the permission issues among other things in this blog post:
But you need to think in the context of the container. If the process in the container is root and, it will create new files as root. If it runs as another user, maybe a dedicated sql server user, it fill create files as that user, and still not as your original user on the host.
If you want to access data created as root in the container, you could try “rootles docker” which means you run the docker daemon as your user
That will still not solve the case when you need to access files created not as root, but any other user in the container and you would need to use “rootlesskit” to get a shell in the user namespace of Docker. The command is mentioned in the documentation.
Sometimes you can also configure the app running in the container to run as a chosen user which has the same user id as your user so you can access the data during development.
Thanks rimelek, when I create/run the container, I get a message indication that sql server 2022 run as mssql user not root, so according to you it should this user. So should I add a user named mssql in the host machine?
I want to work with the directory without the need to use sudo or root. I need to copy files, run some maintainance tasks as myuser or mssql user and so on. Also, I need to give access to some developers. I even tried to use chown to change owner but it does not take effect
I guess I don’t know MSSQL server enough, but I don’t see what files should be handled by a user who is not root and not mssql.
I usually think of how I would work with files without containers and then what would change when using containers. A container helps isolate the process, but the permissions could be the same. If MSSQL doesn’t support running as your user, Docker will not solve it. If MSSQL support running as any user, you can try setting the user id and optionally group id when running the container. How you would do that depends on how you create the container now, but it is posisble with the docker run command and can be defined in the compose file as well.
I wrote that to try help you with your original issue, but I still don’t see why it would be required. I will have to leave it to an MSSQL user.
Some software like PHP or Apache HTTPD support changing the user on behalf of processes can run, which makes accessing files easier during development, but I would not change the owner of processes to my user on the host in production. If that seems to be required, it raises the question whether the software is managed correctly. or how much that software is supported in containers.
Thanks, I know and you have helped me in other issues in the past. Of course rimelek we can run SQL server with any user we want. I have 3 SQL servers running on VMs, 2 run under non-priviileged users(with specific prmissions) only 1 with privileged user but not administrator.
OK, why docker uses root t create the volumes and not using mssql user which doscker indicates when I create the container?
where my confusion is coming from? if it is running under non-root as msssql user, why volumes on host are created with root privilges when I create the volumes and containers using my user?
Currently, the permissions of the filesystem has nothing to do with the user that runs the main process. You can have data in the image owned by any other user. Files are copied keeping the original owner including the folder.. When the mount point folder in the container doesn’t exist, it is created on the host as root and mounted to the container. Likely because the daemon is still running as root and it has no way to know how you want to create the folder in the container. It would be possible that you don’t want the container to write it, only read it and you create files on the host.
In your case, you had an existing folder rin the container, but /var/opt/mssql inside the container (if you are using the official mssql docker image) is actually owned by root and only the group is mssql. The ID is exactly what you had on the screenshot. 10001. So what happened was expected. Since the group can read the files, you don’t actually need to create a user with the UID of mssql, you just need to create a group on the host with the GID 10001 and add your user to the group.
Your screenshot shows that the group can alos write the folder which is not what I see using mcr.microsoft.com/mssql/server:2025-latest but you may have a different image.
Your user just interacts with the the API of the Docker daemon thorugh a unix socket and the daemon is root. But it only matters when you mount a folder to a nonexistent folder in the container.
I’m not sure about your conclusion. Can ou explain what you mean? We discussed permissions and owners. Whether you need to create a volume or not depends on your needs, but you definitely need to mount something to the container if you don1t want to lose data.