Suggestion: Allow moving location of KBFS

[chucksense]

The KBFS appears to be symlinked as a network drive on the desktop. I'd rather have control where it lives like with Dropbox / Google Drive.

[strib]

Hi @chucksense -- it's not really a symlink, it's a mountpoint. So unlike Dropbox/GDrive, you can't mount it at an existing folder on your hard drive, it has to be a new, empty directory. We nudge everyone towards using /keybase because that allows for global paths -- i.e., if I tell you to look at a file at /keybase/public/strib/foo, that points to the same place on every (non-Windows) computer globally.

That said, we do have options in the code for mounting it elsewhere, we just don't expose it yet. If you run the kbfsfuse binary yourself, you can set the mountpoint as an argument on the command line. Perhaps in future releases we will expose this as a config option via the GUI if there is enough demand.

[chucksense]

If it's mounted at /keybase/, why is it showing at ~/Desktop/keybase/ and is there a way to remove that?

[gabriel]

Are you sure that's not the dmg mount from the Keybase.dmg? What's in there when you ls (vs /keybase). Otherwise it might be a bug.

[chucksense]

It doesn't show up via Terminal. It's just sitting on the Desktop as a "Network" drive. I don't want it on my Desktop, but I also don't want to disable true mounted "Network Drives" in Finder.

[gabriel]

Ah right, yeah ok, I see... OS X is putting links to all mounted "volumes" (including keybase) on the desktop. I think this might be an OS (or Fuse) thing (and something we might be able to disable), but I'll have to investigate a little bit more. Thanks for your feedback.

[chucksense]

Thanks! FWIW, you could accomplish a similar "global path mechanism" on *nix systems by living under the home folder: ~/keybase/public/strib/foo and be a bit more compliant to how these systems are typically organized. Just my $0.02 and I should point out I only use bash shells, so perhaps this mechanism is different elsewhere...?

[malgorithms]

Sadly, I'm not sure this is entirely universal inside the programs people use on a a unix system...we talked about this a lot internally.

I was building something from source and did ./configure --prefix=~/somedir before building something, and it actually made a ~ directory in the folder I was in. I had switch it to --prefix=/home/chris/somedir .

I caught myself about 1 second before hitting enter on rm -rf ~ trying to remove the directory.

Also, in Node this wouldn't work, in either linux or OSX: fs.readdir '~/keybase/public/chris', cb

Cronjobs are annoying, too...

I think there are a lot of usability reasons why we want a keybase directory to be universally the same (windows excepted). Other file services such as Dropbox or GDrive or SkyDrive don't have universal folder paths inside their service, so there's no advantage to their doing it this way. But a path inside keybase means the same thing to everyone in the world, so it's nice to have easy to remember global paths.

@gabriel - why don't I see that volume on my OSX desktop? @chucksense - is that the actual keybase mount or the mounting of the dmg for the installer? OSX does confuse me sometimes.

[gabriel]

@malgorithms yeah I don't see it either on my computer, but I remember this coming up in the past... I need to dig that up issue/email.

And yeah it's not the dmg mount, that was my first thought as well, since you can see the Fuse icon for keybase mount (and other mounts on the desktop too)

[cjb]

Yeah, the explanation for @malgorithms' experiences is that both ~ and $HOME are expanded by shells, not by other binaries. Some other binaries have noticed that it's a useful expansion and do it, but many don't.

So we wouldn't have a safe way of referring to global Keybase paths that would work outside of shells.

[chucksense]

Makes sense, thank you!

As for the network mount, do you have "Connected Servers" checked under your Finder preferences?

[gabriel]

Ah ok.. I can repro.. it's a Finder preference, if you enable Show these items on the Desktop:, Connected servers:

So this doesn't actually mean that keybase is mounted in ~/Desktop, it's actually mounted at /keybase (if you ls /keybase in Terminal you should see files) but the Finder decides to show it on the Desktop based on this Finder preference.

[gabriel]

Oh oops, didn't read your previous message before replying with the above.... what you said :)

[turtlegraphics]

I had the same issue as chuck, and it is true that I can set the finder (as above) to not show the keybase folder on the desktop. However, that's a global setting.

Why is keybase making this connected server in the first place, and can I turn it off entirely?

[gabriel]

There is some background on this here: https://github.com/osxfuse/osxfuse/wiki/FAQ#42-i-mounted-a-fuse-for-os-x-volume-but-i-do-not-see-a-volume-icon-on-the-desktop-why

Unfortunately, I don't think we can control whether or not to show the icon here if Connected servers option is enabled. (We can't opt-out of this.)

[gabriel]

Keeping it open, cause maybe it might be possible in the future, and would be nice feature to have.

[turtlegraphics]

Thanks, Gabriel. Here's my take on this issue: I have installed Keybase on my Mac. I now have a folder on my Desktop, and even ejecting it (with right-click) won't kill it - it just pops up again seconds later. I'm not willing to change the Finder setting, because often I mount things and want them to appear on the Desktop, while mounted. Keybase hasn't earned a spot on my Desktop yet - I like the identity management aspect, but don't feel a need for the file system. And if I do, I'd prefer to turn it on and off as needed.

So, this folder cannot stay. The Finder setting isn't a solution. Keybase, AFAIK, provides no way to turn off the filesystem and/or put this folder somewhere else. The only way to remove the folder from the Desktop is to remove the software.

From my POV, this is a bug, and a rather serious one. Not so much that creating a Fuse file system makes a desktop icon, but that I can't use Keybase without having a file system created. Is there some overarching security reason why the file system cannot be decoupled from the identity management features?

[gabriel]

Currently it's an all or nothing thing, but you can run:

keybase uninstall --components=kbfs

to remove the filesystem component. You'll have to do this after Keybase.app starts up though (because it will re-install it).

AFAIK, there is no way to hide just this mount. I wonder if you could move the icon off screen or some other hack so it's out of sight?

[turtlegraphics]

This is a nice solution for me. I think as a UI issue, though, it would make more sense if the KBFS system wasn't always on, or at least if it defaulted to not being mounted, with a button to turn it on. But now we're in the realm of opinions rather than problems. Thanks!

[chucksense]

Gabriel, thank you for this workaround. This helps a great deal!

[gabriel]

Yeah I think currently we made it "all on or all off" just cause its a little easier to support if everyone is running the same thing. (But in the future we'll want to support custom installs too.)

[trainmeditations]

I just opened a separate issue as I thought this one was primarily focused on Mac OSX but I'll bring over what I said there.

I realise this issue has been discussed before but I am opposed to having kbfs mounted in /keybase and I really think there will be a lot of pushback against it with wider adoption also.

There's two main issues here:

1. it pollutes the / location and is mounting on all *nix systems in a non standard location
2. it's not compatible with multiple users on the same system

In regards to the first point, the argument is to have a standard way to address a file across all systems. This already doesn't work in Windows anyway, and any scripts that want to access a file from keybase are likely to be different in other ways across Linux or Mac OSX implementations anyway, so having a separate path at access them from for each system doesn't seem like it would be a huge issue.

A standard environment variable pointing to the kbfs root could also be implemented, exported by the run_keybase script when the user logs in.

As for the second point, the issue could be avoided by having kbfs mounted in a user specific location (such as under $XDG_RUNTIME_DIR on Linux systems) and have this environment variable point there.

For an even more cross platform solution that would work even in windows, why not use a keybase URI scheme and have the keybase service set up as the URL handler. keybase://public/userid could point to a users public folder. Most Linux DE's and Windows have ways of registering global URI handlers, this seems to suggest Mac OSX does too (I'm not familiar with it myself) https://superuser.com/questions/548119/how-do-i-configure-custom-url-handlers-on-os-x

A combination of an environment variable and a URL handler seems like it would provide as much support (if not more because it would work in Windows as well) rather than just mounting in /keybase

[trainmeditations]

Also, in terms of CLI tools, if you didn't want to use an environment variable, there could be a keybase command that dumps the contents of any file, similar to using curl for http, so if you wanted to extract the contents of a tar file you could run

kbfs keybase://public/userid/file.tar | tar -xv

[strib]

I just opened a separate issue as I thought this one was primarily focused on Mac OSX but I'll bring over what I said there.

Thanks! I edited the subject of this issue to remove macOS. That said, in general the restriction is most likely to bother people there, since I assume most Linux users can easily write their own scripts to move the mountpoint if they really want to. We can't stop you!

it's not compatible with multiple users on the same system

That's true for now, but we will eventually support multi-user systems with a redirector that lives at /keybase and points users towards their own private mount. We do not currently support multi-user systems for this reason.

In regards to the first point, the argument is to have a standard way to address a file across all systems. This already doesn't work in Windows anyway, and any scripts that want to access a file from keybase are likely to be different in other ways across Linux or Mac OSX implementations anyway, so having a separate path at access them from for each system doesn't seem like it would be a huge issue.

Cross-OS compatibility is not the main argument, since as you said this doesn't work for Windows. The most compelling use case is two people both running macOS (the vast majority of our users), chatting and passing full file paths back and forth to each other. They need to be able to paste those paths into any application they have running, and it should work seamlessly. We can't impose anything about special keybase commands or environment variable setup to make application access work. Also see @malgorithms's post above.

why not use a keybase URI scheme and have the keybase service set up as the URL handler.

We can certainly have a URI scheme eventually as an add-on, but we will always need a pure file-based way. Most shells don't handle file URIs natively as far as I know.

[trainmeditations]

Reading through the history on this issue, I think exposing the mount point as an option in the gui should definitely happen as soon as possible, and preferably asking the user to specify a path on setting up their account would be great. If this were still to default to /keybase I wouldn't be too bothered.

Handling URLs in shells is usually done by another utility, such as curl for http, so providing a kbfs tool or keybase url command or something which dumps the file would be a reasonable way of handling URLs on the command line.

[songgao]

http(s):// is a much more universal URL scheme compared to the proposed keybase://. Most distributions ship with curl or wget. Many application understand HTTP. KBFS on the other hand is not. Sure there could be a script or binary that dumps content in shell, but what about other applications? You can open a http address from VLC for example, and you can open a file-based path in VLC, but to make it support keybase:// there likely needs to be plugins. Same applies to MS Excel, Photoshop, etc.. I agree URL scheme is nice to have, but file-based paths are a good fallback that a lot of applications already understands.

[trainmeditations]

VLC can read a video stream from standard input, so a dump tool will work there. As for desktop applications, they certainly should have a file somewhere on the system to open, but I don't think having that file path be universal is necessary. You're more likely to navigate to the folder to open it anyway. Not to mention if your friend gives you a link for Linux or Mac OSX it's not going to work in windows anyway.

I'm not opposed to having a file mount, I just don't think the arguments for having the standard mount be under /keybase are very strong. Having it be configurable at least is absolutely necessary.

[gabriel]

You can register custom url schemes in macOS (to be used by certain apps): https://superuser.com/questions/548119/how-do-i-configure-custom-url-handlers-on-os-x

If you did open keybase://blah it could be sent to Keybase.app which could then open the file (or open in Finder).

It is nice though to have /keybase (or file:///keybase) resolve the same for everyone without needing a mapping though.

[gdm85]

(I am a bit puzzled that the title of this issue says "Suggestion", I would consider this a serious bug as it was reported in https://github.com/keybase/client/issues/4739)

Since nobody mentioned it to so far (only in #2605), here is the Filesystem Hierarchy Standard: http://refspecs.linuxfoundation.org/fhs.shtml (you might want to refer to v2.3 if not v3.0 already).

[milouse]

There is another big issues not mentionned by @trainmeditations : I use a very tiny root partition, because that's not the place to store large volume of personal data. We've got home for that. if I plan to use the totality of my 10Gb free, or if I try to use more of them, it will fill my root partition, leading to unwanted problems.

IMHO, a more robust/stable/previsible place on linux should be under /home (maybe a dedicated user /home/keybase, with per-user subdirectory for when you'll support multi-user?) or /var which are very often on different and larger file systems than /.

By the way, as it really bother me, I've quickly written a patch to relocate the keybase folder, you'll find it with explanation on how to use it in my keybase public folder ;).

[EDIT] add a link to my patch

[oconnor663]

@milouse to clarify, the /keybase folder doesn't take up any space on the / partition. It's only used as a mountpoint for our FUSE filesystem. When the kbfsfuse process backing that mount needs to cache things on disk, it uses ~/.cache or ~/Library/Caches or similar, depending on the OS.

[dvhwgumby]

I see there has been no movement on this topic since the end of 2017. It's a complete pain in the neck to have the keybase FS mounted in the root; I'm not sure how that will work on multiuser machines anyway. And in Mac OS 10.15 (coming out in a couple of months) I believe you won't be able to create the mount point.

I have all my "cloud" filesystems available in a specific location so they don't clutter my home directory, root, etc; Keybase should respect that as well.

[strib]

These days, the /keybase mountpoint is actually a redirection process that redirects the user to a user-specific mountpoint under Volumes. You can turn off the redirector by following the instructions under "Root redirector" here: https://keybase.io/docs/kbfs/understanding_kbfs.

You can change the location of the per-user mountpoint with keybase config set mountdir <dir> and the restarting Keybase.