Your :// stream is not configured.

I have the same problem, and in the "Saved Backups" tab, the previous backups is not visible anymore.
Drupal version 8.5.1

Can confirm same issue.

I confirm the error.
Has anyone found a solution to the problem?

This may pertain the the same issue. When I execute a manual backup, the Recent Log message shows this:

Warning: file_exists(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? in BackupMigrate\Core\Destination\DirectoryDestination->checkDirectory()

Is there is a private file system issue in D8, or not working yet. This is on 8.5.0, and using the latest Backup and Migrate 8.x-4.0.

Setting up the "file_private_path" property in settings.php and rebuilding cache afterwards help for me.

@8georg.pitterle I have configured file_private_path in settings.php, this is not a solution for me.

file_private_path was configured in settings.php for me as well. I did try rebuilding cache, and still not working.

What private path are you setting in settings.php? Thanks

My private path is

$settings['file_private_path'] = 'sites/default/files/private';

and is secured by nginx as internal.

I had the same problem for last last days. Intially after installing the backup_and_migrate module, everything worked, from creating backups to viewing "saved backups" (mypage.domain/admin/config/development/backup_migrate/backups).

After changing the path file_private_path in settings.phpand in the data system (mypage.domain/admin/config/media/file-system) i still was able to run backups and save them, but couldn't see them in "saved backups". Instead i got displaed the warning: "Your :// stream is not configured."

Thanks to your last hint georg.pitterle i received the "enlightment":

As you define the private path in the settings.php, it's enough to use that path in shortform in the backup destination settings : private://

So lets say you have the backup directory (relatively to the drupal root):
1) simply: private/backup

• your private path is: $settings['file_private_path'] = 'private/';
• your backup destination is: private://backup

2) different name: my_secred_files/drupal_files/backup_and_migrate

• your private path is: $settings['file_private_path'] = 'my_secred_files/drupal_files/';
• your backup destination is: private://backup_and_migrate

3) outside of drupal directory : ../private/backup

• your private path is: $settings['file_private_path'] = '../private/';
• your backup destination is: private://backup

For me it works perfectly and i'm glad to had your hint man :) ... now my drupal is out of warnings again! yiha!

in my settings.php:

$settings['file_private_path'] = '/var/www/cms/private';

my drupal root directory is: "/var/www/cms"

my backup destination directory path:

private://backup_migrate/

after cache rebuild still got the warning "Your :// stream is not configured."

hey Ivbeck:

your private path $settings['file_private_path'] = '/var/www/cms/private'; looks good so far. i guess your private folder is in drupal root (cms?). so you can also apply that way: $settings['file_private_path'] = 'private';.

1. have you created a directory "backup_migarte" in /var/www/cms/private/? No? You'd better do so!
2. if 1) is true: have you tried to create backups with the module "backup & migrate" and you can find the new backups in the backup_migrate folder?

Hi @indigo-erich,

You seem very knowledgeable on this topic, and as I am planning to use Backup & Restore in production (I am currently using a cron-based bash script that copies Drupal's files without D8 knowing it), I thought I ask you for your assessment on my current plan:

Current situation:

1. I use a Composer-based setup right from start
2. This means that I have a <root>/web subfolder which serves Drupal
3. The (sub-)domain is configured to point to the <root>/web subdirectory
4. I keep my configuration exports and imports in <root>/config/sync, i.e. out of scope of being served.

My plan:

1. Configure Drupal's private file system as a sibling to config and web, i.e. at <root>/private using settings.php
2. Within private/, I want to store a host of things, e.g. submissions originated from the Webform module
3. Naturally, backup&restore should then reside in <root>/private/backup_restore
4. Rather setting the absolute path, I'd planned to set private to "../private", the same way I have set config: $settings['file_private_path'] = '../private';
5. Create the subdirectory ../private/backup_restore manually
6. Configure Backup & Restore to the destination private://backup_and_migrate

... And all should be well. Or not? :-)

Cheers,
Michel

Hi @indigo-erich,

First， I do have /var/www/cms/private/backup_migrate directory， it works perfectly before updating to Drupal 8.5.x.

Secondly, it won‘t work if I change $settings['file_private_path'] from '/var/www/cms/private' to 'private', drupal will report error "the file_private_path does not exist". because the public drupal root is '/var/www/cms/web’, I guess.

Anyway, thanks for you help.

I manually copy all files from '/var/www/cms/private' to '/var/www/cms/web/sites/default/files/private' and change $settings['file_private_path'] from '/var/www/cms/private' to 'sites/default/files/private', run drush cr, try again, but the warning is still there.

I think it’s really a bug.

Hi lvbeck,

If I understand you correctly, you have a setup similar to mine, i.e. a common parent directory for Drupal ("web/") and your private files ("private/")?

In that case, you need to set your private file directory to $settings['file_private_path'] = '../private';, because Drupal either expects an absolute path, or a path relative to the Drupal home directory (in your case "web/").

HTH,
Michel

Hi @mdrescher,

you are right, I have common parent directory for Drupal public files ("web/") and private files ("private/").

as you suggested, I just changed $settings['file_private_path'] from absolute path '/var/www/cms/private' to relative path '../private', the warning is still there.

Have you flushed all caches? Otherwise Drupal doesn't pick up the changed path!

Check /admin/config/media/file-system for the private file system setting. If it still says "private" and not "../private" (see attached screenshot; I use "private_files" instead of "private") then you need to flush the cache before any other analysis.

Next, check that the directory contains a .htaccess file with 444 permission and the following contents:

# Deny all requests from Apache 2.4+.
<IfModule mod_authz_core.c>
  Require all denied
</IfModule>

# Deny all requests from Apache 2.0-2.2.
<IfModule !mod_authz_core.c>
  Deny from all
</IfModule>
# Turn off all options we don't need.
Options -Indexes -ExecCGI -Includes -MultiViews

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

I am not sure whether Drupal is realising that the directory is by system config out of reach (because it residing next to Drupal root), and rather checks for the presence (and content?) of the .htaccess file instead.

The private file directory needs to have read, write and execute (i.e. change into) permissions for the web server process; I have it configured as rws, i.e. with the execute permission being sticky.

And or course, the "backup_migrate" subdirectory should also exist. :-)

HTH,
Michel

Hi @mdrescher,

I do clear all cache after changing $settings['file_private_path'],

in /admin/config/media/file-system, the private file system path is： "../private"，

and，I do have the .htaccess file inside with 0444 file permission, the content is exactly the same as yours.

the private directory also has read, write and execute for web server, which is 0755 permission in my case for www-data (my nginx user)

in admin/reports/status get no error for the private file directory file permission,

but in admin/config/development/backup_migrate/backups get warning "Your :// stream is not configured."

the the backup_migrate folder exists and all my old backups are there.

Hi @lvbeck,

I've been going through this thread again, and checked changes in recent Drupal releases that might have an affect on this.

The only thing I found that might be the cause is you upgrading to Drupal 8.5.x with an existing BAM 8.x-4.0 installation.

I conjecture that something has gone wrong in that upgrade process; the only thing I would suggest (and do if I were in your place) is the following:
- Export BAM configuration (drush cex ...)
- Uninstall BAM (drush pmu backup_migrate)
- Rebuild cache (drush cr)
- Check Drupal's private file settings
- Reinstall BAM (drush en backup_migrate)
- Update DB just in case (drush updatedb)
- Rebuild cache (drush cr)
- Check whether the error persists

Obviously, I'd do that on a test instance.

Then, as an added bonus, you could add the saved configuration and see whether that has any effect.

Besides, you should update to Drupal 8.5.3, it's two medium to critical security patches ahead of you! ;-)

HTH,
Michel

Thank you @mdrescher,

I figure that out finally,

I uninstalled BAM and reinstalled as you suggested, so I got a brand new unconfigured BAM, then I made some tests below:

1. I decided to move my private directory from '/var/www/cms/private' to '/var/www/private', which is outside Drupal root directory. This is suggested way in D8 documentation.

2.add a custom backup destination in admin/config/development/backup_migrate/settings/destination, in my case:

Destination Label: My Database Backup Directory
Directory Path: private://backup/cms/database/

Important！in the Directory Path field you can ONLY use relative path within 'private://what-ever-your-sub-dir'

If you use absolute path like '/var/www/private/backup/cms/database' , you will see the warning 'Your :// stream is not configured.' again! This is the exactly reason I got the warning before re-installation.

Hi @lvbeck

I think you got it!

The important bit here is that the path after "private://" in the BAM configuration is ALWAYS interpreted relative (i.e. as a sub directory path) within the path for Drupal's private directory!

So, if Drupal's private dir is configured to be /a/b/c and BAM's backup destination is private://d/e/f then the resultant absolute backup directory /a/b/c/d/e/f must exist!

And if you configure D8 private files directory relative, e.g. ../private then the resultant absolute path to your backup location depends on Drupal 8's home directory! If that is /var/www/cms/web, then the resultant absolute path to your backup dir will be /var/www/cms/private/d/e/f!

I think this warrants an update of the module's documentation to make that abundantly clear!

The key for me was the very non-intuitive need to flush the cache after changing the settings on $settings['file_private_path']

Do I understand correctly that we are needing an update to the module documentation rather than a patch in this situation?

I was having the same problem. It would be nice if clear instructions on how to setup the module were on the project page or documentation.

Thanks @tepelena we will mark this as a documentation task, then.

Comment #13 works for me. Thanks indigo-erich!

Using Backup and Migrate 8.x-4.0 in Drupal 8.6.3 in Lando on Ubuntu.

My docroot is at /web. I have put my /private directory at the same level as /web and created a subdirectory within it called backup_migrate.

My settings.php file contains $settings['file_private_path'] = '../private'; and my /admin/config/media/file-system page reports the "Private file system path" as ../private.

My private files directory path in BAM is configured as private://backup_migrate/.

Backups to the private files directory are working correctly and being saved in /private/backup_migrate/.

However I am still getting the "Your :// stream is not configured." warning at /admin/config/development/backup_migrate/backups. I have flushed caches through the UI, done drush cr, restarted Lando.

Anything else to try?

#13 resolves the "Your :// stream is not configured" for me too.

In the settings.php file, I set my Private file path to:

• $settings['file_private_path'] = 'sites/default/files/private';

In the Backup_Migrate settings for the manual destination (admin/config/development/backup_migrate/settings/destination/edit/manual_backup), I set the directory path to:

• private://backup_migrate/manual_backups

precision: it seem needed to set the path in the settings.php file instead of settings.local.php.

If it's helpful to anyone, I was getting this issue. My private-files directory is outside of Drupal root. What I had noticed is that the backups were being put in cms/private:/backup_migrate which is funny (it created a directory named "private:". The directory set in settings.php is simply ../private-files. I cleared the cache a few times and it worked.

In short:
settings.php = "../private-files"
backup_migrate settings = "private://backup_migrate"

I hope this helps. Drupal 8.6.

Just to be clear, you can put the $settings changes in either settings.php or settings.local.php, presuming that the settings.php file is changed to allow loading the settings.local.php file.

@ #34
I use settings-local to change sync folder location for example, but I was unable to set private folder location in it..only in settings.php. It's weird.

All this works as long as using the defined 'private' folder. But what about using an other folder at the server sites root?

Having 'myserver/mysite1/web' and 'myserver/mysite1/private' structure, I would like to also have 'myserver/backup' where I can save all my backups ('myserver/backup/mysite1', ...).

But as soon as I setup a Server Backup directory path as '../../backup/mysite1' in /admin/config/development/backup_migrate/settings/destination/edit/backup, I'm getting again the 'Your :// stream is not configured.' warning.

Just to summarize this long thread, since the solution disappeared in the flood of answers..
Solution: If the error occurs after changing the Private directory path then usually clearing the cache resolves the issue.
(Administration->Configuration ->Performance ->Clear all Caches)
Regards, Axel

B&M stop working as it can't use tmp folder as it did.In the watchdog I get this any time I try to do a manual backup of the DB to the private folder.
Le fichier 'temporary://bamFDOiWM' n'a pas pu être copié car le répertoire de destination n'est pas correctement configuré. Cela peut être dû à un problème de permission du fichier ou du répertoire.

The tmp folder is sites/default/files/tmp and permissions are 775.

@aiphes: Please check your File System config page to make sure everything is working correctly - remember to click the save button so that Drupal can run its permission checks on the paths.

Done and still the error:
Le fichier 'temporary://bamCuIv1m' n'a pas pu être copié car le répertoire de destination n'est pas correctement configuré. Cela peut être dû à un problème de permission du fichier ou du répertoire.

I don't undertsand why it happen.

@aiphes: does the error show on the file system settings page or the B&M page?

it's a watchdog message.
EDIT: trying on another D8 fresh install, same config for paths, and backup work. I don't understand why the first one stop working.

I have same issue. Everything worked, B&M was able to save backups to private file system and show them here:
admin/config/development/backup_migrate/backups

But when changing the B&M destination (admin/config/development/backup_migrate/settings/destination)
to some other folder than the default, it still can save the backup to that new folder, but can't show it here: admin/config/development/backup_migrate/backups.
That pages gives error "Your :// stream is not configured." even after cron or cache clear.

Still have this error on tmp folder (D8.7.7):
different file system setting tried like:

  ~/tmp
~/admin/tmp
sites/d8dev-ce/tmp

In addition I think a Core issue because this works for D8.5, and not after upgrade to 8.6 or 8.7.

And the error after trying to backup to the private folder...
I don't know what I can do more..

Comment #13 works for me. Thanks indigo-erich!

I have this working with my private directory as ../private and backups saved in ../private/backup_migrate, using the default BAM destination.

I was unable to configure a destination outside of ../private IE ../backup or else I get this error. The backups will export to the configured directory, but they won't be shown in the UI.

We would like the Backup and Migrate to manage backup OUT of our public space.
The backup works, but there is no deletion after 24 hours or 30 days. They PILE UP
Also nothing shows up in Saved backup.

We want to keep private files where they are. it's just the backups that we want somewhere else.
Thanks!

I have the following structure
- private
-- backup_migrate
- web
-- drupal 8 files

after having no success with
$settings['file_private_path'] = '../private';
$settings['file_private_path'] = $app_root . '/../private';
$settings['file_private_path'] = absolute path in my local mashine;

i succeeded in the end:
in my settings.php I have
$settings['file_private_path'] = './../private';

Ok, but this might lead to problems. permission or environment.

Really we should be able to put full paths from root.

Moving 8.x-4.x issues to 5.0.x because the older branch is no longer supported.

I found backups were being saved in my temp dir, $settings["file_temp_path"] , instead of the destination I configured with BAM. I used a full absolute path. Also the backups had no file extension, started with bam, then followed by 6 random alphanumeric chars.

Then I removed the trailing slash, and the backups started appearing in the correct directory! Also they had the correct filename format, as specified with BAM.

Removing the trailing slash seems to be one part of the fix; the slash could be stripped by the module code.

A remaining problem is the backups do pile up; the maximum number is not respected.

I was using 8.x-4.2. Then I updated to 5.0.1, updated the DB, cleared cache, but this made no difference regarding the number of backups to keep - the backups pile up.

Also, I still see

Your :// stream is not configured.

on the admin page listing backups, admin/config/development/backup_migrate/backups

Also, there are no backups listed there, though I can see the backups in the destination directory by the Linux command line on the server directly.

Hi! I was face this problem too a feel weeks ago.
I configurated my settings.php file, following the steps in this link and giving the directory the right permissions. So I put in backup-migrate destination the directory configurated and it worked.

@DamienMcKenna
It was moved to 5.0.x to forget it... ok, but is it fixed in 9.x!? Because this IS an issue. And maybe the fix is applicable to 8.x and helps us out! ;)
Thx

@MastaP: It was moved to the 5.0.x issue queue because we're not supporting the 8.x-4.x versions anymore, and you can run the 5.0.x versions on Drupal 8.

I had something similar. (Running stable version 5.0.1).

I had configured in settings.php:

$settings['file_private_path'] = '/var/private';

I am unable to save a backup to the private file system. (So this is related to: #2953132: private directory setting not working, code creates own.) I get the following error:

The backup file could not be saved to 'private://backup_migrate/' because the directory could not be created or cannot be written to. Please make sure your private files directory is writable by the web server.

The directory /var/private/backup_migrate/ exists and writable by the web server.

When I visited the "Saved backups" tab it said:

Your private:// stream is not configured.

Note that it is slightly different than "Your :// stream is not configured."

The list of saved backups was also empty (it should not have been).

I have a companion site running Backup and Migrate version 8.x-4.2 that backs up to the same private path. It works fine.

I then did two things:

1. Visited Manage » Configuration » File system and, without changing anything, pressed "Save configuration".
2. Rebuilt all caches.

When I revisited the "Saved backups" tab, the error message was gone, and I got the expected list of saved backups.

I then then proceeded to save a backup to the private file system. It worked.

I cannot be sure that resaving the file system settings and rebuilding cache is what fixed it for me (I tried a lot of different things), but it is worth a try.

Follow-up to my previous comment (#56).

I am unable to reproduce this 😢.

I just went through the following steps:

1. Set up an empty database for project.
2. Clean Install of Drupal ver 9.2.2 (using composer create-project drupal/recommended-project html)
3. Edited settings.php: $settings['file_private_path'] = '/var/private';
4. Installed Backup and Migrate: composer require 'drupal/backup_migrate:^5.0'
5. Did not visit Manage » Configuration » File system
6. Visited he "Saved backups" tab. No error message – and everything worked fine.

My hypothesis was that this procedure would reproduce the bug on a clean install. That did not happen.

This is an elusive one. My gut feeling is that until we're able to understand what's going on (i.e. reproduce the condition that triggers the bug from a clean install), we shall not be able document how to set up up the module to always avoid it, or otherwise fix it.

I'm changing the Category back from a documentation Task, to a Bug report.

Heeey, to make Backup and Migrate be able to save files you need to do 4 easy steps:

1) put in "

Directory Path

" field by path

http://exemple.com/admin/config/development/backup_migrate/settings/dest...

this:
private://backup_migrate/

2) In [ROOT OF SITE]/sites/default/settings.php
need update

$settings['file_private_path']

to:

$settings['file_private_path'] = 'sites/exemple.com/files/private';

2.1) And if you dont make it yet need to put in [ROOT OF SITE]/sites/sites.php below:

$sites['exemple.com'] = 'exemple.com';

3) create all folders to destination path:
[ROOT OF SITE]/sites/exemple.com/files/private/backup_migrate/

4) check if they all have chmodes 755 by run from inside of each of them (including dot):

stat -c %a .

if no run for them:

chmod 755 .

cheers;)

Ievgen Iefimenko,
welcome to Drupal.org and thank you for engaging with the community.

Unfortunately, this issue is not about how to set up Backup and Migrate to save to private files on the server. That is already well described in the project's documentation.

Instead, it is about an elusive error, where one is not able to see saved backups, or to save a backup, despite having correctly set up the module. This error is elusive because it does not always happen. I've set up the module for dozens of Drupal 9 websites, and I think I know pretty well how to set it up, and it has only bitten me twice. So far, I've not been able to figure out how to reproduce it.

Further, the recipe for setting up you offer is unfortunately not correct, and will compromise backup security for anyone that follows it.

For instance, if you look at the first step in the project's documentation, it says:

Create a directory, writable by the server, but outside the Drupal installation and not accessible over the web.

You suggest using this path for this directory: 'sites/exemple.com/files/private'.

The 'sites' subdirectory is within the Drupal installation, and very much exploitable over the web. In other words: What you suggest is something that will make backups insecure.

There are other problems with what you suggest, but there is no need to elaborate. Please use the recipe in the project's documentation for setting up this module to back up to a private path on the server. That is the correct way to do it.

This should be the correct configuration and works for us

Public file system path
sites/default/files
A local file system path where public files will be stored. This directory must exist and be writable by Drupal. This directory must be relative to the Drupal installation directory and be accessible over the web. This must be changed in settings.php

Public file base URL
http://localhost/web/sites/default/files
The base URL that will be used for public file URLs. This can be changed in settings.php

Private file system path
../private
An existing local file system path for storing private files. It should be writable by Drupal and not accessible over the web. This must be changed in settings.php

---

1. For example, I want to use sites/default/files as a BAM Source. So I created a source and used sites/default/files as the Directory Path. I named this new source SDFiles S

2. Create the destination directory in private directory, example sdfiles

3. Then configure a BAM Destination and use, example private://sdfiles *This is the original issue topic. I named this new source SDFiles D

4. Add a new Profile, so that you can customize the filename and gzip. I named this new profile Sites Default Files Backup

5. Attempt a manual backup using the new source, destination and profile. The backup and info files should now be in the sdfiles directory and they will be listed in the Saved Backups tab at /admin/config/development/backup_migrate/backups

6. Then create a schedule

FYI,

I found that backups were created and located where they were supposed to be on the server - but were NOT showing in the BAM saved backups display.

They now display there, after replacing the destination path setting. Previously it contained the full absolute path, something like /var/www/...

The first part of the absolute path, starting with /var/www/... (the part that is identical to the private files path), was replaced with private:// and now the backups show under Saved Backups.

FYI, this was with
Drupal Version
8.9.20

and

backup_migrate
5.0.1

Vote for #33 :)

It was as simple as that.

Got bitten again today after setting up a new site.
Drupal 9.3.6.
Backup and Migrate 5.0.1.

$settings['file_private_path'] = '/var/private';

Followed my own advice from #56:

1. Visited Manage » Configuration » File system and, without changing anything, pressed "Save configuration".
2. Rebuilt all caches.

That fixed it.

Next time it happens I'll skip the first step and just rebuild the cache.

Got bitten again today after setting up a new site.
Drupal 9.5.0.
Backup and Migrate 5.0.3.
PHP 8.1.7

$settings['file_private_path'] = '/var/private';

Followed my own advice from #56 and #63:

1. Visited Manage » Configuration » File system and, without changing anything, pressed "Save configuration".
2. Rebuilt all caches.

That fixed it.

I don't know if the first step is required, out of habit I used the same procedure as the last time.

Drupal Version 10.0.9
Backup and Migrate Version: 5.0.3
PHP Version 8.0.28

I Could not save backups to private destination.

To solve:
1. Once I was sure that Private Files folder was setup correctly in settings.php as per #56 & #66
2. Error still apparent
3. Uninstalled Backup_Migrate
4. Re-install Backup_Migrate
Saving backup to Private files destination worked first time!

#67 worked for me. Thank you @web226

#67 worked for me too.