Skip to content
This repository has been archived by the owner on Feb 12, 2019. It is now read-only.

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

Open
eli-schwartz opened this issue Jul 3, 2018 · 16 comments

Comments

@eli-schwartz
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

strib commented Jul 3, 2018

@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
Copy link
Contributor Author

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
Copy link
Contributor

strib commented Jul 3, 2018

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
Copy link
Contributor Author

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
Copy link
Contributor

strib commented Jul 3, 2018

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

cc: @oconnor663 who might also be interested.

@eli-schwartz
Copy link
Contributor Author

eli-schwartz commented Jul 10, 2018

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
Copy link

theMarix commented Nov 4, 2018

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
Copy link

r3k2 commented Nov 16, 2018

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
Copy link
Contributor

strib commented Nov 16, 2018

@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
Copy link

r3k2 commented Nov 16, 2018

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

@strib
Copy link
Contributor

strib commented Nov 16, 2018

That line "fusermount: entry for /home/rek2/keybase not found in /etc/mtab" is not an error, it's just the output of an attempted unmount that isn't necessary in this case. Please don't read it as an error.

I don't see anything wrong in your logs either. What is your symptom you're having with the mountpoint at /home/rek2/keybase? What shows up in that directory?

@strib
Copy link
Contributor

strib commented Nov 16, 2018

Also, what is the output of mount?

@r3k2
Copy link

r3k2 commented Nov 16, 2018

hmm the symptons is that before I used to cd to the directory and if it was a new install or I changed I will only have to do once cd private and it will get the whole thing public, teams, private now it does not get anything empty.

NEVERMIND now is working.. O_o

[ blackarch keybase ]$ cd /home/rek2/keybase/
[ blackarch keybase ]$ ls
private  public  team

maybe I just needed to wait more or something ...
anyways thanks for your help <3

heronhaye pushed a commit that referenced this issue Jan 3, 2019
Move creation logic out of kbfsfuse/main.
See
- #1669
- #1655
heronhaye pushed a commit to keybase/client that referenced this issue Jan 7, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 7, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 7, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 7, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 7, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 8, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 8, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 8, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 8, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 9, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 9, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 9, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 10, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 10, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 11, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 14, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 14, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 16, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 17, 2019
@webknjaz
Copy link

I was having the same problem and the following solved it:

keybase config set mountdir ~/.local/share/keybase/fs
systemctl restart --user kbfs

heronhaye pushed a commit to keybase/client that referenced this issue Jan 23, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 23, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 25, 2019
heronhaye pushed a commit to keybase/client that referenced this issue Jan 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants