File permissions

Hi,

I have same problem in drupal 7.

Thank You,
Rahul Barge

Are you guys still having problems?

Yep — B&M seems to be getting its private file settings from an entirely different place. Changing it directly in the Manual Backups Directory destination didn't even help.

Do you mean you reinstalled?

These commands is what resolved this issue for us. Just had to recreate the private directory that we set in the File System config settings.

[ftpuser@domain public_html]# rm -rf sites/default/files/private/
[ftpuser@domain public_html]# mkdir sites/default/files/private
[ftpuser@domain public_html]# drush bb
Default Database backed up successfully

Does this module respect windows folder permissions? And what path format is valid for windows? The network drive that I'm trying to save to is mounted locally on the webserver and is visible under the service account user. (it's an intranet site) And I've given explicit permissions for read/write to the webserver machine on the destination folder. The service account profile on the webserver also has explicit read/write on the destination folder. I've tried both a UNC path and a "regular" windows path declaration to reference the destination folder. Whenever I try to run the back up I get "Unable to create or write to the save directory 'X:\foofolder1\foofolder2'. Please check the file permissions that directory and try again." (This occurs whether I use UNC or the above path format) Who/what* else needs to be given permission? (*account/machine/service)

Something to watch for - if you give a destination path that includes a symlink it may give a failure notice, even though it does save the backup file.

Is this still an issue with 7.x-3.2?

Closing after more than two weeks with no activity. @DamienMcKenna, I am going through the 7.x issues I marked as postponed needs more info and closing the ones that seem outdated with no activity since almost three weeks ago. I hope I'm not marking some true bugs as closed, but I think for the most part a lot of these issues are very old and have been resolved with newer versions of the software. Hopefully users will come back at some point in the future and re-report any problems. Also, I think as we move more toward Drupal 8, the 7.x branch is going to be completely outdated in time, so as long as it works for most users right now we should be on target.

I think we should add some notes to the documentation about things to look for, e.g the symlink problem I mentioned above.