Open floatingatoll opened 7 years ago
Hi @floatingatoll -- it should already be configured to look like a network mount. You might just have to list if explicitly in your software's exclude list. Not sure what else to do on our end. It's true that root
does not have permissions to read /keybase
, only the user you mount it as.
For 'root', it would be invaluable if /keybase was an otherwise-empty directory with a README explaining what's going on. That would help people who do things as root on OS X (sudo or otherwise) understand why keybase isn't accessible, when eventually they get around to trying that, and would also give backup software something other than an disk read error.
On Mon, Mar 13, 2017 at 8:45 PM, Jeremy Stribling notifications@github.com wrote:
Hi @floatingatoll https://github.com/floatingatoll -- it should already be configured to look like a network mount. You might just have to list if explicitly in your software's exclude list. Not sure what else to do on our end. It's true that root does not have permissions to read /keybase, only the user you mount it as.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keybase/client/issues/6238#issuecomment-286313888, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFqDG3-lt2LM-6YHLFXl_ioQmgexJSkks5rlg1SgaJpZM4McFqx .
Thanks for giving this some thought @floatingatoll, interesting idea. Unfortunately, the way Finder works in macOS means that we can't present root
with an empty folder. Finder often drops into root
mode to look up attributes about files -- why it does that, I couldn't tell you. But the file system kernel module we use (osxfuse) has many fancy exceptions to let those Finder-related calls through, but not other types of root access like listing directories, etc.
Do the errors you're seeing actually break the backup software? Or does it just log the error and move onto the next directory? Also, are you willing to name the software so we can test with it? Thanks!
Ah, that explains why it's all getting confused. That's crazy! I had no idea! I'm so sorry! :(
I should have noticed you were using FUSE. It means this is all basically a FUSE problem and not a Keybase problem. They don't break it, it just logs it and moves on.
Arq Backup is the one I use everyday, and is available to the general public.
On Tue, Mar 14, 2017 at 11:06 AM, Jeremy Stribling <notifications@github.com
wrote:
Thanks for giving this some thought @floatingatoll https://github.com/floatingatoll, interesting idea. Unfortunately, the way Finder works in macOS means that we can't present root with an empty folder. Finder often drops into root mode to look up attributes about files -- why it does that, I couldn't tell you. But the file system kernel module we use (osxfuse) has many fancy exceptions to let those Finder-related calls through, but not other types of root access like listing directories, etc.
Do the errors you're seeing actually break the backup software? Or does it just log the error and move onto the next directory? Also, are you willing to name the software so we can test with it? Thanks!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/keybase/client/issues/6238#issuecomment-286509698, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFqDMsFl8IyMU-OdPFwszD9BNBLEbCxks5rltcPgaJpZM4McFqx .
Keybase GUI Version: 1.0.20-20170309192151+e30557a
When trying to back up my computer with any backup agent that uses administrative privileges to perform backups, they universally report filesystem errors trying to access /keybase/ to back it up.
This is probably because 'root' has no keybase configuration. It may make sense on Mac to handle this specific case more effectively, so that backup clients either back up nothing (which is fine) or ignore the mount (because you tune it to look like a network mount, or something, which is also fine) or some other manner altogether.