Duncan <1i5t5.duncan <at> cox.net> writes: > That's almost certainly due to the state of the location where btrfs > stores scrub status information, /var/lib/btrfs, which should be a > directory that's both writable by btrfs during the scrub, and readable at > the time btrfs scrub status is run. > > It appears that (as expected for such commands) you're running btrfs as > root, so normal file permissions shouldn't matter. > > However, if you have that filesystem mounted read-only at the time, or if > you or your distro has configured additional security restrictions like > SE Linux and they're preventing access to that dir, that would explain > the problem. > > Additionally, I'm not sure whether btrfs scrub will create that directory > (and its parents /var/lib and /var) dynamically if needed, or if the > package is supposed to do that at installation, so btrfs scrub itself > doesn't do it. In the latter case, if the directory simply doesn't > exist, that would prevent the status files from being written, and thus > read, as well.
Thank you, sir, for taking the time to post at length. The (need to) repost gives it away as something I'd done/not done; rather than a generic problem. I think I've always run some btrfs commands as root, because they've not allowed themselves to run with lower priv. It sounds to me like I have hamstrung myself somewhere/somewhat as the directory is only for root user (only). $ la /var/lib/btrfs total 8.0K -rw------- 1 root root 360 Jan 26 11:45 scrub.status.caf3bccc-6061-44bc-9726-96a87cfdb9eb -rw------- 1 root root 1.4K May 17 02:12 scrub.status.fdd6a335-6edf-4a74-a909-03c8102cc8f5 The two files represent two file systems scrubbed (a RAID6 4device and a DUP single). Both are effectively 'zero'. So it only remains to go find the directory correct permissions and if the directory is recreated. I'll come crying back if I can't find it! Been running btrfs from quite early on, early linux three I think, and have only had it self-implode once. Every other problem has been of my own making I think: damn you 'dd'. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
