I cannot seem to access the /keybase directory. I am running latest version of arch (pacman -Syu cron everyday), and installed from pacman. I setup the kbfs as per https://wiki.archlinux.org/index.php/Keybase#Keybase_Filesystem_(KBFS).
The service is running, and the fs is mounted at /run/user/1000/keybase/kbfs, but still cant access using /keybase. Im not sure if this is expected or if i must explicitly set the mount dir to /keybase through keybase config set mountdir, but i cannot find any documentation pointing me on this.
Opening as issue from lack of documentation on this, and from client behavior not matching documentation.
If its of any help/interest, I wanted to test if i could have html files in my public folder, and pull / parse / process them in a nodejs process (I feel keybase fs could pair with a couple of my tor projects nicely, can provide links to repo if devs are interested in integration)
my log id: 30ee9df4a58612c5da4b061c
Found temporary fix:
# ln -s /run/user/1000/keybase/kbfs /keybase
If this is a good solution for the devs I can submit an edit to the arch wiki to help new users
@stoneRdev I don't think the arch package supports the /keybase mount point by default, it's a community package and @eli-schwartz would know more.
You can always change the location of the mount point with keybase config set mountdir <desired_mountpoint>.
@stoneRdev,
The /keybase mountpoint is implemented by the Keybase developers upstream, using a setuid program implementing a FUSE filesystem redirector. It has been, if I remember correctly, referred to as a "legacy compatibility" shim. Really, you should just use the qualified path from keybase config get -b mountdir. This would also mean that your interesting tor projects would still work, on systems where the user has manually disabled the root redirector as per the instructions here: https://keybase.io/docs/kbfs/understanding_kbfs#root-redirector
I'm not interested in packaging any method that requires setuid binaries, especially given I don't... really see the purpose in doing so just for a glorified symlink, and it's an officially supported configuration to disable it anyway. (@strib would be justified in pointing out that that is opt-out, whereas I have automatically opted out for all Arch users using my community package, but on the other hand... supported configuration, programs that integrate with kbfs should be expected to support this use case, and it is after all a community package, so I'm okay with making that choice on behalf of interactive use.)
So yeah, programs querying keybase really should just ask the API where the mountpoint is. For interactive use by users, the keybase-gui already lets you open files in your default file browser, but I think there is an interesting symmetry to other file storage solutions (e.g. Dropbox) in changing your mountpoint to ~/keybase.
An interesting side effect of re-mounting your keybase directory to ~/keybase is that it will automatically gain a visible udisks label, and thus, appear in the bookmarks panel of many file browsers under "Devices". Of course, using /media is also an option (or /run/media/$USER for people who in my totally biased opinion are silly for not setting UDISKS_FILESYSTEM_SHARED), which, given that the keybase directory is a FUSE mount rather than a synced normal directory, may seem like it has more symmetry, depending on the individual.
Got the same error on MacOS. Here is my id: 9819c3fed8e6de7563efd81c
@PierrickGT this is a thread specifically about arch -- can you please open a new issue so we don't mix up the discussion?
Ahh, thanks for the feedback everyone. I ended up linking the keybase directory to /keybase for my own cli convenience, and my server uses the path provided by keybase config get -b mountdir and works as expected. I think this issue has been resolved and can be closed with the solution:
/run/user/1000 and should be changed using keybase config set mountdir if desiredkeybase config get -b mountdir to get location of kbfs mount~/keybase can provide a more consistent experience with other file storage programsThank You
@strib
and
@eli-schwartz
for the clarification and direction. Much Appreciated!
Great! Thanks for the summary.
Most helpful comment
@stoneRdev,
The /keybase mountpoint is implemented by the Keybase developers upstream, using a setuid program implementing a FUSE filesystem redirector. It has been, if I remember correctly, referred to as a "legacy compatibility" shim. Really, you should just use the qualified path from
keybase config get -b mountdir. This would also mean that your interesting tor projects would still work, on systems where the user has manually disabled the root redirector as per the instructions here: https://keybase.io/docs/kbfs/understanding_kbfs#root-redirectorI'm not interested in packaging any method that requires setuid binaries, especially given I don't... really see the purpose in doing so just for a glorified symlink, and it's an officially supported configuration to disable it anyway. (@strib would be justified in pointing out that that is opt-out, whereas I have automatically opted out for all Arch users using my community package, but on the other hand... supported configuration, programs that integrate with kbfs should be expected to support this use case, and it is after all a community package, so I'm okay with making that choice on behalf of interactive use.)
So yeah, programs querying keybase really should just ask the API where the mountpoint is. For interactive use by users, the keybase-gui already lets you open files in your default file browser, but I think there is an interesting symmetry to other file storage solutions (e.g. Dropbox) in changing your mountpoint to
~/keybase.An interesting side effect of re-mounting your keybase directory to
~/keybaseis that it will automatically gain a visible udisks label, and thus, appear in the bookmarks panel of many file browsers under "Devices". Of course, using /media is also an option (or /run/media/$USER for people who in my totally biased opinion are silly for not setting UDISKS_FILESYSTEM_SHARED), which, given that the keybase directory is a FUSE mount rather than a synced normal directory, may seem like it has more symmetry, depending on the individual.