Cannot delete files in volume mounted via CIFS in docker container

Docker Desktop
1

We are running a local docker registry via docker desktop running on Windows 10. We created docker volumes that are network shares using the following command.

docker volume create --driver local --opt type=cifs --opt
device=//<IP-ADDRESS/<ShareName> --opt
o=user=<username>,domain=<Doman>,password=<password>,file_mode=0777,dir_mode=0777
<Sharename>

We then mount the volume into the container using the following (environment variables left out for simplicity).

docker run --privileged -d -p 5000:5000 --restart=always --name
myregistry.local -v <ShareName>:/<sharename> registry

This works fine and we have no problems pulling or pushing to the registry. However, we attempted to use Skopeo to copy an image to the registry and received the following error in the logs.

time=“2023-06-08T12:51:03.9550905Z” level=error msg=“unknown error
completing upload: filesystem: rename
/var/lib/registry/docker/registry/v2/repositories/redhat/redhat-redhat-operator-index/_uploads/410e153c-ab6a-4722-a5fa-db346db2273b/data
/var/lib/registry/docker/registry/v2/blobs/sha256/d3/d31b7a31227f5f11b6e1c63a6880cfe2873e46b8fd6b0f27e86d42b52e88d95d/data:
permission denied”

I’m not sure if it’s related, but when I accessed the terminal via docker desktop and attempt to perform a mv or rm command I get permission denied. The file that I’m attempting to remove is owned by root. The user that was used to mount the volume is an admin on the Windows server where the share resides. Am I missing something here? Shouldn’t we have the ability to move or remove files in the volume? We can create files with no problem.

2

Could be related to either that the share does not permit the admin user to perform the action, or it might be related to that the move operation not being an atomic operation.

I vaguely remember having problems like this in the past (when I was still using cifs shares), because the linux operation expected to see the changes reflected immediately, but they seem not to be processed like that on the cifs remote share. I believe it’s a race condition, where the move operation expects immediate change in the remote share, which results in an error because from the perspective of the command the filename or path didn’t change when immediately checked. Moments later the file was renamed when listing the directly afterward.

3

Thanks @meyay. Are there any possible workarounds to this? We have NFS server running on the Windows server. Should we use NFS instead? We switched from NFS to CIFS, because we noticed that we would have to manually change permissions on files pushed tot he re

4

None that I am aware of. I stopped using volumes backed by cifs remote shares years ago.

I have no idea what complications NFS on a Windows server might yield. I don’t user Windows Server.

My NFS shares are either AWS EFS or NFSv4 on NAS devices. Of course the UID/GID of the process run inside the container must align with the UID and/or GID (depending on your need) of the folder owner within a remote share. There is no way around that.

5

Since Windows servers support NFSv4, I think we’re going to switch back to using NFS. Your point about the alignment of UID/GID was the reason we switched in the first place. I think we just didn’t configure it correctly. We found ourselves always having to reset permissions from the Linux side whenever new files were created from Windows. Thanks again!