Snapper-Backup/snbk parent subvol not reachable from root subvol

[trainzkid]

Having trouble using snapper-backup.service on Arch to transfer to a secondary drive on the same machine:

$USER@$HOST ~> journalctl --unit snapper-backup --since "2026-01-25 13:30" --output cat --no-pager

Transferring snapshot 1.
Transferring snapshot 2.
Transferring snapshot 14638.
Sun 25 Jan 2026 01:50:53 PM CST <3> TheBigThing.cc(transfer):157 command '/bin/sh -c '/usr/bin/btrfs' 'send' '-p' '//.snapshots/2/snapshot' '--' '//.snapshots/14638/snapshot' | '/usr/bin/btrfs' 'receive' '--' '/mnt/arch/.snapshots.new/14638'' failed: 1
Sun 25 Jan 2026 01:50:53 PM CST <3> TheBigThing.cc(transfer):159 At snapshot snapshot
Sun 25 Jan 2026 01:50:53 PM CST <3> TheBigThing.cc(transfer):161 At subvol //.snapshots/14638/snapshot
Sun 25 Jan 2026 01:50:53 PM CST <3> TheBigThing.cc(transfer):161 ERROR: parent subvol is not reachable from inside the root subvol
Sun 25 Jan 2026 01:50:53 PM CST <3> TheBigThing.cc(transfer):161 ERROR: failed to read stream from kernel: Broken pipe
'btrfs send | btrfs receive' failed.
Running transfer and delete for backup config 'system2mnt-arch' failed.
Running transfer and delete failed for 1 of 1 backup config.
snapper-backup.service: Main process exited, code=exited, status=1/FAILURE
snapper-backup.service: Failed with result 'exit-code'.
snapper-backup.service: Consumed 10min 23.707s CPU time over 25min 37.223s wall clock time, 10G memory peak.
snapper-backup.service: Triggering OnFailure= dependencies.

The error states that the parent subvolume isn't reachable, but the subvolume that was transferred before this one (2) shows the same parent ID as this subvolume (14638):

$USER@$HOST ~> sudo btrfs subvolume show /.snapshots/14638/snapshot

@snapshots/14638/snapshot
        Name:                   snapshot
        UUID:                   cbf4174f-9756-f542-809f-2ec3a53b4165
        Parent UUID:            157b0e88-8230-2247-b63e-c31421bf9113
        Received UUID:          -
        Creation time:          2025-11-01 10:00:12 -0500
        Subvolume ID:           338
        Generation:             335131
        Gen at creation:        136614
        Parent ID:              262
        Top level ID:           262
        Flags:                  readonly
        Send transid:           0
        Send time:              2025-11-01 10:00:12 -0500
        Receive transid:        0
        Receive time:           -
        Snapshot(s):
        Quota group:            n/a

$USER@$HOST ~> sudo btrfs subvolume show /.snapshots/2/snapshot

@snapshots/2/snapshot
        Name:                   snapshot
        UUID:                   27035bf1-9aee-e341-8b8c-b1b5ce61ef32
        Parent UUID:            157b0e88-8230-2247-b63e-c31421bf9113
        Received UUID:          -
        Creation time:          2025-10-07 10:00:00 -0500
        Subvolume ID:           263
        Generation:             334636
        Gen at creation:        72569
        Parent ID:              262
        Top level ID:           262
        Flags:                  readonly
        Send transid:           0
        Send time:              2025-10-07 10:00:00 -0500
        Receive transid:        0
        Receive time:           -
        Snapshot(s):
        Quota group:            n/a

Both of these snapshots were created via snapper-timeline.service so I'm not really sure why one worked but the other didn't, and snbk doesn't continue after a failure, so I'm not sure if the ones after that one will work. I'm considering moving that snapshot to see if snbk will do the rest without complaint, but I've yet to try it. I'm on the latest version of snapper available on Arch Linux, though I thought I saw someone in another issue saying that this version is not the latest stable release from here on this GitHub, and I've seen evidence of this (MKNOD capability missing from snapper-backup.service on my system, yet present here on GitHub), but that confuses me even more because the version numbers of snapper on Arch matches the latest release here on GitHub. Anyway..

env:

$USER@$HOST ~> pacman --query linux-zen snapper btrfs-progs

linux-zen 6.18.5.zen1-1
snapper 0.13.0-2.1
btrfs-progs 6.17.1-2

Let me know if this is something dumb that I'm doing/missing or if more info is needed!

[aschnell]

I have never seen that error message before. Maybe some strange mounts so some snapshot is not visible as usual.

Concerning the snapper version: There has not been a release after the MKNOD fix.

[trainzkid]

I did some further testing and it appears that all of my snapshots except for the first 2 ("1" and "2") are failing to transfer with the same error. Interestingly, if I manually transfer each snapshot (with btrfs send $src | btrfs receive $dst, no -p flag), snbk considers those snapshot pairs to be valid and will continue on to the next snapshot (where it'll once again error out with the same error). I assume the -p flag is used in this case to reduce bandwidth and speed up the transfer? If my assumption is correct, could an option be added to do the transfer without the -p flag? I know that doesn't necessarily fix the problem..

I'm not able to run the same command snbk is trying to run either (with the -p flag), so I suspect that, like you said, this has to do with the destination I'm trying to transfer to. I'm trying to send snapshots of root (/, btrfs) located on an SSD to a directory on a separate btrfs formatted HDD. Is this out of scope for snbk? I would assume since ssh is an option, that backing up to a separate drive/system is still within scope idk.

Ironically, using the -p flag would be good for another transfer I've been planning that transfers to a locally mapped NBD network drive, since the latency is so large, which slows file transfers down to that drive significantly. Although, it sounds like btrfs doesn't like something about what I'm trying to do, so it likely wouldn't work anyway (using the -p flag).

[aschnell]

The -p flag is essential: Without it you do not only use more bandwidth but also much more disk space on the target (unless you run deduplication). Removing it is not an option.

[jamesljlster]

I searched for the reported error message and found several related issues:

• ERROR: parent subvol is not reachable from inside the root subvol kdave/btrfs-progs#649
• ERROR: parent subvol is not reachable from inside the root subvol baodrate/snap-sync#107 (comment)

I'm not sure whether this helps, but they seem potentially related.
@trainzkid Would you mind listing all subvolumes on your target backup device?
The command should be something like:

sudo btrfs subvolume list /mnt/arch/

[trainzkid]

So I (manually) transferred about a 3rd of the snapshots, running the snapper-backup.service after each one to see if it would fail to transfer the next or not and after a group of snapshots in the middle, it started transferring newly created snapshots just fine. I think this means some of my snapshots are no good for some reason, even though I'm fairly certain they were created automatically via snapper-timeline.service. I guess that means I'll have to transfer the ones in the middle manually each time I set a new destination for snapper-backup.service/snbk, not ideal but tolerable.

Anyway, here's the list of snapshots at the destination:

$USER@$HOST ~> sudo btrfs subvolume list /mnt/arch/

ID 259 gen 3414167 top level 5 path @
ID 260 gen 3414186 top level 5 path @home
ID 261 gen 3413669 top level 5 path @snapshots
ID 262 gen 3343528 top level 259 path var/lib/portables
ID 263 gen 3353799 top level 259 path var/lib/machines
ID 11352 gen 1824537 top level 261 path @snapshots/6729/snapshot
ID 29159 gen 1824537 top level 261 path @snapshots/14620/snapshot
ID 32353 gen 1824249 top level 263 path var/lib/machines/.tar-https:\x2f\x2fhub\x2enspawn\x2eorg\x2fstorage\x2farchlinux\x2farchlinux\x2ftar\x2fimage\x2etar\x2exz.\x22a4fcf20-612b75200bd1b\x22
ID 34090 gen 2323038 top level 261 path @snapshots/17223/snapshot
ID 34183 gen 2410315 top level 261 path @snapshots/17254/snapshot
ID 34273 gen 2494908 top level 261 path @snapshots/17284/snapshot
ID 34312 gen 2530149 top level 261 path @snapshots/1479/snapshot
ID 34368 gen 2582202 top level 261 path @snapshots/17315/snapshot
ID 34459 gen 2669199 top level 261 path @snapshots/17346/snapshot
ID 34553 gen 2748085 top level 261 path @snapshots/17374/snapshot
ID 34739 gen 2835464 top level 261 path @snapshots/17405/snapshot
ID 34866 gen 2921362 top level 261 path @snapshots/17435/snapshot
ID 34959 gen 3008588 top level 261 path @snapshots/17466/snapshot
ID 35049 gen 3093099 top level 261 path @snapshots/17496/snapshot
ID 35142 gen 3179638 top level 261 path @snapshots/17527/snapshot
ID 35235 gen 3266231 top level 261 path @snapshots/17558/snapshot
ID 35310 gen 3336100 top level 261 path @snapshots/17583/snapshot
ID 35313 gen 3338913 top level 261 path @snapshots/17584/snapshot
ID 35316 gen 3341719 top level 261 path @snapshots/17585/snapshot
ID 35319 gen 3349669 top level 261 path @snapshots/1/snapshot
ID 35320 gen 3349687 top level 261 path @snapshots/2/snapshot
ID 35321 gen 3349691 top level 261 path @snapshots/6/snapshot
ID 35322 gen 3349694 top level 261 path @snapshots/7/snapshot
ID 35323 gen 3349697 top level 261 path @snapshots/8/snapshot
ID 35324 gen 3349700 top level 261 path @snapshots/9/snapshot
ID 35325 gen 3414148 top level 260 path @home/.snapshots
ID 35326 gen 3409511 top level 35325 path @home/.snapshots/1/snapshot
ID 35327 gen 3409566 top level 35325 path @home/.snapshots/2/snapshot
ID 35394 gen 3413268 top level 259 path .snapshots.new/1/snapshot
ID 35395 gen 3413289 top level 259 path .snapshots.new/2/snapshot
ID 35408 gen 3413537 top level 261 path @snapshots/14638/snapshot
ID 35410 gen 3413599 top level 261 path @snapshots/14668/snapshot
ID 35411 gen 3413629 top level 261 path @snapshots/14699/snapshot
ID 35413 gen 3413641 top level 35325 path @home/.snapshots/77/snapshot
ID 35416 gen 3413653 top level 35325 path @home/.snapshots/80/snapshot
ID 35418 gen 3413703 top level 259 path .snapshots.new/14638/snapshot
ID 35420 gen 3413723 top level 35325 path @home/.snapshots/83/snapshot
ID 35422 gen 3413762 top level 259 path .snapshots.new/14668/snapshot
ID 35423 gen 3413796 top level 259 path .snapshots.new/14699/snapshot
ID 35428 gen 3413958 top level 35325 path @home/.snapshots/86/snapshot
ID 35430 gen 3414149 top level 259 path .snapshots.new/14734/snapshot
ID 35433 gen 3414064 top level 35325 path @home/.snapshots/89/snapshot
ID 35436 gen 3414075 top level 35325 path @home/.snapshots/92/snapshot
ID 35439 gen 3414086 top level 35325 path @home/.snapshots/95/snapshot
ID 35441 gen 3414092 top level 35325 path @home/.snapshots/97/snapshot
ID 35442 gen 3414099 top level 35325 path @home/.snapshots/98/snapshot
ID 35443 gen 3414102 top level 35325 path @home/.snapshots/99/snapshot
ID 35444 gen 3414104 top level 35325 path @home/.snapshots/100/snapshot
ID 35445 gen 3414110 top level 35325 path @home/.snapshots/101/snapshot
ID 35446 gen 3414114 top level 35325 path @home/.snapshots/102/snapshot
ID 35447 gen 3414116 top level 35325 path @home/.snapshots/103/snapshot
ID 35448 gen 3414127 top level 35325 path @home/.snapshots/104/snapshot
ID 35449 gen 3414132 top level 35325 path @home/.snapshots/105/snapshot
ID 35450 gen 3414134 top level 35325 path @home/.snapshots/106/snapshot
ID 35451 gen 3414139 top level 35325 path @home/.snapshots/107/snapshot
ID 35452 gen 3414143 top level 35325 path @home/.snapshots/108/snapshot
ID 35453 gen 3414147 top level 35325 path @home/.snapshots/109/snapshot
ID 35454 gen 3414152 top level 259 path .snapshots.new/14738/snapshot
ID 35455 gen 3414155 top level 259 path .snapshots.new/14739/snapshot
ID 35456 gen 3414158 top level 259 path .snapshots.new/14740/snapshot
ID 35457 gen 3414161 top level 259 path .snapshots.new/14741/snapshot
ID 35458 gen 3414164 top level 259 path .snapshots.new/14742/snapshot
ID 35459 gen 3414167 top level 259 path .snapshots.new/14743/snapshot

My current config for snapper-backup.service/snbk is to transfer to /mnt/arch/.snapshots.new/ because /mnt/arch/.snapshots/ has snapshots from the same system but after I moved to a new hard drive/SSD. I obviously don't want to lose any snapshots that are older on the off chance I need data from them, and the default action for snapper-backup.service is to remove those snapshots that it has decided are invalid, hence all the snapshots in various places. I apologize, I'm not sure what I'm looking for with this list of snapshots.

[jamesljlster]

You are good. We definitely don't want to lose any we want to keep, including old system snapshots.
I reviewed your subvolume list and have a question. Are your system (the backup source) and the backup target on the same Btrfs filesystem?
I'm asking because I see the system subvolumes (@, @home) and the backup target (.snapshots.new) all appearing in the list.
Sorry if I misunderstood your setup.

By the way, you mentioned:

the default action for snapper-backup.service is to remove those snapshots that it has decided are invalid

I think this could be opened as a separate issue related to the backup retention policy.
When I'm restoring a system onto a fresh device, it would be necessary to restore all snapshots before booting into the system. Otherwise, snbk might delete old snapshot backups on the target device during the first run.

[trainzkid]

Are your system (the backup source) and the backup target on the same Btrfs filesystem?

No, the target is an old HDD that I btrfs send | btrfs receive'd to a new SSD (the source) a few months ago and booted into. I'm not sure I did that the correct way as per how Snapper suggests, so that may be my issue. However, I don't fully understand why the source and the target being the same filesystem would be beneficial, the point of using snapper-backup.service/snbk (I thought) is to send snapshots to another, potentially remote location in the event of emergencies. If I were using the ssh transfer method, it's almost guaranteed that the target would be a different filesystem, as it would live on a different system entirely. Maybe I'm misunderstanding though, I apologize! 😅

I think this could be opened as a separate issue related to the backup retention policy.

Yeah I'm not super sure why the default action is to remove potentially usable snapshots, but it is indeed helpful when I've got snapshots being created on a timeline so that the source and target remain in-sync as far as snapshots that fall outside of the retention window. As you said, it's not very helpful when I've got old snapshots that do indeed fall within the retention window but snbk has for some reason decided they're not valid. Maybe what "valid" means could be expanded or better clarified. Either way, I'm open to input to my apparently very unique problems 😂

[jamesljlster]

However, I don't fully understand why the source and the target being the same filesystem would be beneficial

No, I don't think using the same filesystem for both the source and the target is a good idea, and I'm not even sure whether it would work. I really did misunderstand your setup earlier, sorry about that!

I believe using btrfs send | btrfs receive is the correct way to restore your system onto the new SSD.
By the way, the latest unreleased version of snbk supports restoring snapshots to the source device.
If you would like to try it, you will need to build it yourself for now. Please refer to: #1088 (comment)
If you are familiar with Arch PKGBUILD, I would recommend modifying the latest Snapper PKGBUILD to build and install the package.

Once you have restored the old snapshots, you will have another copy of the important old data, which improves overall data safety. However, since you already have new snapshots on the SSD, restoring the old snapshots to the source device may lead to conflicts, such as snapshot number collisions. Some manual migration will likely be necessary to align them. Either via scripts or manual operations.
Also, if you restore any snapshots to the source device, please remember to restart the snapperd service to make them visible. This is a known limitation at the moment.

I'm very interested in your very unique problem. 😆 
I believe if your problem gets resolved, I will learn something new about Btrfs troubleshooting. I'm still a Btrfs newbie.
Since your data on the HDD is important, it's not a good idea to experiment on it. Do you have a spare physical drive or sufficient space to create a virtual disk? (I would recommend using a physical drive if possible.)
If we want to determine if there is an issue with the target filesystem, we could prepare a clean filesystem for testing. Here is an example using a virtual disk (since I don't have a spare physical drive):

# Create a virtual disk with sufficient capacity (40G as an example)
sudo dd if=/dev/zero of=virtual_target.img bs=1M count=40960

# Format it as Btrfs
sudo mkfs.btrfs virtual_target.img

# Mount it
sudo mkdir /mnt/virtual-target
sudo mount -o loop virtual_target.img /mnt/virtual-target

# Verify the mounts
findmnt /mnt/virtual-target
df -h /mnt/virtual-target

# Create a subvolume for snapshot backups
sudo btrfs subvolume create -p /mnt/virtual-target/snapper/root

Once the clean target filesystem is ready, you can create a new test backup config, for example:
/etc/snapper/backup-configs/root-virtual.json

{
  "config": "root",
  "target-mode": "local",
  "source-path": "/",
  "target-path": "/mnt/virtual-target/snapper/root",
  "automatic": false
}

Then run:

sudo snbk -b root-virtual --verbose transfer

If it completes without issues, there may be a problem with your HDD target filesystem.
Otherwise, I would suspect there could be an issue with the source filesystem.

Yeah I'm not super sure why the default action is to remove potentially usable snapshots

I assume the retention policy is designed to follow the source Snapper config (please correct me if I'm wrong, Arvin).
Would you mind opening a separate issue to discuss this topic further?

[jamesljlster]

Sorry, I linked this issue to the wrong PR by mistake.