ERROR: cannot find parent subvolume, can't see reason for it.

I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the following error:

ERROR: cannot find parent subvolume

The "src/snp1" is present in both "src/" and "dst/". The "src/snp2" is present in "src/" .
The send works when "-p" is not used, but will not work when it is.

I imagine I am missing something obvious but cannot see what, and would appreciate some suggestions on what might be causing the error.

note: I have sent several queries to this list, but have not heard anything back. I hope they have not been inappropriate. If so, I would be grateful if you would let me know, or if there is somewhere else I should be going for advice.

I have had pretty good luck with the basics of btrfs and have high hopes for it. I do seem to be having some difficulty getting much beyond basic functionality with small flat filesystem layouts, and will soon have to revert back to ext4 for some of the more complex functionality I made use of under that. I look forward to seeing what further progress might be had with btrfs, and hope to be able to use it in a few years time.

J. Hart posted on Sat, 29 Apr 2017 23:10:48 -0400 as excerpted:

Note that my own use-case doesn't include send/receive, so the degree to which I can get into specific detail is limited, but as you mentioned sometimes we miss the obvious and need someone else to point it out, so in that spirit, here's a couple obvious things:

* Your apparently contrived for posting paths above are relative. Have you tried absolute paths and/or are you certain the relative paths are correctly relative to your current working directory?

* src/snp1 is a read-only snapshot, not just a directory, correct?

I see three previous threads (the first starting on March 25) with you as original poster on the list, all of which have followups to the list, one of which has a single followup from you to someone replying to you, from you as well. I don't however see any followups from you to replies on the other two threads, and only the one followup to someone replying on the one thread.

So it may be that you're not getting the replies very well.

Are you subscribed to the list? While some posters reply directly to author as well, and that's encouraged, some reply only to the list (including me unless specifically asked or there's some other hint, as here, that it may be needed).

The other possibility, of course, is that replies are getting spam-binned via gmail or on your end. You may want to check that.

Meanwhile, if you're subscribed or are otherwise not getting replies, there's a number of list archives available, see:

https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list

The mail-archive one is probably easier to use than marc, and the gmane web-based archive is offline, possibly permanently.

(Gmane does still have the news-based, that is nntp:// archive available, which I actually read and post thru myself, but the service recently changed hands and there's little information on whether the web service is coming back or not, and without it the news side is likely to eventually die as well.)

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

It's not merely that it must be present. The src/snp1 must have originally been sent to dst/ using btrfs send/receive. And in particular it's trying to match subvolume UUIDs; so really the error is "cannot find parent subvolume uuid on the destination" - at least I *think* that's what's going on.

You'd need to use -v or possibly -vv with both the send and receive commands to get more verbose output and maybe see whether it's the send or receive side having the problem. I'm gonna guess it's the receive side.

Chris Murphy

Thank you very much for your response.

I had just discovered exactly this a few hours ago. In sending an original snapshot instead of using a duplicate already in place, I was able to get around this problem. As you mentioned, the error was coming from the receive side.

I am presently investigating a another error I have detailed in another message:

ERROR: rename o3528-7220-0 -> usr failed: Directory not empty

It is probably not related. I will file a report with Kernel.org bugzilla on it.