Warning: touch(): Utime failed

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.

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. Drupal tries to touch the file, but NFS thinks the file is not there (yet)
4. Drupal issues error/warning
5. NFS completes file creation operation (say in 1 sec), and the file is now seen on the NFS client system
6. Note: 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.

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.