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.

Comments

ronan’s picture

ronan commented

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.

HS’s picture

HS commented
Category: support » bug

Same issue here..

fumbling’s picture

fumbling commented

Same. Subscribing

ronan’s picture

ronan commented
Status: Active » Fixed

I've backported the temp delete code from 2.x so that should fix the issues.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jrdixey’s picture

jrdixey commented
Status: Closed (fixed) » Active

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.

HS’s picture

HS commented

I removed the module all together.

Gerben Zaagsma’s picture

Gerben Zaagsma commented

Subscribing, since 2 days having this issue.

Durrok’s picture

Durrok commented

I ran into the same issue and was receiving error messages like this in my watchdog table:

User Anonymous
Message unlink(/tmp/backup_migrate_4ba269ff0c736.mysql) [function.unlink]: Operation not permitted in public_html/sites/all/modules/backup_migrate/backup_migrate.module on line 124.

Went and checked out my permissions and sure enough anonymous no longer had access to any part of the backup & migrate module. Provided the proper permissions and the module is working correctly.

HS’s picture

HS commented

Why would you allow anonymous access to the module anyway? Or did I just read the above all wrong?

Is this issue fixed in 6.x-2.2?

jmcintyre’s picture

jmcintyre commented

As far as I can tell, the proper place to set the destination for temporary files is /admin/settings/file-system. Backup_migrate retrieves the value via file_directory_temp() (it's not hard-coded into the module).

ronan’s picture

ronan commented

As far as I can tell, the proper place to set the destination for temporary files is /admin/settings/file-system. Backup_migrate retrieves the value via file_directory_temp() (it's not hard-coded into the module).

Yep, that's how it works. And if you're on a shared environment I highly recommend switching your temp directory to something inside your user folder. It shouldn't be in the web root but needs to be readable/writable by the web server (and not by other users). That way none of your files are being written to a directory that other people on the same server can access.

dgorton’s picture

dgorton commented
Status: Active » Closed (fixed)

Closed per #6, #11 and #12