error unlinking orphaned temp files on shared hosting
| Project: | Backup and Migrate |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
I am just sharing an experience here for the benefit of others. My log was filling up with errors like this:
unlink(/tmp/backup_migrate_v7wgo5) [function.unlink]: Operation not permitted in /home/user/drupal/sites/all/modules/backup_migrate/backup_migrate.module on line 124.
It turns out that these are backup & migrate temp files belonging to another user on this shared hosting system. It did not immediately occur to me that other users files would be visible, but not writable, in /tmp. Backup & migrate attempts to delete any files meeting the filespec /tmp/backup_migrate_* and if these are not your files, it will throw an error.
The obvious solution is to change the drupal tmp directory in admin/settings/file-system to something private. However it would be nice if backup_migrate automatically created a unique subdirectory within /tmp for this purpose.
#1
We just experienced this issue on one of our development servers too. I'm gonna get a fix in here as soon as I can. I'll need to either:
1) Add some sort of site id to the temp files so that each site only attempts to delete it's own backups
2) Check permissions on temp files before deleting
3) All of the above.
As soon as I get a chance to put this solution together I'll commit it and write back in this issue.
Thanks for the heads up.
#2
Same issue here..
#3
Same. Subscribing
#4
I've backported the temp delete code from 2.x so that should fix the issues.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.
#6
Using 6.x-1.2, this error is coming up in my error logs now. Looks like the fix is to just change the temp directory used by the module to something else other than /tmp, but I thought I should post it so you know the temp delete code backport didn't apparently fix it by itself.
#7
I removed the module all together.
#8
Subscribing, since 2 days having this issue.