Enable Keybase in Finder doesn't work in macOS Big Sur 11.0.1 #24366
Comments
|
Both fixes above give no result on Apple M1 MB, so problem might be somewhere else, ARM- related. |
It looks like you can now use the latest stable version of macFUSE (currently 4.0.4) |
|
I too was struggling with this for quite some time, I needed to create the symlink with the correct version 11.0.1 not 11.0 |
|
Did not worked for me with hack from @MarcoMartins86 and macFUSE 4.0.4. |
|
Same behaviour in 11.1 as noted by @kolobus. The hack from @MarcoMartins86 with macFUSE 4.0.4 doesn't work with this version either by symlinking 10.11 to 11.1. |
|
FWIW: I appreciate the work arounds, I prefer to confirm a real fix from keybase dev team. |
|
@jburnett, same here. |
|
Likewise, this is affecting my workflow significantly. I can't find a workaround that works on either 11.0.1 or 11.1 :/ |
|
This is affecting a few peoples' workflow now. We don't really want to buy more new machines to head back to the intel-CPU arch. Some official statement would be greatly appreciated, like "we are going to pay-off the macfuse guy, and a fix is coming" |
|
I'm on Big Sur 11.1 and tried the various symlinks as well, without any luck. Ended up with However, I was finally able to get it working by loading the kext via kextutil as per https://github.com/keybase/client/blob/cac9573e33f472fcb1417c1e6a899bfbba36405c/osx/Fuse/README.md and then allowing via the Security popup. Who knows what edge cases the creates but basic functionality works. |
|
To add a further complication. Has Anyone have any luck with using I'm still sorting mine out after receiving it yesterday, so there may be something obvious that I'm just missing. Executing: /usr/bin/kmutil load --bundle-path /Library/Filesystems/kbfuse.fs/Contents/Extensions/10.11/kbfuse.kext --load-style start-only
Error Domain=KMErrorDomain Code=71 "Incompatible architecture: Binary is for x86_64, but needed arch arm64e" UserInfo={NSLocalizedDescription=Incompatible architecture: Binary is for x86_64, but needed arch arm64e} |
|
@adamhsparks I have exactly same error on m1. |
|
Having the same issue on Intel MacBook running macOS 11.1 Big Sur. |
|
@adamhsparks that is a different problem and the only way to fix it is by compiling the code from scratch and maybe do some in code adjustments for that architecture, M1 is an ARM-based chip that has different opcodes (assembly code) than Intel ones. |
|
Polecam |
|
@MarcoMartins86, I understand the differences in architectures. However, it's not an entirely different problem. I still have the exact same issue. I still cannot access my files via Finder. |
FWIW, the latest stable release of macFUSE is 4.0.5, and it includes enhancements to macOS 11.x along with Apple Silicon installs. I've mentioned the same in Homebrew/homebrew-cask#96258, where I'm hoping to see |
|
I see. I was using macFUSE 4.0.4 but this issue still existed. I’ll try 4.0.5 and see if it helps.
… On 10 Jan 2021, at 01:43, Nicholaus Halecky ***@***.***> wrote:
It looks like you can now use the latest stable version of macFUSE (currently 4.0.4)
FWIW, the latest stable release of macFUSE is 4.0.5, and it includes enhancements to macOS 11.x along with Apple Silicon installs.
I've mentioned the same in Homebrew/homebrew-cask#96258, where I'm hoping to see brew updated to this version so scriptable env-building workflows can be sane again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I'm still confused about whatever macFUSE is. Does Keybase on Big Sur now require a new dependency? Are their plans to update it to "just work" as a standalone install on Big Sur?
…On 01/09, Nicholaus Halecky wrote:
> It looks like you can now use the latest stable version of macFUSE (currently 4.0.4)
FWIW, the latest stable release of [macFUSE is 4.0.5](https://github.com/osxfuse/osxfuse/releases/tag/macfuse-4.0.5), and it includes enhancements to macOS 11.x along with Apple Silicon installs.
I've mentioned the same in Homebrew/homebrew-cask#96258, where I'm hoping to see `brew` updated to this version so scriptable env-building workflows can be sane again.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#24366 (comment)
|
|
Im running Keybase Version 5.5.0-20200526170801+139bb348af with macFUSE 4.0.5 and I still have the issue. I click "Enable Keybase in Finder" and it takes a few seconds for keybase to return with no Finder integration enabled. I see that I have 2 folders created in Are there anyway to check the logs and see what exactly is broken? Update Jan 13th 2021: |
|
Hi friends. None of these are going to work on M1 chips since M1 requires ARM64 (and the emulation for x86_64 via Rosetta2 isn't applicable here I think). I would not recommend any of the symlinking hacks here unless you have a redundant backup of everything on the machine you're using this on, both stuff on Keybase and local storage too. See this comment for more information there: #17796 (comment) Unfortunately since Zoom has acquired Keybase development (that we can see) has stopped, see this link showing the commit history; guess when Zoom acquired Keybase: https://github.com/keybase/client/graphs/commit-activity Now onto my own speculation. This project is likely dead now -- they haven't addressed any meaningful issues or support tickets like these for instance -- and so I'd recommend probably looking to NextCloud or Syncthing for DYI storage. RIP. |
|
I inspired myself from @leoluz's instructions and replaced
|
|
On the flip side, there's keybase/keybase-issues#3990, which seems to mean on Big Sur that the integration cannot be disabled, which I would like to do, as I don’t use it. Any tips from y’all? |
|
5.6.2-20210202191343+d72cc00cd3 is out. Sadly no GitHub release available yet. But a screen informing about a macFuse update adding KBFS support on Big Sur + M1 macs. This probably closes this bug here along with keybase/keybase-issues#3990. Can someone confirm? |
|
Version 5.6.2 actually broke the soft link I used to fix the issue on macOS 11.2. |
|
Updated my OS and restarted, same issue |
I had this once, and for some reason rebooting once more seemed to help. Attempting to use |
|
Ah that one extra restart solved it, thanks! |
|
Same for me, As today i'm still not able to enable finder extension with keybase 5.9.0 in Monterey 12.1 .. |
|
this should work without upgrading the os. |
|
You don't need to have any workarounds. All you have to do is change startup Security Utility to set the security policy to Reduced Security and select the “Allow user management of kernel extensions from identified developers” checkbox. Please follow the below steps.
|
|
Thanks bud. I No very little about this stuff. And by the way I wouldn’t be doing this if I didnt have very good reason to do so. Thanks again On 13 Oct 2022, at 6:58 am, Dushan Wijesinghe ***@***.***> wrote:
You don't need to have any workarounds.
All you have to do is change startup Security Utility to set the security policy to Reduced Security and select the “Allow user management of kernel extensions from identified developers” checkbox.
Please follow the below steps.
Upload a sample file in your private folder in keybase app
Enable the option "Open in Finder" in the top right corner.
Then it will prompt you to enable the security Extention in the kernel "System Preference >> Security and privacy"
Once you unlock the padlock and tick the box, it will ask you to power off your mac.
Then press and hold the power button to enable security extension in the MacOs kernel
You will see the Recovery assistant window
Select your user and type your password.
Select the 2nd option in the security Extention window (Allow user management of kernel extensions from identified developers” checkbox)
Once the Extention is applied select the apple logo in the top right corner and restart.
Open keybase app, it will again bring you to System Preference >> Security and privacy
Again tick the box it's asking.
Your mac will need to restart
Finally you will see your files in /Volumes/keybase
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Since support for macOS Big Sur was allegedly dropped from the code, it's best to update the README.md to reflect the policy change. Note that I personally disagree with that approach — [since `macfuse` itself supports macOS 10.9 to 13](https://github.com/macfuse/macfuse/blob/release/README.md) — so there is no reason to restrict KBfuse to just 12 and 13, since not even Apple has discontinued Big Sur yet. Also note that the Homebrew maintainers are not aware of this discrepancy — their Keybase formula is still valid for Big Sur (I've just confirmed it!) although obviously it won't be able to install the KBfuse component. It would also be nice to provide a link to how to replace KBfuse with macfuse for those (such as myself!) who are locked by Apple into obsolescence but continue to have perfectly decent Macs :) See also keybase#24366 for a long thread about former (and current) issues with Big Sur.
|
I've still got to try out some of the above suggestions (thanks, guys, for so many helpful comments!), but I've noticed something that might be a deal breaker. I'm on a venerable MacBook Pro (Retina, 15-inch, Mid 2014), which can only run Big Sur (still supported by Apple at the time of writing), unless I go crazy and crack it with the OpenCore patcher... which, at this time, I'm as yet reluctant to do. That said, I'm using Homebrew 3.6.16-2-gf679990, which has installed keybase version 6.0.3-20221212202006+608e46df72. All worked reasonably well until very recently, when Apple decided to bump up macOS Big Sur to 11.7.3 (20G1102). I believe that the Homebrew team also updated Keybase at around the same time. The result? Well, it seems that there is no 11.X kernel extension any longer: $ ll /Library/Filesystems/kbfuse.fs/Contents/Extensions/
total 0
drwxr-xr-x 4 root wheel 128 Dec 12 20:49 ./
drwxr-xr-x 7 root wheel 224 Dec 12 20:49 ../
drwxr-xr-x 3 root wheel 96 Dec 12 20:49 12/
lrwxr-xr-x 1 root wheel 2 Dec 21 13:07 13 -> 12/(the directory for macOS 12.X, however, seems to be quite complete). And naturally enough, this means that
At first, I thought it really was a conflict between kernel extensions, but it's really just the macOS 11 kext that is missing. The logs are vast and show things such as:
|
|
@GwynethLlewelyn That seems like a different issue since your version of macOS is older.. You should open a new issue instead of replying to this one to get the best visibility. |
|
@JPry — no, actually it's always the same issue :-) It has just been reported at least 20 times (as far as I've managed to count so far) for different versions of macOS, a few of which have been marked as 'closed'. I posted on this thread because it explicitly mentioned macOS Big Sur in the title! But I believe a full answer to this should require a 'meta-thread' — since it's something that will happen over and over again. |
|
@jburnett please re-open this issue that you prematurely closed two years ago. The issue is not — I repeat, not — fixed. Just because there are some workarounds (namely, going back a few versions or compiling the Keybase Client from scratch) it doesn't mean that the mainline Keybase works. On the other hand, I found something that the Keybase team might find interesting: FUSE-T, a kext-less way to access a FUSE filesystem. The authors on their page note that it is getting incredibly harder to support kext-base solutions on macOS, and with each new release, old kexts get broken and become harder and harder to support. This is most definitely the case with Keybase! Their alternative? Add the FUSE API over a layer of Apple's NFS driver. Whatever requires FUSE to work will have a drop-in compatible library; while on the filesystem side, there is no need to use any kernel functionality at all to work with the filesystem. Instead, everything gets routed through NFS. NFS, as the authors so well point out, is blindingly fast1 — that's by design, from the 1980s, when Ethernet could only support 1 MBps and Sun workstations had to do their best with whatever they had. Of course, NFS is (unjustly) blamed for all sorts of security issues (which mostly happen because, unlike other remotely-mounted filesystems, NFS is hard to configure, and people tend to be careless about how they set up their permissions), but, in this scenario, there is no reason for worrying: everything happens locally, after all. Using FUSE over NFS is both future-proof and legacy-proof. Apple will continue to support NFS 'forever', and they already have a very optimised implementation. NFS is a pretty standard protocol and will not unexpectedly change from one day to the other (not even if Apple wants that change!). So... Keybase devs... any thoughts on this? Mind you, you're already doing your own port/fork of an old version of macFUSE anyway. FYI, I did check the I'm sure there must be a way to accomplish that! 1. In fact, I was utterly surprised when mounting remote shares on my humble Raspberry Pi, first via Samba, then via NFS. The purpose was to stream video from the Raspberry Pi to a not-very-smart TV; because the Pi doesn't have much memory, I needed to mount a share from my home NAS; by default, those shares are made via Samba/SMB but there is an option to do them via NFS as well. With Samba... well, I got hiccups all the time, and eventually the Pi would give up on the attempt, and sever the connection. Even when it worked — over Wi-Fi, mind you! — video stuttered and gasped, struggling to flow through the wireless connection. After switching to NFS, not only there was an insane speed improvement, but all the stuttering magically disappeared! Talk about UDP for tackling unpredictable wireless transmissions... it actually deals with them so much better than Samba's TCP connections! |
|
Yeah this ticket kind of stinks. It's a big problem and ignored. I get it, Keybase FUSE isn't a priority. It still hurts a lot of people's sore little piddys. At least leave it open so people can figure out workarounds without having to look so hard for it. |
Exactly! Every other week or so I take a look at this, and it seems to me that there is no easy way around it. The best that one can hope to do is, well, clone this repository, add some tweaks to use the above-mentioned kext-less FUSE-T solution (it's sooooooo easy to use...), grab XCode, figure out Keybase's signing key, change, oh, perhaps two lines of code, get rid of the whole The only reason for that is to avoid the Keybase GUI installer to automatically install I might give the Go part a try (because, well, the GUI/Installer bits require XCode to be installed — no thanks!). With a little bit of luck, I may be able to get at least the redirector launching without complaining, and with the redirector happy, Finder should be happy too. The Keybase app by itself may be hopelessly confused after that, but who cares... let it remain confused :-) — so long as Finder is not confused and works, I don't care! |
|
bumps @jburnett to reopen this issue |
and others
After upgrading to macOS Big Sur 11.0.1, Keybase client is not working with Finder, and enabling does not work. In main app, select Files tab; "Enable Keybase in Finder?" should show at the top. Click to accept "I understand that closed source...", and push "Yes, enable" button.
Result: After working for a few seconds, nothing changes and "Yes, enable" button is enabled again. Attempting to navigate to any keybase managed files gives
permission denied.Keybase client for macOS 5.5.0-20200526170801+139bb348af (installed via brew). kbfuse version is 10.11 with symlinks for higher versions.
The text was updated successfully, but these errors were encountered: