Client: KBFS: Cannot access /keybase

Created on 21 Sep 2019  路  7Comments  路  Source: keybase/client

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

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-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.

All 7 comments

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:

  • Arch Linux has the default mount at /run/user/1000 and should be changed using keybase config set mountdir if desired
  • Programs needing to access keybase should do so using APIs provided by the keybase binary when possible. e.g. keybase config get -b mountdir to get location of kbfs mount
  • Re-mounting keybase to ~/keybase can provide a more consistent experience with other file storage programs

Thank You
@strib
and
@eli-schwartz
for the clarification and direction. Much Appreciated!

Great! Thanks for the summary.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pipermerriam picture pipermerriam  路  4Comments

martindevans picture martindevans  路  4Comments

hkjels picture hkjels  路  4Comments

nikolayhg picture nikolayhg  路  3Comments

iqballher picture iqballher  路  3Comments