Open_basedir restriction after update to 26

Our log gets flooded with (almost) the same lines after 25 > 26 update. The only difference is
php74 where its is php73 in the OP.
We have not noticed further issues so far.

We’re on shared webhosting based on Litespeed Web Server and DirectAdmin. Provider Nextcloud was installed using the web installer promoted here: Install - Nextcloud.


Nextcloud version : 26.0.1
Operating system and version : Linux 3.10.0-962.3.2.lve1.5.79.el7.x86_64 #1 SMP x86_64
Apache or nginx version : Apache/2 (litespeed)
PHP version : 8.1.17

The issue you are facing: same as OP above

Is this the first time you’ve seen this error? Y

Steps to replicate it:

  1. update 25.0.5 > 26.0.1 (via 25.0.6 and 26.0)
  2. look ub /index.php/settings/admin/logging

The output of your Nextcloud log in Admin > Logging:

[PHP] Error: is_file(): open_basedir restriction in effect. File(/proc/cpuinfo) is not within the allowed path(s): (/home/<account>/:/tmp:/var/tmp:/opt/alt/php74/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php74/lib/php/) at /home/<account>/domains/

GET /index.php/core/preview?fileId=464&c=c5edf881068c4f84bc6c9eb94f3cdcc9&x=375&y=375&forceIcon=0&a=1
from 2a10:3781:15:1:64d0:faf:896:88ea by <admin account> at 2023-04-23T20:44:04+00:00

(as it seems this line appears at any activity)

The output of our config.php file in /path/to/nextcloud :

    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "",
    "overwrite.cli.url": "https:\/\/",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "mail_smtpmode": "smtp",
    "mail_smtpsecure": "tls",
    "mail_sendmailmode": "smtp",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpport": "587",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpauthtype": "LOGIN",
    "mail_smtpauth": 1,
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "maintenance": false,
    "theme": "",
    "loglevel": 2,
    "default_language": "nl",
    "default_locale": "nl_NL",
    "defaultapp": "files",
    "default_phone_region": "NL",
    "skeletondirectory": "\/home\/<account>\/domains\/\/public_html\/clouddata\/skeleton",
    "templatedirectory": ""

The output of your Apache/nginx/system log in /var/log/____: we have no access to that.

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

[Sat Apr 22 00:10:47.369999 2023] [ssl:warn] [pid 3548:tid 140332246354048] AH01909: server certificate does NOT include an ID which matches the server name
[Sat Apr 22 00:24:45.679993 2023] [ssl:warn] [pid 3548:tid 140332246354048] AH01909: server certificate does NOT include an ID which matches the server name
[Sat Apr 22 01:56:39.407407 2023] [authz_core:error] [pid 1131188:tid 140330959476480] [client] AH01630: client denied by server configuration: /home/<account>/domains/
[Sat Apr 22 04:17:57.462229 2023] [authz_core:error] [pid 1568317:tid 140330791622400] [client] AH01630: client denied by server configuration: /home/<account>/domains/

The editing of generator.php seems to work in my Plesk environment. I haven’t got the error message for 35 min. now.

When I save the script and call it, I, however, get the following message:

Warning: require_once(lib/private/Preview/Generator.php): failed to open stream: No such file or directory in /httpdocs/comnomad/nproc.php on line 2

Fatal error: require_once(): Failed opening required ‘lib/private/Preview/Generator.php’ (include_path=‘.:/usr/local/php74/share/php74’) in /httpdocs/comnomad/nproc.php on line 2

I’m on php 8.

The path lib/private/Preview/Generator.php is relativ to the webroot.
you must place that script in your webroot (the place where occ is)

Or you can change the script and give the absolute path to Generator.php.

I added /proc/ and no more errors appear in the log.

We’re on shared hosting and unable to edit php.ini directly. But in DirectAdmin there is an app ‘PHP Selector’ where you can select extensions and set options. The open_basedir field looks empty when I click ‘reset to default’ but from the error I concluded that the default is:


So i filled the field with:


I have exactly the same error as @camouflage81, no problems with it on my end either until Nextcloud version 25.0.6.

Details about my installation:
Nextcloud version: 26.0.1
Webhosting provider: netcup
PHP Memory Limit: 512 MB
PHP Upload Filesize: 128 MB
Apache or nginx version: Apache/2
PHP version: 8.1.17
Operating system: Linux 4.19.0-21-amd64 x86_64
Processor: Unknown processor (display under Nextcloud System) possibly a cause?!
Hard disk shared: sda3
Mount: /
File system: ext4
Size: 4.15 TB
Available: 755.83 GB
Used: 83% (3.41 TB)

As recommended by @ernolf, I have run the commands.
php -d memory_limit=512M /httpdocs/xxxxxxxx/nextcloud/nproc.php
Hardware concurrency: 0
php -r “echo function_exists(‘exec’) ? ‘exec is available’ . PHP_EOL : ‘exec is not available’ . PHP_EOL;”
exec is available

Special feature since version 26 in the System section:
Besides my personal IPv4 and IPv6 address, about 360 other IPv6 addresses are now displayed.
Does this mean that I share the storage with 360 other netcup users?

Following @ernolf’s instructions, I modified the “./lib/private/Preview/Generator.php” file and the error no longer occurs.

I also host with netcup.
I hope that I can test it tonight as well.

I have already read your post in the netcup forum.

The file “data.config.php” in the config directory is absolutely necessary at netcup in the web hosting, because the occ commands in the SSH access do not work properly otherwise.

My file is structured as follows, because I still refer to the tmp directory in other installations.

	'datadirectory' => realpath(__dir__ . '/../data'),

Alternatively with tmp directory:

	'datadirectory' => realpath(__dir__ . '/../data'),
	'tempdirectory' => realpath(__dir__ . '/../data/tmp'),

Maybe it helps other users here with similar problems.

I just did that.

1 Like

This solution works for us. A Pull request is in the making.

Others are confirming what @ernolf states above: from a NC perspective it is OK to turn off open_basedir. In plesk or cPanel you can by setting it to none if your provider allows. In DirectAdmin it is always admin-only AFAIK.

But it might break other applications, like old WordPress plugins.

Edit: the first PR was closed, a new one is waiting for review.

Thank you very much. I moved the nproc.php to the right place and now I get

sh: nproc: command not found
Hardware concurrency: 0

Exec is available and since I edited the Generator.php I didn’t get the “open_basedir” error. Although I don’t seem to have a CPU and nproc command…

What is your platform?
Looks like nproc is not available on your system. (Find out with which nproc)

but that shouldn’t be a problem, because a solution is already being developed that doesn’t need it.

With your code under New: the error goes away for us (shared hosting on CentOS, Litespeed, DirectAdmin) but Nextcloud Files gets a little sluggish. The list of files appears slower.

If your in a Plesk environment (or cPanel, DirectAdmin) there probably is no console…

But cloud.mydomain.tld/nproc.php results in:

Hardware concurrency: 0

From an info panel in WordPress on the same host I know we’re on a 10 core Xenon Silver.

This means the function does not work on your system. The fact that the error message is gone does not mean that the alternative works with all those restrictions!
If I were you, I would wait a little longer until a new patch was issued that generally solves this or look around for a proper hosting alternative. I honestly wouldn’t even consider such shared hosting from the start, it would drive me crazy.

The nice thing about shared hosting is that the number of cores in the CPU doesn’t change very often. So Nextcloud should not have to check that on every preview :smiling_imp:

But more serious: the official Nextcloud documentation provides information on how to install it on shared hosting and the website promotes a web installer (under Community projects). We get some warnings in Administration > Overview like ‘PHP modules “gmp” and/or “bcmath” are not enabled’ but nothing about open_basedir settings.

Also many hosting providers offer a tool called Installatron that helps installing AMP application with limited technical knowledge.

The problem is that many regulars in the community are running their own dedicated server and are looking down on shared hosting or Docker / Snap variaties.

I’m running it on my own Ubuntu server at home for personal use but since a year also on shared hosting for two associations where I’m a volunteer webmaster. It has worked very well to keep data centralized and control access. Otherwise teams and committees will spread data over ad hoc Dropbox en Google drive groups with all the related GDPR problems.

We only use Nextcloud files, < 50 users, a few hundred documents. The backup solution included with Installatron works fast and easy, a lot better than the ‘official’ Nextcloud Backup app.

It is also in the commercial interest of Nextcloud to make and keep it working well on shared hosting. Members of these associations work for companies or own them. A commercial Nextcloud provider already got a paying customer because saw how I made it work. Likewise MailPoet and Woocommerce got new customers this way.

Then you can help with your experience expertise to make things better :+1:

Yes willemb2 this fix solves the problem

Check for open_basedir before reading /proc #37959


Still occours in Nextcloud 26.0.2

Would be nice to add this fix for Nextcloud 26.0.3 and not later in 27.x.
Or should be backported.

Great thanks.

Unfortunately, the error still occurs in Nextcloud 26.0.4 and Nextcloud 27.0.1.

If I understand it correctly, the solution to this problem is postponed to Nextcloud 28.

Anyway, with the fix from @anon78853765’s post it works very well for me.

@camouflage81 We just moved to another hosting that is using Plesk. A simple workaround on Plesk is by going to Websites & Hosting > PHP Settings and add {:}/proc/ to the open_basedir field. In our case the default was {WEBSPACEROOT}{/}{:}{TMP}{/} and I changed that to {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/proc/

As I understand it there are 2 competing PR’s being discussed now on Github:

Check for open_basedir before reading /proc by solracsf · Pull Request #37959 · nextcloud/server · GitHub (already mentioned above)


In my experience, for small scale Nextcloud setups on shared hosting the only issue is the flood of open_basedir restriction errors in the log. We encourage our (35) users to only use the clients and we’re not seeing any performance issues.

The error has now been corrected in Nextcloud Hub 6 (27.1.4).
A modification of the file “Generator.php” is no longer necessary.

In Nextcloud Hub 4 (26.0.9) the error is unfortunately still present.
For Nextcloud to function correctly in web hosting, the “Generator.php” file must unfortunately still be modified.

Change in the code of the file lib/private/Preview/Generator.php from line 351


			if (is_file("/proc/cpuinfo")) {
				$width = substr_count(file_get_contents("/proc/cpuinfo"), "processor");


			if (function_exists('ini_get')) {
				$openBasedir = ini_get('open_basedir');
				if ($openBasedir == '') {
					$width = is_readable('/proc/cpuinfo') ? substr_count(file_get_contents('/proc/cpuinfo'), 'processor') : 0;
				} else {
					$openBasedirPaths = explode(':', $openBasedir);
					foreach ($openBasedirPaths as $path) {
						if (strpos($path, '/proc') === 0 || $path === '/proc/cpuinfo') {
							$width = is_readable('/proc/cpuinfo') ? substr_count(file_get_contents('/proc/cpuinfo'), 'processor') : 0;
						} else {
							$width = 0;
1 Like