Open mizifih opened 1 month ago
Can anyone help me check for permission? Looks like it's related to the CIFS
remote volume. A local bind works alright.
I would need more information, could you please follow the bug report template to provide me with more information?
The OS and Docker is pretty straightforward, nothing fancy, just regular apt-get Docker on Ubuntu. Using Portainer with Docker, to help manage my containers.
Docker Mounts
are stored on a TrueNAS Share, and TrueNAS is also virtualized on ProxMox.ZFS ZRAID0
and the CIFS/SMB
The container can run without any problem when I use bind
in Portainer to match host
path with container
path. Honestly I don't know if this bind option is the same as -v
when you use docker run
or a volume declared in a docker.compose.yaml
file. Portainer treat these volumes
as global mounts, that can be referenced and used by any container it manages, so I think these are mounts
, not volumes. I don't know... Docker itself makes it confuse, I believe it use -v
for binding path, instead of volumes, and use --mount
for mounting volumes. Right?
Anyways... If I use the Volume option in Portainer (that I believe are mounted volumes), I have that read/right permission problem I mentioned on my OP, and this is something that doesn't happen with other containers that also make use of this method of matching paths. But if I use the bind
option, there's no problem at all and everything just work, flawlessly.
My mounts/Volumes, however you wanna name it, are CIFS/SMB
shares, so even though everything runs on the same machine, Virtualization makes everything virtually remote.
Bind
This path is a regular path on my Ubuntu VM, that runs Docker
Volume
This volume real path is
//162.168.1.40/AppData/palworld
Docker itself makes it confuse, I believe it use
-v
for binding path, instead of volumes, and use--mount
for mounting volumes. Right?
Nope. -v
is just a simplified --mount
. The differences between the two aren't related to the differences between bind
and volume
.
bind
is simply a mount that the user controls while volume
is a mount that the Docker daemon controls, including all the permissions, etc.
In a simple docker run
command, they look something like this:
docker run -v /home/test/palworld:/palworld/ thijsvanloef/palworld-server-docker
/home/test/palworld
will be mounted on /palworld
inside the containerdocker run -v palworld:/palworld/ thijsvanloef/palworld-server-docker
/var/lib/docker/volume
and will be named palworld
. Then that folder will be mounted the same way as the bind example. The only big difference is that the Docker daemon is able to control the configuration of that folder (permissions, etc.).My mounts/Volumes, however you wanna name it, are
CIFS/SMB
shares, so even though everything runs on the same machine, Virtualization makes everything virtually remote.
Now, your setup is slightly different from the example I gave above. This time, instead of the default local volume, your volumes are network shares. Network shares are inherently different from local filesystems. One of the reasons being the need for users to authenticate over the network for security. That authentication stage makes it harder for network shares to "emulate" the same permission controls that one would typically find in a local filesystem.
In the context of Docker volumes, volumes on a network share and local volumes behave differently. Volumes on a network share does not have the advantage of Docker being able to control permissions by itself.
The only reason why network shares can only be mounted directly with the volume option in Docker is because it is the only option capable of doing so. The bind option is only applicable for volumes mounted in the host OS. It is essentially just doing all the things bind does but for network shares. You will encounter the same problem with bind if UID 1000 does not have the write permission for the folder you mounted.
Yes, the UID for the default user (steam
) inside the container is set to 1000 by default. You can change the UID and GID of the steam
user inside the container by modifying the PUID
and PGID
env vars.
this is something that doesn't happen with other containers that also make use of this method of matching paths.
I can only speculate that the other containers you've tried so far are using the root user by default (pretty common as it can be a struggle to make a container rootless). If it is, then your CIFS is probably configured to map whatever user you're using to mount as root in your NAS. Since both the user inside the container and the user in your NAS are probably both root, then it makes sense that those container have write permissions to the share.
The problem here is that this particular image (thijsvanloef/palworld-server-docker
) is rootless. Meaning, you're not allowed to set PUID and PGID as 0 for security reasons so simply doing those won't work.
At this point I can think of 3 options for you:
PUID
and PGID
to the ones you just made. If you used 1000 for both, then no need to set the PUID
and PGID
env vars as these are already the defaults.chmod -R 777 <network-shared-directory>
on the network share's local OS (TrueNAS in your case). Be reminded that this will essentially allow any users to have read, write, and execute permissions to all files inside that directory recursively.
Except it is creating the
backup
sub directory. So, it's actually doing something inside/palworld
(a remoteCIFS/SMB
permanent volume). But it doesn't do anything else after this output, it's a loop, keep outputting this message.