How to setup permissions? RESOLVED!

If you don't want to allow write access to everyone (the last 7 in 777) then you need to make sure the folder is owned by the web server user. On many hosts the webserver runs as a different user than the one you ftp or ssh into your server as, so if the directory is owned by your ssh user then apache will not have access to write to it unless you chown it to the apache user or chmod it to 777.

Hope this helps

I have the same issue after upgrade.

I might be seeing the same thing. Apache owns the directory and has identical configs as my primary drupal server (still running Drupal 6.13 and b&m 6.x-1.2). I get the error that it's too open to the public, yet when I make it any more secure, it says it doesn't have access. In general my directory is set to 744, which is the same on my primary server...which works. This install however, (Drupal 6.15 and b&m 6.x-2.2) doesn't. What am I missing?

Same thing here I had to go back to the older version of the module. No matter what I do its either too secure or too insecure to use.

Maybe there is some conflict, ive not had time to test it again but the new features look very cool though!

On a variation of this issue, I get a file not found message in the dblog for the forbidden.html. It tracks back to the text.txt file in the schedules directory. After reading the contents of the file, which should have a line feed at the end, I understood the problem. I changed the permissions on the scheduled directory to 770. The problem is not the permissions issue, it is how I discovered the error message. In my option, the check should produce a more reasonable message than depending not find a file called forbidden.html.

I'm having the same permissions issue, I have folder permissions set to 700 on the "manual" directory yet it still says,

"Security notice: Backup and Migrate will not save backup files to the server because the destination directory is publicly accessible. If you want to save files to the server, please secure the 'sites/default/files/backup_migrate/manual' directory"

Not exactly sure how 700 is publicly accessible.

I don't believe this is a bug since most users of this module don't have this problem.

Hopefully this will clarify some of the issues here:

File Permissions:
The web user needs to be able to write to the backup and migrated directory. This means you should use the same file permission setup as your files directory. If you did not change the default location of the backup and migrate directory then you don't need to do anything at all since the module will simply create the backup directory inside your files directory and set the permission it needs. This works the same way as the attachment module, imagecache, css aggregation, etc. etc. so if all those are working so will B&M will too. If you want to move the backups directory somewhere else on the filesystem you'll have to make sure the directory is readable by the webserver, so don't do this unless you're comfortable with that level of server administration.

Access Via the Web:
Since the files directory is generally set up to allow anonymous users to read files remotely (via their web browser), B&M also writes a .htaccess file to the backup directory to disallow read access via apache. For extra security, the module also attempts to read a test file out of that directory via http and if it is able to it will refuse to save backups to the server. If this check succeeds it causes an access denied error in your apache logs. This is not ideal, but it is normal since the goal is to deny access to the directory. If the test fails you get the error message quoted in #10. That message means that the directory is writeable, but for some reason the .htacess file that protects that directory could not be created, or that it was created, but is being ignored by Apache. Or maybe you're not using Apache. Whatever the reason, you will need to take additional steps to make sure that directory is not readable via the web. Go to http://YOURSITE.com/sites/default/files/backup_migrate/manual/test.txt in your web browser. If you can read the file the directory is not secure. If you need to protect this directory and .htaccess is not doing the job, contact your Sysadmin or webhost about setting up some other kind of security.

I hope this clears up some of the confusion.

@billsdesk
The access check does not do anything with forbidden.html. My suspicion is that you're web server is set up to use a custom forbidden page but that that page does not exist so there's an additional file not found error while trying to load it. That's pretty common. You can usually change this setting in your Apache settings or through CPanel if your host is running that.

Sorry, but this still doesn't make sense to me.

I'm using apache. My files dir is owned by apache and everything is 750/640.

Apache needs to be able to read/write the files/backup_migrate dirs in order to work right?

But if it can, B&M claims the dir is too open.

Also, for the list_files and restore features to work, don't the dir and files have to be readable by apache?

Only something off of htdocs works, but that's no good because that piles all the multisite backups into one non-site-specific dir.

I'm with gbell12, only above the site root works for me. Surely that isn't right? It seemed to co-incide with permissions being reset for the folder, but then it's impossible to set them correctly after.

Apache needs to be able to read/write the files/backup_migrate dirs in order to work right?

Yup

But if it can, B&M claims the dir is too open.

Nope. B&M doesn't care if the file is readable by apache, it cares whether or not apache is serving the files publicly over http. B&M tries to protect the directory by adding a custom .htaccess, but it may not be able to write the .htaccess file, or apache may be ignoring it. If either of these is the case then you have a non-standard set up and you will have to secure the directory yourself before B&M will save files to it. If you can't do this then just use a directory that is outside your webroot.

I'm still not understanding why Ronan is insisting that the permissions are correct. I've been reading through these posts regarding this issue and I'd like to add my $.02 worth. In my case I am trying to migrate a production 5.18 install to a 6.20 and not having an easy go of it. I thought I would try the backup_migrate modules to export/import the database info. When I access the modules I see the following notice at the top of the page(s):

Security notice: Backup and Migrate will not save backup files to the server because the destination directory is publicly accessible. If you want to save files to the server, please secure the 'files/backup_migrate' directory

OK. As I write this here are what my directory permissions look like:
drwxr-xr-x 77 www-data www-data 65536 2011-01-28 17:10 files
drwx------ 4 www-data www-data 4096 2011-01-29 14:51 files/backup_migrate
drwx------ 2 www-data www-data 4096 2011-01-28 13:02 files/backup_migrate/manual
drwx------ 2 www-data www-data 4096 2011-01-29 14:51 files/backup_migrate/scheduled

As I understand this ONLY the owner has permission to do ANYTHING on those directories. and that ownder is the user that apache2 is running under. So PLEASE, tell me how these directories are accessible to the public? If its the read permission on the files directory then isn't that necessary for all other modules and users to upload files?

Please enlighten me and many other users/readers? All we wish is to have this tool function for us? Thanks

If apache is the owner, and apache has read access then it is able to server them to the public over http. If the directory is under your webroot then apache will indeed do so if requested. If the module is telling you that it can access the file remotely than it can. It wouldn't make a thing like that up. The module should have written a .htaccess file to the directory with a rule in it telling apache not to serve the file. If your apache is not set up to allow such instructions in htaccess files (http://httpd.apache.org/docs/1.3/mod/core.html#allowoverride) then the .htaccess will not work and you'll have to figure out some other way to protect that directory. This is what I explain in the section "Access Via the Web" in comment #11 above.

Perhaps more detail in the configuration of this module would help countless other newbies. But after reading and trying and reading and trying I finally got this to pass the security test and work.

The directory structure that is being used is {webroot}/files/backup_migrate and below. The default permissions of these directories was rwxr--r-- so with the following *nix command the permissions were changed and the module now works:

sudo chmod -R a-r {webroot}/files/backup_migrate

Again, I hope this post will help someone in the future. Thanks all for the comments.

@bobmct, Thanks for sharing your solution in advance. it solved the issue so that I could make scheduled backups but I can not see the list of backup files through the admin interface where you can get into with "admin/content/backup_migrate/destination/list/files/scheduled". Any solution on this?
Thanks.

guysung;

I am with you - I too cannot see my backups via the admin menus at all but using a command line I can see the backup files in the {webroot}/files/backup_migrate/manual/ directory.
What version are you using? We're still on 5.18 which I am trying to upgrade sufficiently enough to allow me to migrate to 6.20, a feat unto itself.

I'll keep looking and let you know if I find anything. You do the same please?

Thanks - Bob

No matter what I do its either too much or not enough secure. So best solution is still to revert to the old version of the module? Easy enough.

Solution #18 worked flawlessly also for Drupal 6. Thank you so much. I had migrated the whole drupal directory and something happened in terms of permissions.

Solution #18 worked flawlessly also for Drupal 6. Thank you so much. I had migrated the whole drupal directory and something happened in terms of permissions.

Note that in Drupal7 the error "The file cannot be written to." Is also triggered if the Temporary Directory is not set up correctly as set (and tested) on:
{siteurl}/#overlay=admin/config/media/file-system

This is not really a Backup_Migrate issue but it does trigger the Backup_Migrate error.

Had a hard time with this. With the help of ronan on #11, I stopped trying to change directory permission and realized it was the .htaccess file that was not being recognized.

I am still not sure why Apache isn't respecting the .htaccess file in the backup_migrate directory. Does anyone have advise on?

In order to get B&M working, I added this directive to my httpd.conf file

<Directory /var/www/sites/default/files/backup_migrate/>
  Order Allow, Deny
  Deny From All
</Directory>

I did read somewhere that using directives in the httpd.conf file is a best practice over using .htaccess files. Advice in regards to configuring apache to use .htaccess files is greatly appreciated (Or, why we shouldn't).

I was having a similiar problem in Drupal 7 with it saying either it could not write to the folder or it was publicly accessible. None of the above suggestions helped. I eventually fixed it by changing the destination folder path from private://backup_migrate/scheduled to sites/default/files/private/backup_migrate/scheduled. This may be something specific to my hosts 1&1.

#18 it works. set permission 300 is fine . only the admin download-button can download.