isWritable check requires that the root directory be deletable ("/palworld is not writable")

[acmcarther]

Describe the bug

When I updated today, my server would not start with error "/palworld is not writable"

I root caused this to this script, which is checking not only for writability, but also for the ability to delete the directory.

I suppose due to some idiosyncracy of my Kubernetes setup (NFS based volume management via nfs-client-provisioner), my persistent volume claim root directories are not created to be deletable. Normally an application would not try to delete the whole PVC directory anyway, so this has historically not been a problem.

To Reproduce

Steps to reproduce the behavior:

1. Create a palworld directory without delete permission on the root palworld directory
2. Startup
3. "/palworld is not writable"

Expected behavior

Palworld should not require the root palworld directory to be deletable ideally since there's no circumstance where that directory would need to be deleted.

Alternatively, the file writability check could be for some file within the palworld world directory

Alternatively (2), the error message could be more explicit about the required permissions.

---

I resolved this locally by manually updating the NFS directory to be deletable, but the kubernetes nfs-client-provisioner does not normally create the directory this way, so I'll have to do it manually for future palworld servers.

[Dashboy1998]

Very interesting.

What are you running the NFS server on?

When I had made the write check it assumed Linux permissions. Not sure how it works for more advance permissions like AppArmor or SELinux.

I agree it shouldn't need the ability to delete the directory.

Checking if a child directory or file is writable wouldn't give the result we want. I suppose we could try to create a temporary file inside palworld directory.

I'm not sure how we would be more explicit as it sounds like you are using a different permissions set than base Linux.

I'll check if there's another way to check if it's writable.

[muri235]

I also geht the same error. But even setting the root directory and the one above to chmod 777 doesn't change anything. Still getting the "/palworld is not writable" eventhough "/palworld/backup/" is being created. Not using NFS though.

[XeNz]

Also getting the same issue.
Not using NFS but ext4.
Folder has 777 permissions.

[Dashboy1998]

@XeNz @muri235 Are you both using Kubernetes?

[XeNz]

@XeNz @muri235 Are you both using Kubernetes?

I am not running on k8s. I'm running a simple docker compose file.

[Dashboy1998]

I am not running on k8s. I'm running a simple docker compose file.

What distro are you running?
Are you using apparmor or selinux?

Could you try to use #381 ? That PR changes how we check the permissions of the directory so it might fix your issue. Unfortunately I have not been able to reproduce the issue so I am not able to test the solution.

[XeNz]

I am not running on k8s. I'm running a simple docker compose file.

What distro are you running? Are you using apparmor or selinux?

Could you try to use #381 ? That PR changes how we check the permissions of the directory so it might fix your issue. Unfortunately I have not been able to reproduce the issue so I am not able to test the solution.

• Ubuntu 20.04.6 LTS
• Docker version 19.03.12
• Using the 0.26 release image

Will report back after running the above mentioned changes.

Edit2:

Was a long day, did not use the Dockerfile for the build as a mistake. Seems to work fine now.
Did have to upgrade my docker version 25.0.3, as my old version had some issues building this specific container.

[muri235]

We are on

• Debian 10.13
• Docker 18.09.1
• Also Using the 0.26 (:latest) image

I have difficulties building the #381 (I think because of the outdated versions) But I will try further. Just can't update everything immediately because of other services running.

[isundaylee]

Sorry for replying to this closed ticket, but just want to share my finding in case it can help save someone else's time in the future. In my case, [ -w /palworld ] returns non-writable despite of the user actually being able to write to that location:

$ sudo docker run --volume /mnt/iscsi_mnas_palworld/data/data:/palworld:rw --entrypoint "/bin/bash" -e PUID=1000 -e PGID=1000 -i thijsvanloef/palworld-server-docker:latest

container$ [ -w /palworld ]; echo $?
1
container$ touch /palworld/a
# Finishes successfully

This turns out to be due to seccomp. Disabling it for the container by adding --security-opt=seccomp:unconfined fixed the issue for me.