37

I'm trying to write a file to my /tmp directory (on an apache server) with the php fopen function, but it fails:

<?php
$handle = fopen("/tmp/test.txt", "x");
if ($handle) 
   echo "Success!";
else 
    print_r(error_get_last());

This returns the error message:

failed to open stream: No such file or directory.

The /tmp directory has permissions set to drwxrwxrwt and I can see that the web user is writing other files to it. Mysteriously, if I point the script to another folder with permissions 777, it returns success. But my open_basedir has no value. I have safe_mode=on and allow_url_fopen=off, but I don't think that should explain it?

This is PHP 5.3.10 on Apache Httpd 2.0.

Eddie C.
  • 787
  • 9
  • 16
Anders Sundnes Løvlie
  • 776
  • 2
  • 7
  • 11
  • No, the point of the above script is to test whether I can create files in my /tmp folder. I have tried the script with both the 'x' and the 'w' flags. – Anders Sundnes Løvlie May 25 '12 at 10:11
  • Thanks Robus - that sounds quite possible - the server is on a large, fairly complex university network. How could I verify whether that's the issue? – Anders Sundnes Løvlie May 25 '12 at 11:34
  • Try doing an "ls -l /tmp" or the equivalent. I'm running into this issue on Perl, and the /tmp directory the script is seeing is very different from what's in my actual /tmp directory. –  May 31 '17 at 12:30

4 Answers4

63

I had exactly the same problem. PHP reported no problem with opening file in /tmp/myoutputfile, but no file was in that path. Then I did 

find / -name "myoutputfile"

and found it in /tmp/systemd-…/myoutputfile. I've found this article on Google.
So, in my case, it was a Systemd and Apache Httpd combination. I hope this will help to someone.

Eddie C.
  • 787
  • 9
  • 16
Andrey Kartashov
  • 1,300
  • 1
  • 12
  • 20
  • This is huge! Caused a hard to find bug in a Drupal RHEL 6 to RHEL 7 upgrade where the Drupal file_temp_directory was set to /var/tmp/drupal but images styles were failing to be generated because the drupal directory had not been created yet. Once going to an admin page (e.g. admin/config) where it made the directory then image styles were generated properly. Restarting the server caused the bug to appear again, but only realized that in hindsight, was incredibly hard to reproduce. – Elijah Lynn Mar 01 '17 at 16:05
  • 1
    When using PHP-FPM, remeber checking the `PrivateTmp` flag in the `php-fpm.service` unit rather than the Httpd or NGINX ones. – Eddie C. Jul 18 '19 at 18:02
17

Your problem is likely caused by the combination of systemd and apache. It's a security feature called PrivateTmp, and obviously it's an opt out.

If you don't want it, you can disable it like this:

  1. Outcomment the respective switch in /etc/systemd/system/multi-user.target.wants/apache2.service: #PrivateTmp=true
  2. Restart systemd: sudo systemctl daemon-reload
  3. Restart apache: sudo systemctl restart apache2
untill
  • 1,229
  • 14
  • 19
1

Try to add /tmp to open_basedir. For example:

    php_admin_value open_basedir /some/path:/another/path:/tmp

I'm not sure this is the problem you actually faced, but I found your question while looking for this solution so I guess that might help someone else.

philippe_b
  • 33,481
  • 6
  • 49
  • 47
0

According to the error message displayed, there is no folder /tmp/. Perhaps the tmp folder is somewhere else than the root?

This error will not show if the file actually doesn't exist, as it will attempt to create it.

Method x also returns a warning if the file already exists. (doc: http://www.php.net/manual/en/function.fopen.php)

I think this also goes for another reason this could go wrong, is the user which executes PHP doesn't have rights to write in the /tmp/ folder.

Rene Pot
  • 23,406
  • 6
  • 64
  • 89
  • As I wrote in the question, there IS a folder called /tmp on my server, yes it resides on the root, and from what I can tell the user which executes php does write files to the /tmp folder continuously. – Anders Sundnes Løvlie May 25 '12 at 10:15