Dietpi: Temporary directory /var/tmp/php_upload_tmp is not present or writable

[MichaIng]

Creating a bug report/issue:

Required Information:

• DietPi Version | 155
• SBC Device | RPi2
• Power supply used | 5V 2A
• SD card used | Kingston SDCA3/64GB
• Distro | Stretch

Additional Information (if applicable):

• Nextcloud, at least
• Sorry, I did not try and have no chance to do that soon.

Expected behaviour:

No error message inside Nextcloud log.

Actual behaviour:

Warning in Nextcloud log: Temporary directory /var/tmp/php_upload_tmp is not present or writable
over and over again several times in a second during web ui access.

Steps to reproduce:

I watched this directly after first successful installation of DietPi Stretch Beta image. This can be ignored by setting log level to not show "warnings".

Did you submit a dietpi-bugreport?

9a585d60-960b-4e00-a622-e94d45330a37-0
Maybe I removed some archive apt package too much, as I got zip command not found during bug report.
_€: 9a585d60-960b-4e00-a622-e94d45330a37-1
This worked better after apt install zip :). Again found strong reason for dependency package, as I am still trying to remove as much as possible 😛 .
iwconfig still missing, because I removed all wireless related packages and don't use it._

Extra details:

https://help.nextcloud.com/t/missing-upload-tmp-or-not-writable/7872/5?u=michaing

[MichaIng]

https://github.com/owncloud/core/issues/22183#issuecomment-181325772
But I don't find systemd.service on my system and don't know how to disable PrivateTmp=true and if this is actually a good idea. Any other possibility to enable PHP to see and write to this directory?

[Fourdee]

@MichaIng

Is this issue still occurring, after all the Nginx/NextCloud PR's?
https://github.com/Fourdee/DietPi/issues/1067

[MichaIng]

Hmm totally forgot. Don't see it anymore on my machines, even not on my production system where nothing was affected by PRs... can be closed as for now.

[MichaIng]

@Fourdee Error still there, just appeared on fresh Nextcloud installation

[MichaIng]

Hmm does only show up on my RPi2 system, the VMs (Jessie and Stretch) don't show this. Seems to be a platform specific issue/feature with this private tmp folder.

[Fourdee]

@MichaIng

Thanks, good find 👍

Seems the only solution is to manually edit each service to disable PrivateTmp, no global options known:
https://www.maxoberberger.net/blog/2017/10/debian-9-private-tmp.html

[Fourdee]

Unable to replicate on Odroid C2 Stretch, lighttpd

I'll mark this is a unable to replicate/possible known issue, low priority as this is only a warning in logs.

[MichaIng]

@Fourdee
Just read a bid more about it: https://access.redhat.com/blogs/766093/posts/1976243 and http://0pointer.de/blog/projects/security.html

So basically the idea of this feature sounds totally reasonable to me: Every service (that enables this) has it's own /tmp and /var/tmp folder, thus can't see any other tmp files and other services can't see it's tmp files. Enhances security significantly. At least apache2 seems to have this enabled on raspbian stretch repo. At least nginx/php-fpm on debian (Jessie + Stretch) doesn't. Of course in case of php-fpm, the webserver should not play a role, what would explain that your Odroid+Lighttpd is also not affected. We can go through repo+webserver/php-connector combinations to see how far it reaches, but so far looks like an Apache2 issue. As it must break all PHP temporary file creations, I would not mark it as Low, but would try to fix it fast, who knows which software can fail with broken access to php upload tmp dir. Will test file upload with Nextcloud/ownCloud later.

We change the directory to /var/tmp/php_upload_tmp here: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-software#L8869-L8900
This folder is also affected by privatetmp. We could simply switch it to /var/tmp (without subdirectory) to solve the problem (at least it @should). We could do this just for systems with privatetmp enabled to prevent file name overlaps and stuff like that, and even chmod /var/tmp/php_upload_tmp on systems with privatetmp disabled to only allow www-data read access to it, to enable also sort of privacy there.

Will do further tests later.

[MichaIng]

Okay checked: Issue is also present on Debian Stretch Repo, thus it is: Apache+Stretch
Setting upload_tmp_dir = /var/tmp indeed solves the problem. We could do check for Apache+Stretch to set this different location during php installation.

[MichaIng]

On Stretch:
root@192:~# cat /lib/systemd/system/apache2.service

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
Environment=APACHE_STARTED_BY_SYSTEMD=true
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl stop
ExecReload=/usr/sbin/apachectl graceful
PrivateTmp=true
Restart=on-abort

[Install]
WantedBy=multi-user.target

Nginx and php-fpm systemd services do not have this.
On Jessie apache is still init.d server:
root@192:~# service apache2 status

● apache2.service - LSB: Apache2 web server
Loaded: loaded (/etc/init.d/apache2)
Drop-In: /lib/systemd/system/apache2.service.d
└─forking.conf
Active: active (running) since Sat 2017-11-25 18:31:17 CET; 16min ago
Process: 893 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/apache2.service
├─914 /usr/sbin/apache2 -k start
├─918 /usr/sbin/apache2 -k start
└─919 /usr/sbin/apache2 -k start

We could also specifically look for this entry in php-fpm/apache service file an chose upload_tmp_dir accordingly.

The more I read, the more I actually like PrivateTmp. Do dietpi serives also use the /tmp folders? In case they can also use the feature to have their own undisturbed tmp folder 🙂.

[LexiconCode]

@MichaIng This issue has Cropped up again as discribed in OP but with /var/tmp
DietPi version | 6.15-14
Distro version | Stretch
SBC device | Odroid HC2

level":2,"time":"2018-09-30T21:15:01+00:00","remoteAddr":"","user":"--","app":"no app in context","method":"","url":"--","message":"Temporary directory \/var\/tmp is not present or writable","userAgent":

Edited for clarity

[MichaIng]

@LexiconCode
Thanks for reporting.

\/var\/tmp

This is strange, since this should always be available and global r/w-able. The error above was due to subdir /var/tmp/php_upload_tmp.

Which webserver do you use, and can you please paste result of:
ls -al /var/tmp

[LexiconCode]

@MichaIng
I recognize that's not the exact same error but close enough in nature for fit within the issue.

Apache2

root@DietPi:~# ls -al /var/tmp
total 20
drwxr-xr-x 5 root root 4096 Sep 30 23:39 .
drwxr-xr-x 12 root root 4096 Aug 31 10:05 ..
drwxr-xr-x 3 root root 4096 Aug 27 02:11 dietpi
drwx------ 3 root root 4096 Sep 30 22:45 systemd-private-82f40b17a88d40f6bba4300d82bfb94c-apache2.service-m4i7zj
drwx------ 3 root root 4096 Sep 30 22:45 systemd-private-82f40b17a88d40f6bba4300d82bfb94c-redis-server.service-mu32x2

[MichaIng]

@LexiconCode

drwxr-xr-x 5 root root 4096 Sep 30 23:39 .

Strange, this is not how it should be. On all my machines the dir is 777 chowned. But the private apache2 tmp dir in place. I am not sure how exactly permissions for www-data are handled then, but could you simply try:
chmod 777 /var/tmp

[LexiconCode]

@MichaIng Time will tell but that seems to be a fix. 👍

[MichaIng]

@LexiconCode
Jep, please report back if it works.

Do you remember something you changed/installed before the error appeared?

[LexiconCode]

@MichaIng looking over the logs this morning the workaround was successful.

This was a relatively new install. Another piece of dietpi supported software must have changed permissions as I did not make any alterations manually. So when something is uninstalled or installed I'll have a better idea what it is if it reoccurs.

[MichaIng]

@LexiconCode
Okay I added chmod 777 /var/tmp to our setpermissions function, which will run after every dietpi-software execution. As well it will be done on v6.17 update once:
https://github.com/Fourdee/DietPi/commit/9d494801393d43de43c7a0ead9ef649a41773f52
https://github.com/Fourdee/DietPi/commit/009f26a54bfef10f57e1e58ca68f346037d5d008

🈯️ Verified this being the default on fresh Debian install, so should be (still) considered as safe and expected.

I will mark this issue as closed again.

[ZerooCool]

@MichaIng

really ?
chmod 777 /var/tmp

It's not ?
chmod 1777 /var/tmp

[MichaIng]

@ZerooCool
You are right, the sticky bit makes definitely sense here and as well seems to be default on Debian, as result from quick web search.
Adjusted: https://github.com/MichaIng/DietPi/commit/9846e8136f23a2ad08c9f9262ea7c4d142e6844d