Not able to create snapshot.

[drahnr]

# snapper -c root create-config /
Creating config failed (creating btrfs snapshot failed).

This was run as root, the rootvolume is a btrfs fs, whereas

# btrfs subvolume create /.snapshots 
Create subvolume '//.snapshots'

succeeded

[aschnell]

Please have a look at /var/log/snapper.log.

[moy]

I had the same issue and the problem was that .snapshot already existed. snapper create-config seems to insist in creating the subvolume and fails if it already exists.

My use-case: an external drive used for backups, that I plug on multiple machines. Obviously, running create-config on the second machine it found the .snapshot created by the first. A pity (or a bug?) that snapper didn't work out of the box in this setup.

Workaround: move .snapshot, run snapper create-config, and then restore the old .snapshot if needed.

[NicoHood]

I have the same problem. I created a proper btrfs snapshot backup concept and filesystem structure myself. I am mounting .snapshot always from the btrfs root instead of creating a local subvolume. This way I have more control over my subvolumes and I can restore them easier.

Would there be an option to ignore this check? If the directory is empty it should be safe to create a new config. Snapper could check for that indead, but only warn then, not abort.

Duplicate: https://github.com/openSUSE/snapper/issues/173

[audreytoskin]

My use-case: an external drive used for backups, that I plug on multiple machines. Obviously, running create-config on the second machine it found the .snapshot created by the first. A pity (or a bug?) that snapper didn't work out of the box in this setup.

I'm running into this issue too. Snapper's current insistence on creating its own .snapshots subvolume means:

• You can't run snapshots on the same external storage from different OSes, because the second OS won't be able to create a config
• Even when only using a single OS, if you ever have to reinstall the OS, you'd have to wipe all old snapshots before you can start taking new snapshots.

I'm currently using Snapper 0.5.6 with Btrfs 4.17.1 and Linux kernel 4.19.10 on Fedora 29 Workstation x86_64.

Manually creating my own snapper config file based on the default template doesn't help. Trying to take a snapshot, snapper always says "Unknown config." After a while, it seems like the file I created under /etc/snapper/configs/ keeps getting deleted...

[audreytoskin]

Turns out what I was missing was I needed to add the filename of the new config I manually created to a SNAPPER_CONFIGS parameter under /etc/sysconfig/... Requiring this parameter seems funny to me -- why not just read the list of files in /etc/snapper/configs/?

↪  ls /etc/snapper/configs/
home  main_storage  root

↪  cat /etc/sysconfig/snapper
SNAPPER_CONFIGS="home main_storage root"

Anyway, my own problem is solved for now, but I still agree that it would be nice if snapper create-config could gracefully handle devices and subvolumes that already have snapshots and a .snapshots directory.

[ShadowBoxer2]

The snapshots config may be deleted but the ".snapshots" directory is still there And it can be growing taking up hard drive space and creating critical errors !

1. remove all files from .snapshots directory: example: btrfs subvolume delete /.snapshots/1/snapshot

2. make scripts for automation:

   Split output from ls command to list into one column.

   File1.sh #!/bin/bash ls /.snapshots | perl -ple 's/\h/\n/g' And

   delete snapshot files,

   File2.sh #!/bin/bash read inputvar echo the number is $inputvar btrfs subvolume delete /.snapshots/$inputvar/snapshot rm -rf /.snapshots/$inputvar

   Then

   pipe output of File1 into File2: ./File1.sh | ./File2.sh This will delete one set of files at time.
   todo: add a while loop. simplify.

   After the directory is empty: btrfs subvolume delete /.snapshots
   where "/" is the target directory, (in this case in root dir)