OMV and Docker and users. (new guy)

Dan66215 · 2. November 2020

Zitat von gderf

I didn't create a new dedicated user specifically for docker. I used the only ordinary regular non-privileged user on the system for this. This user is not restricted to only dockers.

This user came first, docker came along later, much later. My OMV system is five years old, docker came along about three years ago. I have not added a new user to my system since the day it was created on OMV 2.x.

File ownership conflicts with dockers don't happen here for me.

At this time I can only dream of achieving "file ownership conflicts with dockers don't happen here for me"! I hope you can help me get there.

Environment:

I created a cifs volume via Portainer that maps to a WS2016 share and is mounted at /var/lib/docker/volumes/Movies/_data on the host.

I created a primary user via the OMV GUI as you recommended, adding it to the groups 'user', 'docker' and 'ssh'.

The UID/GUID for the primary user is 1000/100.

I created the container with UID & GID set to 1000 & 100 and included the above volume.

Behavior:

From the application running in the container, I don't have write access to the volume. (I get the "folder is not writable by user abc" error).

From the CLI within the container, I see the volume is owned by root and is 755.

From the CLI on OMV, the volume also shows as owned by root and 755.

gderf I've read a couple of your other posts where you were helping with the same error I'm seeing and I think you mentioned that the permissions outside the container were often the culprit. Any thoughts on this one?

Thanks.

gderf · 2. November 2020

You need to post what you used to set up the container, all of it. This is important to see because it's not possible to know what you have there without seeing it.

Creating a volume in portainer isn't the best or easiest way to do this. And /var/lib/docker as a docker base path is generally a poor choice.

You should have the docker base path on a data drive, not on the system drive.

And don't use volumes, create bind mounts to a directory on a data drive instead.

crashtest · 2. November 2020

With apologies to gderf for butting in:
_____________________________________________________

Here's at least one issue as I see it.

Zitat von Dan66215

I created a cifs volume via Portainer that maps to a WS2016 share and is mounted at /var/lib/docker/volumes/Movies/_data on the host.

And

Zitat von Dan66215

From the application running in the container, I don't have write access to the volume. (I get the "folder is not writable by user abc" error).
From the CLI within the container, I see the volume is owned by root and is 755.

____________________________________________________

- The WS2016 share was created and populated "in Windows".

- Mapping a share from Portainer can mean as little as "read only" access to the remote network share. (If "Everyone" has read access, it will connect.)
- The container, the OMV root account or an OMV user account, can't take control a Windows share without admin access and they can't write files without a minimum of write access.

Zitat von Dan66215

From the CLI within the container, I see the volume is owned by root and is 755.
From the CLI on OMV, the volume also shows as owned by root and 755.

The mapping itself (which is a sort of "symlink" folder) located at /var/lib/docker/volumes/Movies/_data might be owned by OMV's root account and show the permissions you listed, but when operations are done on the files in the network share it points to, they're under Windows control.

On the Win Server end, you could try setting the WS2016 shared folder the mapping points to, temporarily, to Everyone - Write or Full Control and see what happens. If that works, you'd need to work the issue to where you'd have acceptable access control given to the right user(s) on the Windows end. ("Everyone" with Write or Full Control access to a network share is not acceptable.)

Otherwise, you may have other issues going on. I don't know.

Dan66215 · 4. November 2020

I'll work on getting the config described more fully. In the meantime, what crashtest mentioned made me remember that I have a different server accessing this same windows share with no problems on read or write, which I would think makes more of a case for the windows permissions being ok.

The other server has the following fstab entry:

//192.168.1.227/Recorded\040TV /media/drive_pool cifs vers=1.0,username=xxxx,password=xxxx,iocharset=utf8,sec=ntlm 0 0

The owner of /media/drive_pool is root @ 755 as would be expected.

Thanks.

Jetzt mitmachen!