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/docker.elastic.co-elasticsearch-elasticsearch-9.x

semver_details

nextcloud-metrics

trusted-domains

update_33.0.8

renovate/pgautoupgrade-pgautoupgrade-18.x

pr-15.2.0+34.0.2-fpm

pr-14.1.0+33.0.7-fpm

pr-14.2.0+33-fpm

pr-15.1.0+34.0.2-fpm

pr-15.0.0+34.0.2-fpm

pr-14.0.1+33.0.7-fpm

feat/check-major-upgrade

pr-14.0.0+33-fpm

temp

fix/nginx-conf-config-name

pr-13.2.0+32-fpm

upload-limit

feature/imaginary

kc_stable

nextcloud-v28

add-theming-v28.0.5

add-theming

update-nginx-conf

split-bbb-onlyoffice-compos

split-onlyoffice-bbb-config

authentik_sso

healthchecks

occ_cmds

auto_app_install

embed_nextcloud_in_iframe

auto_configure_sso

add-postgres-db

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#116