This should be fixed in utopic and later.
Nominating for trusty SRU.
** Also affects: btrfs-tools via
http://bugzilla.kernel.org/show_bug.cgi?id=69401
Importance: Unknown
Status: Unknown
** Changed in: btrfs-tools (Ubuntu)
Status: Confirmed => Fix Released
--
You received
For me Alan's workaround didn't work. But I found an another one that
worked for me for sending @ and @home subvolumes (kernel bug tracker,
comment 1 [0]):
1. Make directory for snapshots: mkdir /.snapshots
2. Take snapshot of subvolume, eg. @home: btrfs subvolume snapshot -r /home
** Description changed:
If I create a snapshot, of a subvolume and try to use btrfs send it
fails with No such file or directory
# sudo btrfs sub create /testvol
Create subvolume '//testvol'
# sudo btrfs
- btrfs btrfsck btrfs-debug-treebtrfs-image
I have the same bug, and working with btrfs and lxc containers, there is
no workaround. Container can't send or reveive snapshot.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1348430
Title:
btrfs
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: btrfs-tools (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1348430
Title:
I had this problem as well, and my situation was a little more
complicated to use the workaround.
My subvolume that was being snapshotted for 'btrfs send' to use was at
the top of the hierarchy - there WAS no parent. But BTRFS always has a
parent, so there is still a workaround.
My situation:
Current workaround until upstream bug is fixed (works for me):
If you mount the btrfs root (without specifying subvol=@...) to e.g. /mnt then
you can use btrfs send successfully
e.g.
btrfs subvolume snapshot -r /mnt/@ /mnt/snapshots/MMDD-HHMMSS-@
btrfs send
