/palworld is not writable

mizifih commented 1 month ago

Except it is creating the backup sub directory. So, it's actually doing something inside /palworld (a remote CIFS/SMB permanent volume). But it doesn't do anything else after this output, it's a loop, keep outputting this message.

****EXECUTING USERMOD****
usermod: no changes
/palworld is not writable.

mizifih commented 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.

thijsvanloef commented 1 month ago

I would need more information, could you please follow the bug report template to provide me with more information?

mizifih commented 1 month ago

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.

Software

Virtual Machine, running on ProxMox VE 8.1.5.
Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-113-generic x86_64).
Docker Engine - Community; Version: 27.0.3; API version: 1.46; Go version: go1.21.11; Git commit: 7d4bcd8.
Portainer Community Edition 2.19.5.

Hardware

This Ubuntu VM that runs Docker is installed on a physical SATA3 SSD.
Some Docker Mounts are stored on a TrueNAS Share, and TrueNAS is also virtualized on ProxMox.
The TrueNAS storage used by these Mounts are ZFS ZRAID0 and the CIFS/SMB

Container

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?

The problem

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.

Even though both options are under the tab Volumes, here's how they're treated differently

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

sonroyaalmerol commented 1 month ago

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:

Bind: docker run -v /home/test/palworld:/palworld/ thijsvanloef/palworld-server-docker
- /home/test/palworld will be mounted on /palworld inside the container
Volume: docker run -v palworld:/palworld/ thijsvanloef/palworld-server-docker
- As a local volume by default, a folder is created in /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:

Create a user account on TrueNAS with an arbitrary UID and GID. Then, ensure that the user actually has permissions to the directory being shared locally. After confirming, set the container env var 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.
Mount the CIFS share to the host OS (Ubuntu) instead of directly mounting it to your container. (See here: https://techantidote.com/mount-truenas-core-samba-share-on-linux/). After mounting it to your host, use the bind option to mount it to your Docker container. This way, you wouldn't need to modify the user inside the container as your host OS is the one mounting the share.
Not recommended but you could also do 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.

thijsvanloef / palworld-server-docker