The user www-data runs the service rather than root

[Lindenk]

It looks like a user named www-data user needs to interact with the persistent data directory which create permission issues if the folder is mounted to the host system.

[ckulka]

Hi @Lindenk , this is intentional and somewhat of a best-practice.

The image is based on the official php image and uses the default www-data user to serve requests.

I'd recommend changing ownership of your mounted directories with sudo chown -R 33:33 <directory>. The image's www-data user has the user and group id 33, so I'd recommend using that as your host's www-data user might be different.

Alternatively, check out Running as an arbitrary user in the php image description and the linked Apache User setting.

[ckulka]

Closing the issue, hope this clarified it

[Lindenk]

I would argue best practice is to have services inside containers run as root whenever possible. Having to modify the host system in specific ways to work with a docker container instead of keeping any and all requirements to run the service inside the container is against the docker philosophy.

My temporary solution was to exec a chown command on the directory mounted inside the container after deployment but this has it's own problems. Any newly created filed are owned by root on the host system which causes the mounted system to misbehave unless another chown is executed afterwards.

It would be much more convenient and standard to have the service run as root (or the user configured with docker), or at the very least include an environment variable to allow a user to be set. Honestly, docker has the ability to set a user and group already so I see little need to go against convention and hardcode a different one in.

[ckulka]

The non-root user is not a custom adjustment I made, but what the offical Docker image had in there already. I'd argue running processes inside containers as root is not best practice:

The best way to prevent privilege-escalation attacks from within a container is to configure your container’s applications to run as unprivileged users.

-- Isolate containers with a user namespace, https://docs.docker.com/engine/security/userns-remap/

Regarding convenience and running Apache as a different user, please check the links from my earlier post, the official documentation explain the usage of APACHE_RUN_USER and APACHE_RUN_GROUP. The Apache docs warn about running as root as well, but your use case might require it.

I'm curious though, since you mentioned newly created files and if I interpret it correctly, it's a reoccurring issue on your server. Can you describe your setup and the steps that cause the issue?

[Lindenk]

It seems using the nginx image automatically sets permissions. While the permissions on my host system seem to have also changed, it's good enough as it doesn't requires manual configuration or hacks to get working.

Setting APACHE_RUN_USER didn't seem to fix the issue with the apache container (IE the baikal process(s) were still running as www-data).

Either way, sorry for the rant. I'm just tired of dealing with php in general.

[ckulka]

The Nginx variant sets/updates them, pretty much because of this issue. I didn't do it for the Apache variant though to not break anyone's setup.

I agree on PHP though... https://twitter.com/iamdevloper/status/983963738213666816

Btw, given PHP and the maintenance situation of sabre-io/baikal with the main developer leaving (https://evertpot.com/sabredav-maintenance-update/), I'm actually considering moving to https://radicale.org/ or something else... partially why I'm now cleaning up this repo, putting it in a good state before I possbily make a swtich.