Replies: 1 comment
-
No, there is no guidance because it's completely a personal and subjective concern. Only you know what the correct values are. Who the owners are and what the perms are. It's just ownership and permission data. You can't bork anything you can't just go and fix. There is nothing you can do here that could "kill" your setup. Worse case is you have to become root and chmod and chown them. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
With apologies in advance for what is likely a dumb question, are there any resources available to provide some guidance on how to choose the appropriate fix when using mergerfs.fsck? I've used fsck before but this seems to be a bit different. For example, I've just run
mergerfs.fsck -v -f manual /vdata
Where
vdata
is the mountpoint of my mergerfs drive array, comprised of 16 drives each mounted at/mnt/data/dataX/
. The first thing that's displayed is this:I suppose I should perhaps just pick the newest, but to be honest am not even sure of the implications of selecting the newest and am deathly afraid of borking the entire array by making the wrong choice, particularly in this case, where it seems to be identifying an issue with the mountpoint itself (
/vdata
). I'm also not quite sure I understand the "nonroot" fix option. I've tried googling to find a guide or something to provide more details but haven't had much luck. Any advice or suggestions (or pointers to more detailed guidance), particularly in relation to how to avoid killing my whole array, would be most appreciated.Beta Was this translation helpful? Give feedback.
All reactions