Warning: touch(): Utime failed

Got this on today's 8.1.x HEAD, at /admin/config/development Running on single server Ubuntu 16.10: MySQL 5.7, PHP 7, standard install profile. Installed contrib: devel, kint, config_inspector, all at current HEAD. Local (but sloooow) file system on magnetic disk.

Downgrading to normal because it doesn't prevent site use.

Probably significant : the error does not reappear when refreshing page.

I attached the full trace because it's rather noisy.

Isn't that mostly a permission issue? Maybe you are running some CLI scripts as a different user, which then lets phpstorage have directories with different users.

Something is indeed strange here: directories starting at sites/default/files/php/twig have permissions 0777/myself/www-data and twig-compiled files are 0644/myself/www-data (my umask is 0002 and my primary group is www-data).

Even stranger is the fact that the error does not recur on refresh.

We run into this problem constantly on Pantheon, and I'm not sure why yet. After clearing the cache, we often see a ton of these error messages show up once the first time a page is loaded, then not again until the next cache clear.

They fill up the DB logs and are really annoying, but don't appear to cause any actual problems with the site. I'd very much like to find a fix, however.

The errors seem to be:

Warning: touch(): Utime failed: No such file or directory in Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage->save()

Followed by a bunch of errors about specific twig cache files such as:

Warning: filemtime(): stat failed for sites/default/files/php/twig/5909ef0b8825a_commerce-cart-blocks-cart_MaNNmvNIStysTb2NfG4WkcQNO/9qdTOGo5K4ECts7czpasaqgXDVY7qI8qIGBhQca3glQ.php in Drupal\Component\PhpStorage\MTimeProtectedFileStorage->checkFile()

Me too.
Only just starting to wonder if I need to debug it.
FWIW, I just started seeing it on the switch from a dev env running apache2handler on PHP Version 7.0.15-0ubuntu0.16.10.4 - where we didn't see the error - to cgi-fcgi (Identical OS)
So it feels related to the permissions of the user account that fcgi delegates to.

I'm about to go looking carefully at the file perms now... It's quite possible they need a tweak, as I just did a full files transfer to the new server.

@bmcclure I am also experiencing this issue with Pantheon.

It appeared after I updated to 8.3.0 and think it has something to do with thousands of twig files being generated. It is coupled with very bad performance until I clear the cache. I can't say whether the file generation is a fault of mine or not but will keep this thread updated as I am looking into the issue atm.

Aaron

I changed permissions of the google_tag folder so that my Apache can access it and this issue was resolved for me. However, on every cache reset, the ownership of my google_tag folder is reset and the error occurs again.

Please update your version PHP>=7.2

This is main requirement of Drupal core 8.8/8.9 and above.

I'm running PHP 7.2 and I'm still getting this. So that's not the problem.

Fixing status as there's no code here.

This appears to be an uncommon error. It has been reported to happen with Pantheon and outdated versions of PHP and Drupal.

Is anyone experiencing this error on a currently supported version of Drupal?

If so, reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core") and your PHP version, Drupal version and environment.

Thanks

I've got this problem on a new local install with Docker. Also Ubuntu/Pantheon. I'm running Drupal 9.4.8 and PHP 8.0.24.

This is happening on 9.4.8 and PHP 8.1 for us as well, on a production site. Not clear what is causing it. The call stack does show the issue is related to twig.

Same as #26 but on D9.5.1/Ubuntu 22.04 with php 8.1.14

It happens each time I uninstall a module with the GUI. (But it happens also on other occasions, but I don't see a pattern)

I found the reason why this warning pop-up: this is because the PHP touch() function works only if the file or directory being touched is owned by the PHP user (www-data for apache). If the file or directory have only the group set as www-data it will not work.
As a requirement we must say that all Drupal temp files must be www-data:www-data

We are experiencing this problem on NFS based filesystem.
We had distributed system where many hosts worked with the same NFS filesystem.

What seems to be happening is this:

1. Drupal creates a file
2. NFS starts to sync file creation operation to the NFS server
3. Some other process was seeing the file and removed it
4. Drupal tries to touch the file, but NFS get confused
5. Drupal issues error/warning of touch()

Note: there is another problem also involved: the file sometimes has a random mtime, usually far in the past.

I've got the similar warnings when I've tried to mount 'drupal' folder on the host via nfs+bindfs plugin into guest machine managed by Vagrant+Virtualbox. Mount configuration is:

config.vm.synced_folder "drupal", "/vagrant-nfs", type: "nfs", nfs_udp: false
config.bindfs.bind_folder "/vagrant-nfs", "/var/www/drupal",
      u: 'vagrant',
      g: 'vagrant',
      perms: 'u=rwX:g=rwD',
      o: 'nonempty'
  config.nfs.map_uid = Process.uid
  config.nfs.map_gid = Process.gid

Vagrant and www-data are members of both groups 'vagrant' and 'www-data'.

On the other hand, there is no warnings when using native vboxsf with same user:group:

config.vm.synced_folder "drupal", "/var/www/drupal", owner: "vagrant", group: "vagrant"

No errors observed on production server with totally same configuration: Drupal 9.5.8, Ubuntu 22.04.2,
PHP 8.1.18, Apache 2.4.52 with another 'sysadmin:sysadmin' user and no mount directories.

This error can be fixed by deleting the public://php/ folder and clearing the site cache with drush cr. The site will recreate the folder with www-data as the owner and drwxrwxrwx (777) permissions.

Alternatively, if you copy the folder on deploy, you can set permissions with something like this after:

# public://php/
sudo find /var/www/html/web/sites/default/files/php/ -type d -exec chown www-data:www-data {} \; -exec chmod 777 {} \;
sudo find /var/www/html/web/sites/default/files/php/ -type f -exec chown www-data:www-data {} \; -exec chmod 777 {} \;

Not necessarily: it will recreate with the user running drush as owner. And in many cases this means a user that is not www-data (or is equivalent on other distros) but which has www-data as its primary group. That's a situation I encounter quite frequently when doing audits.