Open averagejoey2000 opened 7 years ago
Are you running a custom kernel without the FUSE module enabled? And is /keybase empty (it needs to be)?
I am not using a custom kernel on this machine. /keybase must be empty because /keybase does not exist. do I need to create /keybase? If so, with what permissions? Do I need to enable a systemd service to allow kbfs tto run at startup for the fuse mount to function?
I see two errors in your log. From November 28:
2 2016-11-28T19:20:55.548664 ▶ [DEBU kbfs main.go:108] 005 Mounting: /keybase
3 2016/11/28 19:20:55 mount helper error: fusermount: mountpoint is not empty
4 2016/11/28 19:20:55 mount helper error: fusermount: if you are sure this is safe, use the 'nonempty' mount option
From December 15:
27 2016-12-15T11:49:18.544404 ▶ [DEBU kbfs main.go:111] 005 Mounting: /keybase
28 2016-12-15T11:49:18.547164 ▶ [DEBU keybase login_state.go:920] 006 + LoginState: Running request loop
29 2016/12/15 11:49:18 mount helper error: fusermount: fuse device not found, try 'modprobe fuse' first
On november 28th, I attempted manual creation of the keybase folders, hoping to "force" keybase to recognize /keybase. Today (dec15), I eliminated /keybase before mounting. I ran modprobe fuse with output
modprobe: FATAL: Module fuse not found in directory /lib/modules/4.8.11-1-ARCH
I already have the most up-to-date version of fuse installed. Do I need to reboot for the hooks to work?
I also have the latest vanilla kernel from archlinux core.
It looks like your kernel is misinstalled somehow, since it should contain the fuse module and that modprobe line should work.
Agreed with @cjb, we assume that FUSE is installed and loaded on all the distros we support, and the run_keybase
script doesn't do anything to detect when that's not the case. Apologies for not reporting errors from that script more cleanly though. (It starts services in the background, and sends their output to the logs, so it's a little tricky to collect errors at that point.)
Is it possible you upgraded the kernel on your machine without restarting it? Whenever I have problems with "kernel stuff" I always suspect that first.
After reboot I get 7a240f88a99a2ffe62762e1c It says that the /keybase mountpoint does not exist. Do I need to manually make the directory, and, if so, with what permissions?
modprobe fuse now returns successful
Hmm. Take a look at /opt/keybase/post_install.sh
. That should've been installed as part of the keybase-bin
package, and it should've been run by the post-install hooks. It creates the directory like this:
if mkdir /keybase &>/dev/null ; then
chmod 777 /keybase
fi
Which is to say "try to create /keybase
, and if we just created it successfully, change its permissions to 777
." So you could just run the same chmod
command now. But the more concerning part for me is why that didn't happen as part of installing the package. Is there any chance you deleted the folder somehow after installing? If you don't have any theories, I'm curious what happens if you reinstall keybase-bin
? Any interesting output from that?
open sudo mkdir /keybase, run_keybase returns error (user does not have permission) bafflingly, attempting sudo run_keybase causes such an enormous problem that sudo ls /keybase freezes my shell. I'm manually stopping the keybase programs, completely deleting /keybase, and awaiting further orders.
Yeah sudo run_keybase
is going to cause terrible problems. You're going to have a FUSE mount for root, and then try to read it as your regular user. That said I'm afraid I didn't understand the first command you said you ran. Could you write out each command and its output for me on separate lines, like this:
$ echo command one
command one
$ echo command two
command two
Also, could you please give me the output of mount
? Finally, have you tried restarting your machine yet?
I tried restarting my machine. I was able to make it work after I manually created the keybase folder with the 777 permission.
But a new issue arose when trying to install keybase for another user. I share my Linux installation with my brother, and we dial into via SSH. We wanted to try to have both of us signed into keybase at the same time, and it worked for about 90 seconds. Now, neither one of us has access to our own files, and root can not access, delete, or unmount any part of /keybase.
We don't have much support for multiple users accessing /keybase
right now. I'm not sure how the 90 seconds effect came about, but in general I think your issues are expected when one user accesses another user's FUSE mount.
I think it's expected that root shouldn't be able to read another user's files in /keybase
. (Other than of course by running commands as that user.) I'm surprised that sudo umount /keybase
doesn't work for you though. Does fusermount -u /keybase
also not work?
If you want to do some custom scripting, it's possible for you both to use Keybase as long as you don't use the same mount point. If you take a look at the /usr/bin/run_keybase
script, you'll see two places where we use the path /keybase
, once as an argument to fusermount -u
and once as an argument to kbfsfuse
. If you copy that script and change both of those paths to something like $HOME/keybase
, and run your custom script for startup instead of the global one, you should both be able to run at the same time. (If you're using a desktop environment that runs autostart apps, you'll need to disable ~/.config/autostart/keybase_autostart.desktop
as described in that file, and you'll probably also need to mkdir
the mount point you choose.)
Apologies for not having an easy environment variable you can set to make this happen. I'll put up a PR for doing that.
I installed keybase for arch linux using the recommended yaourt instructions, but the KBFS was not created nor mounted. ls shows now keybase in / . I can't access keybase encrypted things or keybase public things. I tried reinstalling and executing run_keybase again, but even though the ANSI squirrel says "mounting /keybase" the opposite has happened.
my log id: 87ab8c64e174c58aeb11d81c