Nextcloud changes datadirectory settings in my config.php

ℹ️ Support
,
1
Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 20.0.8
Operating system and version (eg, Ubuntu 20.04): OpenBSD
Apache or nginx version (eg, Apache 2.4.25): OpenBSD httpd
PHP version (eg, 7.4): 7.4

The issue you are facing:

Every update, but also after “some” unindentified circumstance nextloud “corrects” my datadirectory setting, so it is no longer accessible. I have to manually correct that to bring my instance back to life. Case is that I run it over OpenBSD httpd, chrooted by default. To properly run cron tasks I cannot simply ste path to data directory it has to be in format:

‘datadirectory’ => ((php_sapi_name() == ‘cli’) ? ‘/var/www’ : ‘’) . ‘/my/data/directory’,

The ‘/var/www’ is default openbsd chroot, “/my/data/directory” is path within chrooted environment.

There is no other way to run for instance OCC commands without setting data directory that way. Earlier versions of nextcloud stripped /var/www/ part in string while “correcting” my config. That caused errors “no readable data directory” but instance itself worked. Present version simplifies setting to “/var/www/my/data/directory” and collapses whole nextcloud forcing me to manually reset things. Of course I can workaround that with cron job validating settings in config.php and resetting it in case of changes, but I find it odd and dirty trick.
I suppose it is a sort of code integrity validation e.g. during cron.php execution or other automatic task, but form my point of view it is annoying bug.

Thanks in advance for any help/ideas

Is this the first time you’ve seen this error? (Y/N):
no
Steps to replicate it:

  1. For instance upgrade some app
  2. Probably after some coron.php execution
  3. After each upgrade of whole instance

The output of your Nextcloud log in Admin > Logging:

no logs involved

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

no need to paste whole config - case is simple

The output of your Apache/nginx/system log in /var/log/____:

no signs of activity in logs
2

The cron and the webserver run within the chroot environment?

3

No, of course cron is systemwide, while httpd daemon (webserver) is chrooted. Cron can “see” whole path, while webserver is chrooted to /var/www, and nextcloud itself is in /var/www/nextcloud or whatever (it does not matter), and data directrody is for instance /var/www/data-directory - outside from nextcloud itself.
So “some” integrity check procedure triggered by nextcloud changes setting in config.php, while cron(daemon) working over chroot detects change and restores proper setting (with shell script involved). However that “dirty workaround” generally works, sometimes one has to wait up to one minute (cron cycle) to get things working back again.
I suspect it is something in cron.php (also triggered by systen cron-daemon task every 5 minute, according to nextcloud expectations). While cron.php execution takes say 2-4 seconds it overlaps cron-daemon cycle and instance dies for around 50 secs till next execution of my “fix” script goes on. That is really annoying

4

Well, for now I am absolutely sure, that the winner is cron.php. The period between annoying changes is strictly connected with my systemwide cron cycle of invoking cron.php.
Tried to restrict write access but it of course kills instance. Nextcloud does not work without write permissions on config.php.
Is there any sort of “pattern” that must be matched in data directory directive, to prevent it from changing path set by hand? I suppose that kind of behavior is a bug. It cannot be worked around by external scripts because minimal system cron cycle is 1 minute. If one unfortunately begins operation in the middle of 5 minute cron.php period he simply won’t finish it with success. Instead nextcloud displays error at least till next refresh after “fixing” wrong settings, but the operation already broke, so it has to be restarted. Desktop client handles such cases, retrying till success, but with www interface, say administrative tasks or whatever one has 100% chance to see error alert.

Any ideas - suggestions highly appreciated.

5

Hi,

This is an old threads, so to help people in the same situation, the workaround is to add a custom config file config/zzcustom.config.php who containt things like :

<?php

if ( php_sapi_name ( ) == 'cli' )
	$CONFIG['datadirectory'] = "/path/outside/chroot/";
else
	$CONFIG['datadirectory'] = '/path/inside/chroot/';

?>

This will override datadirectory defined in config.php and won’t be modified by nextcloud