[Bug]: wrong directory for temporary PHP path (nc 28.0.5 and 29 / php-fpm)

[bbx-github]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Error while checking the temporary PHP path - it was not properly set to a directory. Returned value: /tmp

The error seems to be plain wrong since php config was not changed.

Happens

• after updates 28.0.4 -> 28.0.5
• fresh installation of 28.0.5
• fresh installation of 29.0.0

in use:

• php-fpm8.2 with open_basedir
• tested with apache2 and nginx

Steps to reproduce

1. use php-fpm
2. set upload_tmp_dir to other than "/tmp"
3. set open_basedir accordingly

Expected behavior

Everything just works.

Installation method

Community Manual installation with Archive

Nextcloud Server version

28.0.5.1, 29.0.0

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

apache, nginx

Database engine version

MariaDB, postgresql

Is this bug present after an update or on a fresh install?

Both

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "nc28.<mydomain>"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "28.0.5.1",
        "overwrite.cli.url": "https:\/\/nc28.<mydomain>",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "default_language": "de",
        "default_locale": "de_DE",
        "default_phone_region": "DE",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": "0",
            "timeout": "0"
        },
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "updater.release.channel": "stable",
        "upgrade.disable-web": "true",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_sendmailmode": "smtp",
        "mail_smtpport": "465",
        "mail_smtpsecure": "ssl",
        "mail_smtpauth": "true",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "loglevel": 2,
        "maintenance_window_start": 1
    }
}

List of activated Apps

Enabled:
  - activity: 2.20.0
  - circles: 28.0.0
  - cloud_federation_api: 1.11.0
  - comments: 1.18.0
  - contactsinteraction: 1.9.0
  - dashboard: 7.8.0
  - dav: 1.29.1
  - federatedfilesharing: 1.18.0
  - federation: 1.18.0
  - files: 2.0.0
  - files_pdfviewer: 2.9.0
  - files_reminders: 1.1.0
  - files_sharing: 1.20.0
  - files_trashbin: 1.18.0
  - files_versions: 1.21.0
  - firstrunwizard: 2.17.0
  - logreader: 2.13.0
  - lookup_server_connector: 1.16.0
  - nextcloud_announcements: 1.17.0
  - notifications: 2.16.0
  - oauth2: 1.16.3
  - password_policy: 1.18.0
  - photos: 2.4.0
  - previewgenerator: 5.5.0
  - privacy: 1.12.0
  - provisioning_api: 1.18.0
  - recommendations: 2.0.0
  - related_resources: 1.3.0
  - serverinfo: 1.18.0
  - settings: 1.10.1
  - sharebymail: 1.18.0
  - support: 1.11.1
  - survey_client: 1.16.0
  - systemtags: 1.18.0
  - text: 3.9.1
  - theming: 2.3.0
  - twofactor_backupcodes: 1.17.0
  - updatenotification: 1.18.0
  - user_status: 1.8.1
  - viewer: 2.2.0
  - weather_status: 1.8.0
  - workflowengine: 2.10.0
Disabled:
  - admin_audit: 1.18.0
  - bruteforcesettings: 2.8.0
  - encryption: 2.16.0
  - files_external: 1.20.0
  - suspicious_login: 6.0.0
  - twofactor_totp: 10.0.0-beta.2
  - user_ldap: 1.19.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

{"reqId":"02Gv01l6yF38","level":3,"time":"2024-04-26T01:30:23+00:00","remoteAddr":"2003:ec","user":"XXXX","app":"PHP","method":"GET","url":"/settings/ajax/checksetup","message":"is_dir(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (XXXX/htdocs/:XXXX/tmp/:XXXX/data/:/dev/urandom:/proc/meminfo) at XXXX/htdocs/apps/settings/lib/SetupChecks/TempSpaceAvailable.php#83","userAgent":"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0","version":"28.0.5.1","data":{"app":"PHP"}}

Additional info

The error disappears if /tmp is added to open_basdir

[joshtrichards]

That value is coming from PHP's sys_get_temp_dir() which doesn't use the PHP INI parameter upload_tmp_dir, but the sys_temp_dir parameter.

The open_basedir restriction is preventing the configured PHP INI sys_temp_dir (/tmp in this csae) from being useful to Nextcloud.

There may be some room here to adjust this check a bit though it seems like. It's currently only checking sys_get_temp_dir(), but our real temporary folder selector is much smarter than the setup check:

server/lib/private/TempManager.php

Lines 212 to 249 in acf8ea1

	public function getTempBaseDir() {
	if ($this->tmpBaseDir) {
	return $this->tmpBaseDir;
	}
	$directories = [];
	if ($temp = $this->config->getSystemValue('tempdirectory', null)) {
	$directories[] = $temp;
	}
	if ($temp = $this->iniGetWrapper->get('upload_tmp_dir')) {
	$directories[] = $temp;
	}
	if ($temp = getenv('TMP')) {
	$directories[] = $temp;
	}
	if ($temp = getenv('TEMP')) {
	$directories[] = $temp;
	}
	if ($temp = getenv('TMPDIR')) {
	$directories[] = $temp;
	}
	if ($temp = sys_get_temp_dir()) {
	$directories[] = $temp;
	}
	foreach ($directories as $dir) {
	if ($this->checkTemporaryDirectory($dir)) {
	return $dir;
	}
	}
	$temp = tempnam(dirname(__FILE__), '');
	if (file_exists($temp)) {
	unlink($temp);
	return dirname($temp);
	}
	throw new \UnexpectedValueException('Unable to detect system temporary directory');
	}

We only use the return value of sys_get_temp_dir() (aka: the value of the sys_temp_dir PHP INI setting) as a last resort in practice.

EDIT: Even if the setup check gets adjusted, it would probably be a good idea to make sure your PHP environments sys_temp_dir is pointed somewhere that can actually be accessed. It should make the error go away.

[bbx-github]

@joshtrichards Thanks a lot!

Setting sys_temp_dir fixed it for me.
But to me it is really strange that this change was introduced from 28.0.4 -> 28.0.5 and broke my setup.

[RainerThe]

@joshtrichards Thanks a lot!

Setting sys_temp_dir fixed it for me.

Great, but I've no idea what to do exactly! Could you please provid me with more details? Which file? Which entry do I have to change or to add? I'm not realy experienced!

[AnrDaemon]

@joshtrichards Thanks a lot!

Setting sys_temp_dir fixed it for me. But to me it is really strange that this change was introduced from 28.0.4 -> 28.0.5 and broke my setup.

How did it "broke" your setup?

[gersteba]

@joshtrichards Thanks a lot!
Setting sys_temp_dir fixed it for me.

Great, but I've no idea what to do exactly! Could you please provid me with more details? Which file? Which entry do I have to change or to add? I'm not realy experienced!

Me neither ...

After update to 28.0.5 having the same message:
"Error while checking the available disk space of temporary PHP path or no free disk space returned. Temporary path: /tmp"

@joshtrichards please explain - thank you!

[intervisionlord]

EDIT: Even if the setup check gets adjusted, it would probably be a good idea to make sure your PHP environments sys_temp_dir is pointed somewhere that can actually be accessed. It should make the error go away.

I have both parameters upload_tmp_dir and sys_temp_dir pointed to /tmp
This directory fully accessible for web-server and php (and other users and groups which need it) and i still have this error...

I have this issue with apache2 + nginx (php as apache mod_php) with NC 29, so the topic starter have this issue with php-fpm. It looks like a bug which appears on different systems.

Other apps and sites which uses this parameter and write data to tmp have no issues with it. ONLY Nextcloud have this issue.

[AnrDaemon]

Given the problem with setting up PHP access to system temp directory, I don't see why would not use upload_tmp_dir always?

[gersteba]

EDIT: Even if the setup check gets adjusted, it would probably be a good idea to make sure your PHP environments sys_temp_dir is pointed somewhere that can actually be accessed. It should make the error go away.

I have both parameters upload_tmp_dir and sys_temp_dir pointed to /tmp This directory fully accessible for web-server and php (and other users and groups which need it) and i still have this error...

I have this issue with apache2 + nginx (php as apache mod_php) with NC 29, so the topic starter have this issue with php-fpm. It looks like a bug which appears on different systems.

Other apps and sites which uses this parameter and write data to tmp have no issues with it. ONLY Nextcloud have this issue.

I have added to my php.ini:
sys_temp_dir=/tmp
upload_tmp_dir=/tmp

And I have added to Nextcloud's config.php:
'tempdirectory' => '/tmp',

Directory root/tmp has these rights:
775

PHP version: 8.2.19
Nextcloud version: 28.0.5

Still getting this:
"Error while checking the available disk space of temporary PHP path or no free disk space returned. Temporary path: /tmp"

Even 777 for /tmp does not make a difference to the problem.
In previous Nextcloud version there was no problem with /tmp (the Nextcloud files are still stored there).

Please fix asap - thank you!

Greetings, Gerald

[gersteba]

In the meantime my webhoster informed me about following:
Nextcloud uses 'disk_free_space', which function is disabled by the webhoster for security reasons.
This seems to cause the problem after the update to 28.0.5 now.
Is this the same with you guys, who are also facing the "Error while checking the available disk space of temporary PHP path or no free disk space returned. Temporary path: ..."?

EDIT:
Seems, as if there is the lack of the check
if (function_exists('disk_free_space')) {
at some places now.

[RainerThe]

Hello, same for me after update to nc 29. message: Returned value: /volume1/Nextcloud/Nextcloud-temp. Any solution?

So, I found a realy easy solution for me: I just createt that missing folder and the message disappears!
And what's funny: nothing is inside that folder !

[AnrDaemon]

Thanks for the note, @gersteba .
According to https://www.php.net/manual/en/function.sys-get-temp-dir.php#115199 and https://www.php.net/manual/en/ini.list.php , sys_temp_dir is, indeed, an option, although undocumented.

[AnrDaemon]

Aaaandd… YES! Setting php_admin_value sys_temp_dir … to a suitable value removes the alert in diagnostics.

[AnrDaemon]

In the meantime my webhoster informed me about following: Nextcloud uses 'disk_free_space', which function is disabled by the webhoster for security reasons.

Then move your project to a hoster that did not lost its sanity.

[gersteba]

Then move your project to a hoster that did not lost its sanity.

Why do you say this?

[AnrDaemon]

Then move your project to a hoster that did not lost its sanity.

Why do you say this?

Because function by itself is not a threat, no matter what parameters you pass to it. It MAY be an information disclosure, IF you display its output to the user.
I understand, why I disable eval (and I hope you do too), I can understand, why somebody want to disable phpinfo() (although in a sufficiently secured installation, it couldn't be used for anything sensible), but disabling some random functions just because somebody could lay an eye on their output… it all seems rather random.

[intervisionlord]

Aaaandd… YES! Setting php_admin_value sys_temp_dir … to a suitable value removes the alert in diagnostics.

Doesn't work

[AnrDaemon]

Then you did something wrong.

[intervisionlord]

Then you did something wrong.

no, i didn't.

Besides, this prolem appears after NC upgrade, without changes of my server by me. So, it’s more logical to assume that the NC developers did something wrong in one of the updates.

With each new version there are more and more problems, because each new version requires more and more changes in the server infrastructure. It seems to me that development should not proceed this way. Changes of this kind must go through multiple stages of testing on various benches and systems. Don't show up unexpectedly and cause inconvenience.

Now it goes something like this:

• developers in the previous version: in this version the system requirements have changed - now your server should look like this...
• developers in the new version: in this version the system requirements have changed - now your server should look like this...

And the community be like this:

This solution works for me, so it should work for everyone. And if it doesn’t work for you, you’re doing something wrong. I don’t know what experience you have in administration, what system you have and what infrastructure components, but I’m sure that you’re doing it wrong, because everything works for me.

Please, let's look at the problem using an objective approach and find the correct and universal solution that will suit everyone.

[AnrDaemon]

Dude. Don't set it to /tmp. That's why it complains. Your FPM don't have access to /tmp.

[AnrDaemon]

php_admin_value sys_temp_dir "/where/is/your/nextcloud/upload_temp_dir"

[Jolopu]

intervisionlord is absolutely right. I got the same issue since NC 28 upwards on my test installation. My live installation is still on NC 27 and runs without any issues. NC development is heading the wrong way. They just bring in new issues with upgrades. This one is just one of them. I will never upgrade my live install until all the issues in the newer versions are resolved.

[intervisionlord]

Your FPM don't have access to /tmp

Are you sure? I am asking because you make strange statements like access permissions and my web-server.
Firstly, because i don't use php as Fast CGI FPM. i use php as mod-apache.
secondly, i granted enough permissions to web-server user and group (as i said, other sites on this web-server can use /tmp without any issues)
So, i am just curious, why are you making statements based on your guesses, which have nothing to do with the parameters of my server? "Dude"...

So, as I suggested earlier, let’s still take a more objective approach to finding a solution to the problem, and not accuse each other of incompetence based only on our guesses and assumptions about the configurations of each other’s servers. If your web server is configured in one way and a specific solution works for you, do not assume that everyone is configured the same way.

[AnrDaemon]

Again, that warning SPECIFICALLY happens, when your PHP process is unable to access sys_temp_dir (which is, by default, unless altered, is /tmp).
To get around it, you have to, either,

1. Set TMP= env var before running the process that manages PHP script execution.
2. Configure PHP to avoid relying on TMP=.

[intervisionlord]

When a process cannot access a directory, this is displayed in the web server logs if the PHP is correctly configured in the error reporting parameter

There is no need to confuse the web application message, (which can be displayed if the accessibility check method is incorrect (which is what is discussed in this thread) or because of errors in programming logic,) and the system message from the web server and its application components, such as PHP.

If I put my script near to the NC installation, which will try to gain access to the /tmp and show that everything is working correctly, will you stop trying to prove to me that the error is on my side and join in an objective and unbiased discussion, a constructive and joint search for the problem?

> cat temp_test.php
<?
        $test_file = fopen("/tmp/test_file.txt", "w");
        fwrite($test_file, "test message");
        fclose($test_file);
?>

> /opt/php82/bin/php temp_test.php
>

> ls -la /tmp/test_file.txt
-rw-r--r-- 1 <web-user> <web-group> 12 июн 19 21:03 /tmp/test_file.txt
>

> cat /tmp/test_file.txt
test message
>

> /opt/php82/bin/php -v
PHP 8.2.0 (cli) (built: Jun 29 2020 09:25:38) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.0, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.0, Copyright (c), by Zend Technologies
>

> pwd
/var/www/<username>/data/www/<NC-site-folder>
>

> whoami
<web-user>
>

> ls -la / | grep -i tmp
drwxrwxrwt  10 root root 20480 июн 19 21:12 tmp
> 

php_admin_value sys_temp_dir "/where/is/your/nextcloud/upload_temp_dir"

You will probably be very surprised, but I also have this directory /tmp and (surprise surprise) there are no problems or errors with it, which once again proves that the problem is precisely in the incorrect determination of the directory’s availability specifically for temporary files on the part of the NC

How do you think why does NC have no problems in the case of upload_temp_dir, but in the case of sys_temp_dir there are?

[AnrDaemon]

PHP CLI app and PHP run by Apache webserver are TWO DIFFERENT APPS.
With different process restrictions.
Stop trying to prove in shell that a web app works fine.

[intervisionlord]

PHP CLI app and PHP run by Apache webserver are TWO DIFFERENT APPS. With different process restrictions. Stop trying to prove in shell that a web app works fine.

Another surprise for you, maybe, but my CLI version and WEB version are the same.

ughhh... i am really tired to talk with you...

<?

echo sys_get_temp_dir();

$test_text = " testing tmp dir availability";

$file = "/tmp/test_file.txt";
file_put_contents($file, $test_text);
$test_file_content = file_get_contents("/tmp/test_file.txt");

echo $test_file_content;

?>

Think as you like, as I understand it, no one is going to solve the problem. Okay, whatever you want. I'm just tired of proving something to people who are sure that they know better than me how my server is configured and give advice based on their conjectures.

[AnrDaemon]

Same version does not mean same executable and same configuration.
If your /tmp is writable from your Nextcloud install, you should not see this warning.
If you still see it, that means an instance running your Nextcloud server have different configuration from what you use in your tests.
Most obvious suspicion would be open_basedir restriction, which I consider a good idea, in general. I've had it set myself, and fixed the resulting warning with abovementioned tweak to relevant **host.conf file.

[kesselb]

The code for the setup check: https://github.com/nextcloud/server/blob/master/apps/settings/lib/SetupChecks/TempSpaceAvailable.php#L54

If you comment, please mention the exact error message to map it to the right code.

The check looks at our temp manager, which uses a couple of available paths and php's sys_get_temp_dir. Most likely because our temp manager is only used in Nextcloud and 3rdparty libraries usually use sys_get_temp_dir. Actually, our temp manager should only look at sys_get_temp_dir and ignore the other options. However dropping those will likely break someone else's setup out there. However the most correct approach because most php libraries will follow, is to rely on sys_get_temp_dir.

See https://github.com/php/php-src/blob/106581b1b6564971489e5b0ac80a760c6689fdd7/main/php_open_temporary_file.c#L235 to understand what php does internally.

[AnrDaemon]

I'd probably break somebody's cardboard castle, but no PHP program should rely on sys_get_temp_dir, if it does not runs in CLI.
In a context of web request, it could be reasonable expected that the available directories are the only those directly related to the request. The code directory and the upload_tmp_dir. Nothing else.

[kesselb]

Hi,

I've prepared a pull request for 29.0.4 (2024-07-1) changing the check a bit: #46190

• The original report was about sys_temp_dir pointing to /tmp which was forbidden by open_basedir. That was easy to spot from the logs.
• The second case is that disk_free_space is disabled. We are showing the same warning if the function is disabled and if the function result was false, and therefore the problem is difficult to spot. This will be improved by the patch.
• If you are still seeing the error with 29.0.4 please log a new issue and provide the exact error message.

[famo]

@kesselb
Thank you for the fix. Will there also be an update for NC28?

Also, just to be sure, users with this error message can use their NC just as normal, including updating?

[AnrDaemon]

users with this error message can use their NC just as normal

Yes, this is merely a warning that the configuration is probably suboptimal, but otherwise, by itself it does not stop you from using your instance.

[famo]

Ok, thx for the info.
However the message is cleary displayed as an error message in NC. It would be good, to change it to a warning then.

[gersteba]

Thank you for changing the error message into a warning message in version 29.0.4:
"The PHP function "disk_free_space" is disabled, which prevents the check for enough space in the temporary directories."

Maybe a more informative explanation, what probable disadvantage or actually harmlessness of that function being disabled has, might be useful for non-involved users.
See i. e. AnrDaemon's comment above:
"Yes, this is merely a warning that the configuration is probably suboptimal, but otherwise, by itself it does not stop you from using your instance."