This update broke a previously functioning setup on a local host install. (Its working fine for me on another install, at a shared host.) The error is reported as a renaming permissions failure, but situation appears distinct from that reported in a previous bug report.

My backup locations option: /home/mwp/drupal/backups

Error Message:

* warning: rename(/tmp/drupal-backup-db-GrjRF9,drupal-backup-db-20070617152118-698587839.sql.gz) [function.rename]: Permission denied in /var/www/sites/all/modules/backup/functions.inc.php on line 82.
* backup_database(): Renaming file '/tmp/drupal-backup-db-GrjRF9' to 'drupal-backup-db-20070617152118-698587839.sql.gz' failed

After seeing a previous error report related to renaming permissions:
I adjusted the permissions to 775 for the home, mwp, and drupal directories (in my backup path) from 750 and 755 settings. I'm not sure why that might help, but in this case these changes didn't change the problem or error report. (The Permissions for \tmp and \home\mwp\drupal\backups were already set to 777 and remain there.)

The Capture Errors option - was initially off and was turned on only after my other adjustments failed and I wanted to get a good capture to report here (but it has not changed the error report).

The Backup from Root option - has never been used.

Comments

dmuth’s picture

dmuth commented
Assigned: Unassigned » dmuth

Hi, a couple of suggestions:

1) Could you try downloading the 5.x-4.0 release from http://drupal.org/node/151672? (I'd have it up on the main page, but there's some CVS craziness going on with the Drupal repository, it seems.) If that doesn't work...

2) Can you try setting the directories to 777 as well and see what happens? It is possible that the webserver is neither the owner nor in the group for the affected directories. (Setting stuff to 777 isn't a good practice, but it will help us rule some things out)

Thanks,

-- Doug

mwpeters’s picture

mwpeters commented

Thanks for quick reply, action...

Here goes log of my exploration:
Set all directories in chain of temp and backup destinations at 777....
Same Error, No Change

Substitute new DEV version code, update database, run CRON, run backup....
New Error message - warning:

Drupal installlation directory is not writable! This needs to be fixed so that a backup can be made. Please check permissions on the directory '/var/www'

My response:
Changed that directory from 755
- first to 775 ..........(no change),
- then to 777 .........(backup successful !)

Next action:
I changed all other directories where that I'd previously switched to 777 back to previous settings
................................(backup still good).

I'd still like to have some user write restrictions on the root web, Drupal install directory (not use 777).
I don't think that is a wise long term solution, so behavior or instructions need some help for a better option.

BTW....

Install is default Ubuntu 6.06LTS Server w/ minimum of whats needed for LAMP, SSH, and current patches...
This does seem to be a pretty security nuts install, but OTOH it really hasn't been a problem before.

dmuth’s picture

dmuth commented
Version: 5.x-3.0 » 5.x-4.x-dev
Status: Active » Closed (works as designed)

Well, at this point what we have here is a sysadmin issue on the box. Since I obviously do not have access to the box, I can only offer some general suggestions:

- It looks like the webserver is neither the owner nor is it in the group for the directory /var/www.

- Changing the group that the webserver runs it could fix this (check httpd.conf), but it may break other things.

- Changing the group of the directory /var/www could fix this, but may break other things.

BTW, good choice with Ubuntu. It's a awesome distro.

-- Doug

dmuth’s picture

dmuth commented

Well, at this point what we have here is a sysadmin issue on the box. Since I obviously do not have access to the box, I can only offer some general suggestions:

- It looks like the webserver is neither the owner nor is it in the group for the directory /var/www.

- Changing the group that the webserver runs it could fix this (check httpd.conf), but it may break other things.

- Changing the group of the directory /var/www could fix this, but may break other things.

BTW, good choice with Ubuntu. It's a awesome distro.

-- Doug