Performance opportunity in postinst steps #64

New Issue

2026-06-04T11:45:47+02:00

adamhax0rbana commented

2026-06-04 11:45:47 +02:00

Problem

On every update, the recursive chown takes several hours, which keeps the server down. This is a combination of the chown affecting the data directory, my servers having a large number of files and being backed by a network filesystem (a ceph cluster). I believe it's all the calls to getdents() which trigger a ton of small IO requests, but I haven't spend the time to confirm that hypothesis.

Solution

Don't chown the data directory. Nothing in there should need to be chowed after an upgrade.

Patch

~~Hold off on applying this for now, as I have to wait until my server is done with its current chown before I can fully test it.~~

diff --git a/debian/nextcloud-server.postinst b/debian/nextcloud-server.postinst
index 5db0f9f..e43f307 100644
--- a/debian/nextcloud-server.postinst
+++ b/debian/nextcloud-server.postinst
@@ -39,7 +39,7 @@ configure)
     fi
 
     # Permissions and owners
-    chown -R www-data:www-data /var/www/nextcloud
+    find /var/www/nextcloud -mindepth 1 -maxdepth 1 '!' -name 'data' -exec chown -R www-data:www-data {} \;
     chmod 644 /var/www/nextcloud/.htaccess
     chmod +x /var/www/nextcloud/occ
     chmod +x /usr/sbin/occ

The -mindepth omits the . directory. The maxdepth ensures we avoid recursing in find. The '!' is the negation operator to exclude the data directory.

This should result in all files and directories under /var/www/nextcloud to be recursively chowned except the data directory, which will never be traversed.

~~I'll post back here after I've verified this patch works and preforms as expected.~~

# Problem On every update, the recursive `chown` takes several hours, which keeps the server down. This is a combination of the chown affecting the data directory, my servers having a large number of files and being backed by a network filesystem (a ceph cluster). I believe it's all the calls to `getdents()` which trigger a ton of small IO requests, but I haven't spend the time to confirm that hypothesis. # Solution Don't chown the `data` directory. Nothing in there should need to be chowed after an upgrade. # Patch ~~Hold off on applying this for now, as I have to wait until my server is done with its current chown before I can fully test it.~~ ```patch diff --git a/debian/nextcloud-server.postinst b/debian/nextcloud-server.postinst index 5db0f9f..e43f307 100644 --- a/debian/nextcloud-server.postinst +++ b/debian/nextcloud-server.postinst @@ -39,7 +39,7 @@ configure) fi # Permissions and owners - chown -R www-data:www-data /var/www/nextcloud + find /var/www/nextcloud -mindepth 1 -maxdepth 1 '!' -name 'data' -exec chown -R www-data:www-data {} \; chmod 644 /var/www/nextcloud/.htaccess chmod +x /var/www/nextcloud/occ chmod +x /usr/sbin/occ ``` The `-mindepth` omits the `.` directory. The maxdepth ensures we avoid recursing in find. The `'!'` is the negation operator to exclude the `data` directory. This should result in all files and directories under `/var/www/nextcloud` to be recursively chowned except the `data` directory, which will never be traversed. ~~I'll post back here after I've verified this patch works and preforms as expected.~~

marsupilami79 commented

2026-06-04 13:04:41 +02:00

You might want to move the data outside of your nextcloud installation. On my installations the data is in /srv/nextcloud and in config.php Nextcloud is configured to use it:

'datadirectory' => '/srv/nextcloud',

You might want to move the data outside of your nextcloud installation. On my installations the data is in `/srv/nextcloud` and in `config.php` Nextcloud is configured to use it: ` 'datadirectory' => '/srv/nextcloud',`

adamhax0rbana commented

2026-06-04 19:42:23 +02:00

Confirmed. The old chown took 7 hours and 10 minutes. The new find/chown line took 21 seconds. It's the tremendous efficiency gain that I was hoping for!

And even if it's not as big of a time savings for people with a small number of files, or bigger & better hardware, it's still an improvement.

Confirmed. The old `chown` took 7 hours and 10 minutes. The new `find`/`chown` line took 21 seconds. It's the tremendous efficiency gain that I was hoping for! And even if it's not as big of a time savings for people with a small number of files, or bigger & better hardware, it's still an improvement.

adamhax0rbana referenced a pull request that will close this issue

2026-06-04 19:58:31 +02:00

performance upgrade that goes from hours of downtime to seconds #66

ijurisic closed this issue

2026-06-05 07:46:12 +02:00

ijurisic referenced this issue from a commit

2026-06-05 07:46:13 +02:00

performance upgrade that goes from hours of downtime to seconds #64

Sign in to join this conversation.