In your case, it should be
root = “@snapshots/.snapshots,@,b4328e45-d246-4613-938c-a559ba2a0a2c”
As a side note, I am not sure how that layout is possible. Can I see your findmnt --real
Sure, follows below:
findmnt --real
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda2[/@] btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=256,subvol=/@
├─/var/cache /dev/sda2[/@cache] btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=258,subvol=/@cache
├─/.snapshots /dev/sda2[/@snapshots] btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=266,subvol=/@snapshots
├─/swap /dev/sda2[/@swap] btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=265,subvol=/@swap
├─/var/log /dev/sda2[/@log] btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=259,subvol=/@log
├─/home /dev/sda2[/@home] btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=257,subvol=/@home
├─/boot/efi /dev/sda1 vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
Interesting, you have @snapshots mounted at /.snapshots.
Normally, this would result in your snapshots being something like:
@snapshots/1/snapshot
However, yours are in:
@snapshots/.snapshots/1/snapshot
I am not entirely sure how you did that…
In live USB I did the following:
# mount /dev/sda2 /mnt -o subvolid=5
$ cd mnt
# btrfs subvolume create @snapshots
added this to fstab:
UUID=2e7adfca-adc3-4e39-82da-05844c0ae3b6 /.snapshots btrfs subvol=/@snapshots,defaults,noatime,compress=zstd,ssd 0 0
Edit: I did this way because grub.btrfs.path wasn’t working…
That seems pretty normal but if you take a look at someone else from above who did the same thing you, here is their list:
btrfs subvolume list /
ID 256 gen 80 top level 5 path @
ID 257 gen 80 top level 5 path @home
ID 258 gen 73 top level 5 path @snapshots
ID 259 gen 80 top level 5 path @log
ID 260 gen 79 top level 5 path @cache
ID 262 gen 61 top level 258 path @snapshots/1/snapshot
ID 263 gen 67 top level 258 path @snapshots/2/snapshot
ID 264 gen 72 top level 258 path @snapshots/3/snapshot
Btrfs Assistant can support it either way, I was just curious because I have never seen that happen before.
1 Like
Thanks Dalto, I managed to fix it
Edit: only manual snapshots works…
I’ll make a new install here…
That isn’t right either. There may be a bug in btrfs-assistant-git.
The dropdown box should have @ in it, not @snapshots
Thanks Dalto, I’ll have to do a few things now for my work, be back later.
Anything you need from to check if its a bug or not, I’ll be glad to help, but I’m not sure how long its going to take from now
1 Like
Damn, for a short time I considered to set up my partitions with Btrfs on my recent installation but I opted to use ext4 instead. Now I’d wish I would have chosen Btrfs to test this. Btrfs’s features and this utility look pretty neat 
. Maybe next time…
4 Likes
Make the leap, it’s well worth the work 
I’m back Dalto, in case you have something that I can do to test, just tell me
I put a temporary fix in for that one issue. Can you see if that fixes your problem or if there is more to do?
1 Like
Sure, I’ll test it right now, you are fast huh? 
For the Backup path, should I choose / or /.snapshots ?
/etc/btrfs-assistant.conf
root = “@snapshots,@,94137a44-5d96-4426-8c98-f28de58b427a”
The backup path is what you want to take snapshots of. So I strongly suspect the answer is / 
2 Likes
name root backup path /
This is my layout:
$ sudo btrfs subvolume list /
ID 256 gen 228 top level 5 path @
ID 257 gen 228 top level 5 path @home
ID 258 gen 214 top level 5 path @cache
ID 259 gen 228 top level 5 path @log
ID 260 gen 27 top level 256 path var/lib/portables
ID 261 gen 28 top level 256 path var/lib/machines
ID 262 gen 79 top level 5 path @snapshots
ID 263 gen 128 top level 5 path @swap
Yes, I need to fix that to show the error. That basically means that the Snapper command failed.
For now, try just running it manually.
sudo snapper -c root create-config /
Then you can see why it is failing.
it worked…
$ sudo snapper -c root create-config /
Falha ao criar a configuração (creating btrfs subvolume .snapshots failed since it already exists)
$ sudo umount /.snapshots
$ sudo rm -r /.snapshots
Here, I created the configuration in btrfs-assistant-git <--
$ sudo btrfs subvolume delete /.snapshots
Delete subvolume (no-commit): '//.snapshots'
$ sudo mkdir /.snapshots
$ sudo mount -o subvol=@snapshots /dev/sda2 /.snapshots
$ sudo mount -a
1 Like
If I have the grub.btrfs.path working, I don’t need the snap-pac-grub, right?
$ sudo systemctl status grub-btrfs.path
● grub-btrfs.path - Monitors for new snapshots
Loaded: loaded (/usr/lib/systemd/system/grub-btrfs.path; enabled; vendor p>
Active: active (waiting) since Thu 2022-04-07 13:10:03 -03; 4s ago
Until: Thu 2022-04-07 13:10:03 -03; 4s ago
Triggers: ● grub-btrfs.service
abr 07 13:10:03 eos systemd[1]: Started Monitors for new snapshots.