I'm getting permission denied when trying to save a file in a docker volume. Before you close this as duplicate i did try all the docker related questions/answers i suspect this is related to the dotnet/runtime image i'm using and how it's setup.
I have this Dockerfile
FROM mcr.microsoft.com/dotnet/runtime:8.0 AS base
USER app
RUN mkdir /home/app/data
WORKDIR /home/app
COPY ./publish .
ENTRYPOINT ["dotnet", "MyProject.dll"]
Doing something like File.WriteAllText("/home/app/data/file.txt", "lorem ipsum") in MyProject get permission denied when the volume is mounted in linux
docker run --rm \
-v ./testdata:/home/app/data \
-e RUN_ON_STARTUP=true \
$image_name
This works running on windows with mounted folder. This works running on linux IF the folder is not mounted.
Is it even possible for this to just work? Meaning running the app non-root, and for users that run the image it just works and they see files in the mounted /home/app/data without doing anything?
I would like assistance on how to debug this, without making the app running root. And hopefully have everything done in the dockerfile, without the end user having to do anything
More debug info
running without mounting /home/app/data on linux
app@10a002ed6d04:~$ id
uid=1654(app) gid=1654(app) groups=1654(app)
app@10a002ed6d04:~$ ls -ld /home/app/data
drwxr-xr-x 2 app app 4096 Jun 24 07:06 /home/app/data
Runnin with /home/app/data mounted on linux
app@139b37a1d399:~$ id
uid=1654(app) gid=1654(app) groups=1654(app)
app@139b37a1d399:~$ ls -ld /home/app/data
drwxrwxr-x 2 1000 1000 4096 Jun 24 09:01 /home/app/data
I don't understand where drwxrwxr-x 2 1000 1000 is coming from, it's not from the host, I don't it's something we can change in the dockerfile?
???
You have
USER app
in your Dockerfile, so your application is running as the predefined app user which has UID 64198.
For you to be able to create files in the mounted directory, UID 64198 needs to be able to create files on the host in the ./testdata directory.
You can do that by giving public write access on the host using chmod o+w ./testdata.
If that's too permissive, you can create a user on the host with UID 64198 and give that user group access to the directory.
A 3rd option is to drop USER app and run the container as root which should have access.
As a note, the reason it works without a mounted volume is that the directory is owned by the app user in that case. But when you mount a host directory into a container, the host ownership and permissions are transferred into the container, so those are the ones that matter.