Ensure write permissions in nextdata volume root #116

New Issue

2026-08-18T12:52:34Z

simon commented

2026-08-18 12:52:34 +00:00

We had issues with Nextcloud when restarting our VMs where the permissions on the root path of the nextdata volume got changed to the root user.

While the core issue probably lays in our system update routine, ensuring the correct access to the root directory (not recursively) would make the app itself more resilient against this.

Example solution in wordpress:

wordpress/entrypoint.sh.tmpl Line 57 in fadb247d47

chown -R --from=root:root www-data:www-data /var/www/html/wp-content/

Proposal to add:

chown --from=root:root www-data:www-data /var/www/html/data/

We had issues with Nextcloud when restarting our VMs where the permissions on the root path of the nextdata volume got changed to the root user. While the core issue probably lays in our system update routine, ensuring the correct access to the root directory (not recursively) would make the app itself more resilient against this. Example solution in wordpress: https://git.coopcloud.tech/coop-cloud/wordpress/src/commit/fadb247d471f5241adf35e5e81427735a8b78b55/entrypoint.sh.tmpl#L57 Proposal to add: ``` chown --from=root:root www-data:www-data /var/www/html/data/ ```

dannygroenewegen commented

2026-08-20 19:09:02 +00:00

Looks safe to add this. Was it only the nextdata that was changed? Or also other volumes where maybe it did not directly cause an issue?

dannygroenewegen referenced this issue

2026-08-20 19:09:54 +00:00

Ensure write permissions in nextdata volume root #115

simon commented

2026-08-21 09:08:34 +00:00

was only nextdata

ineiti commented

2026-08-28 15:05:50 +00:00

I'm not sure we should add these checks here - if the normal installation / upgrade works, and only non-standard handling of the files fails, I would not add this:

it might break somebody else's workflow
if we add it, then we should make sure that all other directories also have the correct owners set

What about improving the error handling of this situation? How did you find out the owners were wrong?

I'm not sure we should add these checks here - if the normal installation / upgrade works, and only non-standard handling of the files fails, I would not add this: - it might break somebody else's workflow - if we add it, then we should make sure that all other directories also have the correct owners set What about improving the error handling of this situation? How did you find out the owners were wrong?

moritz commented

2026-08-31 10:44:50 +00:00

I'm not sure we should add these checks here - if the normal installation / upgrade works, and only non-standard handling of the files fails, I would not add this:

It's a very typical nextcloud problem. I discovered this even on complete different setups. Nextcloud reads/writes a big bunch of files all the time. This can easily lead to inconsistent filesystem states, when the container or the host is shut down. Ext4 can handle this easily but sometimes it forgets/resets the owner of the volume directories . This can affect all volumes of all services, but the data volume of nextcloud has the highest probability.

it might break somebody else's workflow

Do you have any argument what could break?
Running chown --from=root:root www-data:www-data /var/www/html/data/ on every start should be absolute safe and fast.

if we add it, then we should make sure that all other directories also have the correct owners set

The owner change affects only /var/www/html/data/ not the sub directories. If we would apply chown -R to all the sub directories it could delay the start of the container depending of the amount of data by a quiet long time.

> I'm not sure we should add these checks here - if the normal installation / upgrade works, and only non-standard handling of the files fails, I would not add this: It's a very typical nextcloud problem. I discovered this even on complete different setups. Nextcloud reads/writes a big bunch of files all the time. This can easily lead to inconsistent filesystem states, when the container or the host is shut down. Ext4 can handle this easily but sometimes it forgets/resets the owner of the volume directories . This can affect all volumes of all services, but the data volume of nextcloud has the highest probability. > - it might break somebody else's workflow Do you have any argument what could break? Running `chown --from=root:root www-data:www-data /var/www/html/data/` on every start should be absolute safe and fast. > - if we add it, then we should make sure that all other directories also have the correct owners set The owner change affects only `/var/www/html/data/` not the sub directories. If we would apply `chown -R` to all the sub directories it could delay the start of the container depending of the amount of data by a quiet long time.

Sign in to join this conversation.

Branches Tags

main

renovate/nginx-1.x

kc_stable

mitigations_php

renovate/ghcr.io-nextcloud-releases-whiteboard-2.x

version_35

after-pr-143-cherry-pick

pr-143-review

renovate/docker.elastic.co-elasticsearch-elasticsearch-9.x

pr-125-v2

pr-125

renovate/mariadb-13.x

trusted-domains

renovate/pgautoupgrade-pgautoupgrade-18.x

pr-15.2.0+34.0.2-fpm

pr-14.2.0+33-fpm

fix-pgautoupgrade-max-connections

upload-limit

feature/imaginary

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#116