kbfsfuse does not know how to handle missing directories during the mount stage.

[eli-schwartz]

The default Linux mountdir is currently /run/user/$UID/keybase/kbfs, which does not exist by default and causes kbfs to fail to mount if it doesn't exist. kbfs should try to create it, rather than logging the error

2018-07-03T09:31:50.875363-04:00 ▶ [ERRO kbfs mount_interrupter.go:52] 050 Mounting the filesystem failed: stat /run/user/1001/keybase/kbfs: no such file or directory

Interestingly, it doesn't actually consider this a failure state -- kbfsfuse continues to run, rather that exiting with a non-zero return code.

[eli-schwartz]

What confuses me is, I originally tried this some time ago when the default was ~/.local/share/keybase/fs and I'm positive it behaved properly... this was back when I originally packaged kbfs for Arch Linux, without packaging the GUI.

[eli-schwartz]

Also the service file tries to call fusermount on the output of keybase config get mountdir, but that may or may not exist, and if it doesn't, kbfs doesn't try to set it.

Instead, it relies on run_keybase to do so, even though technically run_keybase has nothing to do with kbfsfuse. IMHO, kbfsfuse should not assume it is started through any one particular method, but should do the right thing no matter how the user chooses to start it.

[strib]

@eli-schwartz this is working as intended. kbfsfuse is not supposed to create any directories, esp. since the parent dirs may have to be made as root (such as /run/user/$UID). Note that it only uses /run/user/$UID if $XDG_RUNTIME_DIR is set in your environment. There's always been a requirement that the directory should be pre-made -- it doesn't have to be by run_keybase, but there has to be something to prep the local disk before calling kbfsfuse.

KBFS doesn't treat a missing dir as a failure because it is still useful for the service as a non-mounted daemon, to help power chat and git.

[eli-schwartz]

Then kbfs.service should create it, perhaps.

But I think it is reasonable to try to make the directory even so. The majority of applications that create files in e.g. $XDG_CONFIG_HOME/foo will try to create the directory if it does not exist, even though it's almost certainly a sub-subdirectory of the root-owned /home...
Currently, kbfsfuse does not "just work". It unconditionally requires wrapper scripts in order to successfully mount the fuse filesystem when $XDG_RUNTIME_DIR is set (which it generally will be). This is not good UI, and saying "but we don't expect people to start kbfsfuse except via run_keybase" is not really a good excuse. kbfs.service, if enabled, will consistently fail to mount the fuse filesystem, since it will run at logind start while run_keybase does not, and will continue to "not work" until the user interactively runs run_keybase.

...

Whether or not it should abort on failure to either create the directory or mount successfully, is a completely different issue entirely, and I acknowledge that kbfsfuse for chat/git is a valid use case the likes of which render my comment invalid.

[strib]

I understand your points, but that's not the way we've viewed it historically. We consider run_keybase to be part of our official distribution and a required part of running things. I'm happy to consider PRs that clean up those assumptions if they still work well for our distribution, but we won't be able to schedule time to work on that ourselves anytime soon.

[eli-schwartz]

Well, I am sort of interested in getting these assumptions cleaned up. :) So it is worth it to me to make sure the point has been considered.

An open issue means people are aware it's an issue, I just wanted to clarify why it should be kept open even if it's not a priority, rather than closed as NOTABUG.

Unsure whether I'll find time to learn golang and fix this myself, I guess we'll see.

Thanks for taking this into consideration anyway.

[strib]

Sure, I'm happy to leave it open, thanks for writing up all the details.

cc: @oconnor663 who might also be interested.

[eli-schwartz]

So, documentation seems to suggest the pull request I just created should work, though, disclaimer, I still don't actually really understand golang...
(Also it compiled on my machine, and created the mountdir, yay!)

The other potential improvement, I guess, is that fusermount -uz $(keybase config get mountdir | sed ...) could probably be optimized to do this via some dedicated kbfsfuse unmount command, since it doesn't fallback on $XDG_RUNTIME_DIR or anything else either. But while I can implement mkdir -p in golang after reading documentation, I don't think I could extend libfuse bindings in the same way... the systemd unit ignores errors from that anyway, though.

[theMarix]

For systems that run Systemd 235 or higher this could also be solved by adding RuntimeDirectory=keybase/kbfs to the Service section of kbfs.service. This obviously would not fix things for custom mountdirs but would improve the out-of-the-box experience.

[r3k2]

I am having problems with this as well.. default /keybase not mounting I changed it to some ramdon user not mounting, I change it again to my user and not mounting...

[ blackarch / ]$ systemctl status --user kbfs
● kbfs.service - Keybase Filesystem service
   Loaded: loaded (/usr/lib/systemd/user/kbfs.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-11-15 21:12:26 PST; 2s ago
  Process: 18055 ExecStartPre=/bin/sh -c fusermount -uz "$(keybase config get -d -b mountdir)" (code=exi>
 Main PID: 18077 (kbfsfuse)
   CGroup: /user.slice/user-1000.slice/user@1000.service/kbfs.service
           └─18077 /usr/bin/kbfsfuse -debug -log-to-file

nov 15 21:12:17 rek2system systemd[1246]: Starting Keybase Filesystem service...
nov 15 21:12:17 rek2system sh[18055]: fusermount: entry for /home/rek2/keybase not found in /etc/mtab
nov 15 21:12:26 rek2system systemd[1246]: Started Keybase Filesystem service.

why the issue after all this years now? I been using keybase with no problem until 3-4 weeks a go.

[strib]

@ReK2Fernandez we didn't change anything recently so i don't know what's going on and I don't see any fatal errors in what you posted. Please run keybase log send and post the log ID here if you need help debugging something. The rest of this issue is about the mount directory not existing before you start keybase, so depending on what you set it to, maybe that is the problem.

[r3k2]

@strib 2233fa3935fb303436a4461c <--- log sent.
also here is me showing the dir, creating the dir, again changing keybase mountdir then stop and starting the keybase service, and still says "fusermount: entry for /home/rek2/keybase not found in /etc/mtab" so fails to mount even tho of course kbfs is running but not mounting.

[ blackarch ~ ]$ pwd
/home/rek2
[ blackarch ~ ]$ mkdir keybase
[ blackarch ~ ]$ keybase config set mountdir /home/rek2/keybase
[ blackarch ~ ]$ systemctl status --user kbfs
● kbfs.service - Keybase Filesystem service
   Loaded: loaded (/usr/lib/systemd/user/kbfs.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-11-15 21:12:26 PST; 39min ago
  Process: 18055 ExecStartPre=/bin/sh -c fusermount -uz "$(keybase config get -d -b mountdir)" (code=exited, status=1/FAILURE)
 Main PID: 18077 (kbfsfuse)
   CGroup: /user.slice/user-1000.slice/user@1000.service/kbfs.service
           └─18077 /usr/bin/kbfsfuse -debug -log-to-file

nov 15 21:12:17 rek2system systemd[1246]: Starting Keybase Filesystem service...
nov 15 21:12:17 rek2system sh[18055]: fusermount: entry for /home/rek2/keybase not found in /etc/mtab
nov 15 21:12:26 rek2system systemd[1246]: Started Keybase Filesystem service.
[ blackarch ~ ]$ systemctl stop --user kbfs
[ blackarch ~ ]$ systemctl start --user kbfs
[ blackarch ~ ]$ systemctl status --user kbfs
● kbfs.service - Keybase Filesystem service
   Loaded: loaded (/usr/lib/systemd/user/kbfs.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-11-15 21:52:21 PST; 2s ago
  Process: 31664 ExecStartPre=/bin/sh -c fusermount -uz "$(keybase config get -d -b mountdir)" (code=exited, status=1/FAILURE)
 Main PID: 31681 (kbfsfuse)
   CGroup: /user.slice/user-1000.slice/user@1000.service/kbfs.service
           └─31681 /usr/bin/kbfsfuse -debug -log-to-file

nov 15 21:52:06 rek2system systemd[1246]: Starting Keybase Filesystem service...
nov 15 21:52:06 rek2system sh[31664]: fusermount: entry for /home/rek2/keybase not found in /etc/mtab
nov 15 21:52:21 rek2system systemd[1246]: Started Keybase Filesystem service.