v.27: Could not run backup because the file could not be saved to the destination.

The latest version fixes an issue with the security check. Can you tell me what web server you are using? Is it apache? Is there a possibility that your private files directory isn't protected from web access?

Hmm... not sure what's happening here. Are there any other messages or log entries other than the one saying that it could not be saved?

I have the same problem with a difference I can see in my messages a wrong path (it is saying 'ites/...' instead of 'sites/...') [don't know why] while in admin setting every path has been set to 'sites/...'. So far all has worked with this settings very well.

Same thing for me too after I upgraded from previous version.

Warning: file_put_contents(../sites/default/files/private/backup_migrate/manual_V2/.htaccess) [function.file-put-contents]: failed to open stream: No such file or directory in file_create_htaccess() (line 498 of ../includes/file.inc).
Warning: fopen(../sites/default/files/private/backup_migrate/manual_V2/test.txt) [function.fopen]: failed to open stream: No such file or directory in backup_migrate_destination_files->check_web_dir() (line 210 of ../sites/all/modules/backup_migrate/includes/destinations.file.inc).
Security notice: Backup and Migrate was unable to write a test text file to the destination directory ../sites/default/files/private/backup_migrate/manual_V2, and is therefore unable to check the security of the backup destination. Backups to the server will be disabled until the destination becomes writable and secure.
Could not run backup because the file could not be saved to the destination.

Using Apache web server and .HTACCESS has
"SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Deny from all
Options None
Options +FollowSymLinks"

inside. Backup and migrate made it.

I made a new directory "manual_V2" and it does not have the htaccess file in it. seems like it could only create the folder structure but not place anything inside.

in the mean time i have downgraded to backup_migrate-7.x-2.5.tar.gz to get things running again.

Found it !

I have a site hosted in a subdirectory of the http root, named drupal-7.22;
There is a symbolic link to this, named sitedir, so my site is accessed by :
http://example.com/sitedir

In destination.file.inc, line #194 :

  function check_web_dir($directory) {
    // If the directory is specified with an absolute path, strip the site root.
    $directory = substr(drupal_realpath($directory), strlen(drupal_realpath($_SERVER['DOCUMENT_ROOT']) . base_path()));

let's see how does that translate :

$directory = 'private://backup_migrate/manual';

$root = drupal_realpath($_SERVER['DOCUMENT_ROOT']) . base_path();
==>  /home/www/sitedir/

$realpath = drupal_realpath($directory);
==>  /home/www/drupal-7.22/sites/default/files/privates/backup_migrate/manual

$directory = substr(drupal_realpath($directory), strlen(drupal_realpath($_SERVER['DOCUMENT_ROOT']) . base_path()));

==>  .22/sites/default/files/privates/backup_migrate/manual

I'm not a drupal specialist, but an another API should be used for $_SERVER['DOCUMENT_ROOT'] ...

Please just replace in destination.file.inc, line #196 :

  function check_web_dir($directory) {
    // If the directory is specified with an absolute path, strip the site root.
  //$directory = substr(drupal_realpath($directory), strlen(drupal_realpath($_SERVER['DOCUMENT_ROOT']) . base_path()));
    $directory = substr(drupal_realpath($directory), strlen(DRUPAL_ROOT . '/'));

it works, will have a safer week-end...

@gifad: Thanks for the code! I'll try and run this through all the possible scenarios and see if it hold up.

I've committed gifad's fix. Thanks all.

Is this an issue for D6 too? I am running a multi-site instance of 6.28. Backup and Migrate module is in the sites/all/modules directory, 1 default site and 3 named sites currently use it. Each of them saves to their own files/backup_migrate/scheduled directory. After the upgrade to 6.x-2.7, I have been getting emails from my server:

Security warning: Couldn't modify .htaccess file. Please create a .htaccess file in your rate/scheduled directory which contains the following lines: order allow,deny
deny from all
or add them to the existing .htaccess file
Could not run backup because the file could not be saved to the destination.

A different site listed a different directory:
Security warning: Couldn't modify .htaccess file. Please create a .htaccess file in your es/backup_migrate/scheduled

I don't know what those directories are, but I have verified that in each of the "scheduled" directories for each site there is an .htaccess file properly formatted.

Please let me know if the fix in #8 is the correct one to use for my version and situation.

I went ahead and tried the fix, but it does not appear to make any difference; I've had two more of the same errors since making the change. Any other suggestions?

I can make a manual backup with the ui but not with drush
I checked the rights with a site that does work and the are the same.

There is a .htaccess with:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Deny from all
Options None
Options +FollowSymLinks

And here are the errors I get

file_put_contents(home/id095/domains/14.testomgevingrotterdam.nl/public_html/sites/default/files/prive/backup_migrate/manual/.htaccess): failed to open stream: No such file or directory file.inc:498 [warning]
WD security: Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your home/id095/domains/14.testomgevingrotterdam.nl/public_html/sites/default/files/prive/backup_migrate/manual directory which contains the following lines: SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006 [error]
Deny from all
Options None
Options +FollowSymLinks
fopen(home/id095/domains/14.testomgevingrotterdam.nl/public_html/sites/default/files/prive/backup_migrate/manual/test.txt): failed to open stream: No such file or directory destinations.file.inc:210 [warning]
file_put_contents(home/id095/domains/14.testomgevingrotterdam.nl/public_html/sites/default/files/prive/backup_migrate/manual/.htaccess): failed to open stream: No such file or directory file.inc:498 [warning]
WD security: Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your home/id095/domains/14.testomgevingrotterdam.nl/public_html/sites/default/files/prive/backup_migrate/manual directory which contains the following lines: SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006 [error]
Deny from all
Options None
Options +FollowSymLinks
fopen(home/id095/domains/14.testomgevingrotterdam.nl/public_html/sites/default/files/prive/backup_migrate/manual/test.txt): failed to open stream: No such file or directory destinations.file.inc:210 [warning]
Could not run backup because the file could not be saved to the destination. [error]
WD backup_migrate: Could not run backup because the file could not be saved to the destination.

#7 #8 didnt helped ;[ problem is still the same...
I have drupal installation in (this is also set as source/private data to backup):
/web/s/site.ext/subdomain/www/
and backup dir is set to:
/web/s/site.ext/backup_migrate/manual
since new version of bm it is not backing up anymore... with the same error all the time... I tried changing path from absolute to relative, permissions are ok, backup dir is writtable...
Any idea? Thanks.

Security notice: Backup and Migrate was unable to write a test text file to the destination directory backup_migrate/manual, and is therefore unable to check the security of the backup destination. Backups to the server will be disabled until the destination becomes writable and secure.
Security notice: Backup and Migrate was unable to write a test text file to the destination directory backup_migrate/manual, and is therefore unable to check the security of the backup destination. Backups to the server will be disabled until the destination becomes writable and secure.
Could not run backup because the file could not be saved to the destination.

Drupal 7.22 installed in root. Encountered this problem after module update from 2.5 to 2.7. Unable to create test text file error message on screen and "Could not run backup because the file could not be saved to the destination" message in log.

The following 3 actions did not help.

1. Edit to line 196 as gifad #8 suggested.
2. Complete uninstall/install.
3. Removed backup_migrate folder in private files. When i tried to manually create a backup it created backup_migrate and manual folders then failed. The manual folder was empty. There were no .htaccess files in either folder.

Reinstalled 2.5 and my backups are working. Module 2.5 performed flawlessly until update 2.7.
Thanks for a great module.

Hi, I can see this is fixed for D7, but for D6 it still is a problem. None fixes worked, neither latest dev version.

6.x 2.7 still shows "Could not run backup because the file could not be saved to the destination."

I can provide more details, but not sure where to start.

Installing 6.x-2.x-dev fixed the problem for me.

Hi,
my case is a bit different:
i have drupal root in /home/mysite/www
and private file system in /home/mysite/www-private

backup to manual location failed - and the reason is that function dir_in_webroot in destinations.file.inc line 234 (version 7.x-2.7) doesn't count with trailing slash when deciding whether the directory is in drupal root and evaluates that /home/mysite/www-private is a subdir of /home/mysite/www

  function dir_in_webroot($directory) {
    if (strpos(drupal_realpath($directory), realpath($_SERVER['DOCUMENT_ROOT'])) !== FALSE) {
      return TRUE;
    }
    return FALSE;
  }

changint it to the below works for me:

function dir_in_webroot($directory) {
    if (strpos(drupal_realpath($directory), realpath($_SERVER['DOCUMENT_ROOT']). '/') !== FALSE) {
      return TRUE;
    }
    return FALSE;
  }

A simple workaround for my case is also just renaming the private files directory to someting else, e.g. private-files (and updating it in filesystem settings) so that it is not similar to Drupal root directory.

Hi,

I am using D6 with the following configuration of paths:

• Web root is /path/ ($_SERVER['DOCUMENT_ROOT'])
• Drupal installation into /path/cms/
• Redirection (/path/.htaccess) that translates accesses to /cms/ into / (avoids the /cms/ part in URLs)
• Base path is therefore www.example.com (and not www.example.com/cms/)

The problem I encountered is that the current working directory is /path/cms/ because Drupal is installed in this directory. Therefore, the check_web_dir() does not correctly locate the .htaccess file responsible for protecting the destination directory, as it bases its work on the document root. The following patch just makes sure that we are indeed in $_SERVER['DOCUMENT_ROOT'] prior to detecting/creating the .htaccess file.

--- a/includes/destinations.file.inc
+++ b/includes/destinations.file.inc
@@ -194,7 +194,10 @@ class backup_migrate_destination_files extends backup_migrate_destination {
 
     // If the destination directory is within the webroot, then secure it as best we can.
     if ($this->dir_in_webroot($directory)) {
-      $directory = $this->check_web_dir($directory);
+      $old_dir = getcwd();
+      chdir(realpath($_SERVER['DOCUMENT_ROOT']));
+      $directory = $this->check_web_dir($old_dir . '/' . $directory);
+      chdir($old_dir);
     }
 
     return $directory;

Any comment welcome.

Had the same problem - seems to be fixed in the latest dev of 2.x! Thanks!

Edit: Sorry, I haven't seen the Information that's already was fixed in 7.x version. I also talked about 7.x-2.x.

My mistake, 6.x-2.x-dev already fixes the problem.

#21 solved the problem in drupal 6.28 b&m 6.x-2.7
thx cirdd

Not sure why this was reopened. Also I don't think this was ever an issue in the D6 branch (totally different db engines).

Oops wrong ticket. Disregard my last comment

@clrdd Can you send me the htaccess rule you use at / to rewrite the paths to your drupal install? I'd like to be able to reproduce this setup for testing.

Thnks
R

Had the same problem as webcultist.
The 2.x dev fixed it

Using dev from 2013-06-18.

Still can't backup, thou different error message.

Private path is "../html-all-files"

Error message is now showing "file_put_contents(all-files/...) as though the "../html" part of the path is being stripped, and the full path not being allocated.

subscribe

I recently encountered the 'Couldn't modify .htaccess file' error message on sites running both 6.x-2.7 and 7.x-2.7. The problem turned out to be that the code for my sites was saved at locations like /opt/www.example.com/drupal, and the location I was using for backups (private files directory in the case of the 7.x sites) was like /opt/www.example.com/drupal_backups.

The dir_in_webroot function in destinations.file.inc was incorrectly deciding that the backup location was inside the webroot, because it was only checking whether the site-base location was a substring of the backup location. This meant that check_web_dir ended up being called, which stripped the base-path off and attempted to check for a .htaccess file in a completely incorrect location (namely the non-existent relative _backups/backup_migrate path).

This can be corrected by appending a trailing '/' to the locations being checked:

In 6.x-2.7, line 261 becomes:

if (strpos(realpath($directory) .'/', realpath('.') . '/') !== FALSE) {

In 7.x-2.7, line 235 becomes:

    if (strpos(drupal_realpath($directory) .'/', realpath($_SERVER['DOCUMENT_ROOT']) .'/') !== FALSE) {

This correction does not appear to have been made yet in the 6.x-2.x-dev, 6.x-3.x-dev or 7.x-2.x-dev versions.

This

Hi ronan,

Sorry for the delay.

Here is the setup I have the habit to use :

/.htaccess [1]
/cms/<drupal installation directory>
/cms/.htaccess [2] (drupal's htaccess)

[1] main .htaccess:

# .htaccess
# This is a Drupal website, stored in a separate directory for convenience
#

Options -Indexes
Options +FollowSymLinks
RewriteEngine On

# Directory protection
RewriteCond %{REQUEST_URI} ^/cms
RewriteCond %{HTTP_HOST} !^www\.example\.com\.?$ [NC]
RewriteRule .* - [L,F]

# this is the default domain
RewriteCond %{HTTP_HOST} !^www\.example\.com\.?$ [NC]
RewriteRule .* http://www.example.com/$0	[R=301,L]

RewriteCond %{REQUEST_URI} !^/cms
RewriteRule ^(.*)$ cms/$1 [L]

RewriteRule .* - [L]

[2] Drupal's .htaccess

(IIRC nothing modified from the original htaccess file that is shipped with Drupal):

#

# Apache/PHP/Drupal settings:
#

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$">
  Order allow,deny
</FilesMatch>

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Force simple error message for requests for non-existent favicon.ico.
<Files favicon.ico>
  # There is no end quote below, for compatibility with Apache 1.3.
  ErrorDocument 404 "The requested file favicon.ico was not found.
</Files>

# Set the default handler.
DirectoryIndex index.php

# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.

# PHP 4, Apache 1.
<IfModule mod_php4.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

# $Id$

#8 worked for me. Here is a patch for anyone using drush make.

Wrong file extension

#8 works for me too, would be good if this could be rolled into the next release.

#8 || #35 do not work for me. I still receive the same error Drupal 7.21, path to private files works in other modules, (location is outside of root). Just downloaded the latest release today, (7.x-2.7).

#8 works for me too.

#8 doesnt work for me (using 2.7). My backup folder is outside the drupal folder.

Could the maintainer of this module PLEASE roll back the "Recommended Version" of this module to the last working version? Around the world thousands of people are getting prompted to update their Backup and Migrate module to 2.7, a version that does not work.

subscribe

#8 When the folder is outside the drupal folder with not absolute path specified :

<?php
   // If the directory is specified with an absolute path, strip the site root.
  //$directory = substr(drupal_realpath($directory), strlen(drupal_realpath($_SERVER['DOCUMENT_ROOT']) . base_path()));
?>

# 8 worked for me; changed in line 220............ thanks again gifad .

This bug is major. Because when using drush, it's not possible to run backup.
I use a drush command to run cron. And backup_migrate fails to backup the database.

(However, backup_migrate works well in web based UI. I have this error only in drush)

#8 works fine.

Backup failed after I updated to the RECOMMENDED version 2.7.

Please don't recommend this if its not ready. I lost half a day researching and then reverting to 2.5, which works fine. There must be thousands of people doing the same thing.

I also run Drupal in a sub-directory and saw the same errors listed by people above.

But THANKS for a great module! What a time-saver it is for all of us.

Confirmed 2.5 works. 2.7 doesn't.

It looks like the fix in #8 was merged way back in comment #10 or so... but there hasn't been a release which includes that fix.

Concur with jcfiala on comment #47 under Drupal v7.22 and v7.23.

Clarification: Concuring the noted patch works, and there is not an release with said patch available.

If this has been committed then the right status is fixed.

I created an issue to track the next release #2060867: Roadmap for next stable release.

Folks interested in this bug could follow that and help test the issues referenced there to get a new stable.

@greggles - Pardon my confusion. Is it time consuming for the module maintainer to put out a new release? Although I cannot fix either of the two issues mentioned, maybe I can help somehow else. Although those two issues certainly need work, they do not prevent the module from doing its primary function of backing up the site.

I don't understand why not patch the current version of the module and release that as the RECOMMENDED version 2.8 ? If it will help the maintainer, I would be happy to patch the module, zip it and send it to them.

Three months is a fairly long time to have a broken module continue to be the recommended version while a fix is available.

Actually, unfortunately, we've got this committed to dev, BUT we also have people saying the fix doesn't work for them - see comments #35 and #37. #45 may also be having problems.

So - I think we still need more testing/feedback. @diggingrelic, @Goekmen and any others still having this problem with the latest dev - please post more info about your server and filesystem - let us know about filepaths, OS, webserver, etc. It would be really, really nice to knock this one out.

Actually there is ONE person on this thread that is having an issue with this patch. #37 @diggingrelic had an issue and may chime in. I would be happy to work with them to ensure the file was correctly patched. #35 was just to say the patch had the wrong name and reload it as .patch and not .txt.

#45 is complaining about the same issue I am frustrated with. His Drupal install told him there was a new version. Once it was "upgraded" the backups stopped working. As General Akbar says, "It's a trap!"

EDIT: Oh I see you are referring to #39. Maybe @Goekmen will chime in with where the backup file is located. I have my private directory above Drupal's root and it works fine. Is @Goekmen hosting private files on another server?

My backup directory is outside from the drupal root directory. I am getting the following errors:

Warning: fopen(backup/test.txt) [function.fopen]: failed to open stream: No such file or directory in backup_migrate_destination_files->check_web_dir() (Zeile 211 von ***/drupal/sites/all/modules/backup_migrate/includes/destinations.file.inc).

Could not run backup because the file could not be saved to the destination.

Before the update everything works fine. The directory exists and has the right permissions.

PHP Version 5.2.17
Apache/2.2.22
Using a shared hosting environment (if this is important)

EDIT: There is no private file system.

#52 @mcfilms - awesome General Akbar reference. Also - thanks for clarifying and fixing my comment numbers - #39 is correct. :)
@Goekmen - just to be absolutely positive - you're running the latest dev (7.x-2.x-dev), correct? You're NOT using 7.x-2.7, right?

Also Goekman can you visit the page at admin/config/media/file-system and confirm that all three directories exist on your server. I assume you have Public file system path set up. But I think B&M uses the tmp directory and (if I'm not mistaken) saves the backups in the private directory. So all three have to be valid and be writable.

Even though you aren't using Private Files, it is a security risk to store the database backups in a public directory. I believe the decision was made some time back that the database backups should be stored outside the root. I often simply use ../tmp or ../../tmp for private files. If any of these fields are blank I think we identified the problem. Also, if you migrated the site from a development platform, these directories (outside the root) may not have been created. Usually just saving this page will create the directories.

I am using 7.x-2.x-dev now and all 3 directories exists are valid and writable. I am not storing the database backups inside the drupal directory.
Before the update to 2.7 everything worked fine. Sorry I can´t help more :-(

I too am having this issue.
ronan what permissions should we set? what steps can we take to resolve this?
I have apache:apache set on sites/default/files/private/ recursively

Here is some insight to my machine:
Centos 6
apache as server
apache is running without .htaccess rules on by default. I have to specifically use the container to Include such files.
When i do include the .htaccess file from the backup_migrate directory I get locked out of my site with forbidden message.

On the other hand even without the .htaccess rule this url:
mysite.com/sites/default/files/private/backup_migrate/manual/ displays this in the browser:

Forbidden

You don't have permission to access /sites/default/files/private/backup_migrate/manual/ on this server.

Apache/2.2.15 (CentOS) Server at amfnd.ashercinder.com Port 80

Like it should.

Yet when i try to backup to the manual directory these are the messages that I get.
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/private/backup_migrate/manual' directory
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/private/backup_migrate/manual' directory
Could not run backup because the file could not be saved to the destination.

When i adjust permissions on private:
644 gives me this warning
-------
Unable to create or write to the save directory 'private://backup_migrate/manual'. Please check the file permissions that directory and try again.
Could not run backup because the file could not be saved to the destination.
776 gives me this warning
------
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/private/backup_migrate/manual' directory
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/private/backup_migrate/manual' directory
Could not run backup because the file could not be saved to the destination.

755 gives me this warning
-----
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/private/backup_migrate/manual' directory
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/private/backup_migrate/manual' directory
Could not run backup because the file could not be saved to the destination.
Thanks.

655 gives me this warning
Unable to create or write to the save directory 'private://backup_migrate/manual'. Please check the file permissions that directory and try again.
Could not run backup because the file could not be saved to the destination.

somewhat frustrating. :)

if there is anything i can do to help let me know.

It's been long time but I'm just confirming that it still doesn't working with either fixes described here or with latest dev.

I have private filesystem which is outside DRUPAL_ROOT. Before version 2.7 it worked perfectly. I'm experiencing this problem on over 10 websites.

I agree with other people that the borken code (dunno which part of it) should be re-rolled from version 2.5 so we can all have new version 2.8, or at least 2.7.1 :)

Right now thousands of people cant have all modules listed in green on their Available Updates page as they have to stick to 2.5.

@pawel.traczynski: I understand your concern, but I believe the previous version was broken just in a different way. This concerns the internal self-check that B&M does to ensure that it's not backing up to a publicly exposed directory. I don't want to roll back to a version where 10s of thousands of people are getting false negatives on that check, so I'm not planning on moving forward until I have a fix that works for everybody.

I have tested a lot of setups with the private directory outside of the Drupal root so that info alone isn't enough for me to reproduce. Where is the directory in relation to the root? Are you specifying the path relatively or absolutely? Is your web root or private dir symlinked? If I can reproduce your exact setup I can fix the issue for your use case.

Thanks

@baf139 if your web server is not set to read .htaccess files then you'll need to find another way to protect your private directory. You can copy the access rules from the .htaccess file to your php.ini, or put the private directory somewhere outside your webroot. The security notice is not related to your server file (chmod) permissions. The web server needs to be able to read and write to the directory but it should be set up to NOT serve those files to the public.

Ooh okay... so here is my fix... this is possible cause i have root access on my VPS, sorry shared hosters.

<Directory /var/www/html/*/sites/default/files/private>
    Deny from all
    Options None
    Options +FollowSymLinks
</Directory>

place that in your favorite conf file. for instance i have a conf file that is in /etc/httpd/conf.d/domains.conf.
the * is a wildcard in that any site i have in var/www/html will allow these rules to override my "AllowOveride none" setting for .htaccess rules.

What is the reccomended solution now, will it be best to roll back to 2.5
I am currently using 7.x-3.x-dev version and have the same issues.

I receive this in my logs.

Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your home/e-smith/files/ibays/proj3/html/sites/default/files/private/backup_migrate/scheduled directory which contains the following lines:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Deny from all
Options None
Options +FollowSymLinks

Then another:

Could not run backup because a there was no valid destination to save to.

Manual backups work through the ui,
I have created the reccomended .htaccess files within the directories.
My server is setup correctly.
I am right in changing this to critical as it seems that no current version works correctly?

Actually got it working in dev version no problem, just set the private files directory outside of my drupal root.
Changing priority.

2.7 does not work for me either
i know for my part that my hosting provider does not allow the SetHandler command in the .htaccess
Hope this is where the issue comes from

Suggestion in #63 helped me to get Backup&Migrate running without errors.
Thank you, antonyanimator!

My issue was caused by a typo:
There was an extra space at the head of the url string which only affected the Backup and Migrate module.

wrong
$base_url = ' http://www.emogic.com'; // NO trailing slash!

right
$base_url = 'http://www.emogic.com'; // NO trailing slash!

I'm seeing an lot of different but related issues in this ticket. It sounds like a lot of people have been able to fix their issues with proper apache configuration and others were able to fix this by moving their private files outside the docroot.

Because this issue has gotten unreadable, I'm going to close it.

If you are receiving the following error:

Security notice: ... will not save backup files to the server because the destination directory is publicly accessible

Please read the following issue and post in that issue if appropriate:

https://drupal.org/node/2123463

If you are receiving any other error, please look for an open ticket relating to that error and if none exists open a new one with the error you're receiving.

Thanks all,
Ronan

Regarding #4, #13 please see https://drupal.org/node/2144239