Installation required `sudo` on macOS Catalina, and still something is not right

On my MacBookPro I first tried brew install syncthing; brew install syncthing Then I RTFM and noticed I was missing cask. So:

brew services stop syncthing
brew uninstall syncthing
brew cask install syncthing

But now {tray icon (red)} -> open wouldn’t open the in-browser settings pane. No luck rebooting. So I remove the app, rm -rf /Applications/ ~/Library/Application\ Support/Syncthing Now I try

brew cask fetch syncthing
sudo open ~/Library/Caches/Homebrew/downloads/7ec71af62abb4c691f4e27be32cf5f1511c9372ce98d5a542b7a5236a7727c9d--Syncthing-1.0.0-2.dmg

… and drag-drop the .app in to /Applications. Now it works. Now {tray icon (green)} -> open does open the in-browser settings pane. I follow the same procedure to install it on my MacBookAir. I allow the update on both machines. I even successfully share a couple of folders with my MacBookAir.

The next day though, something’s not right: i.e. it says it is Running (offline). Yesterday the light was green. Today it is yellow. And there is a (!) badge over the trayicon.

It does still seem to be sharing files; I dropped one in to the MacBookAir and pulled it off the MacBookPro.

Can anyone recommend a path forwards?

Check the web ui

Everything in there looks fine. But I don’t know what to look for.

Listeners is 3/3, which seems strange, as I only ever sync’d 2 machines. Which surely should mean there is 1 listener other than this machine?

Discovery is 4/5 which again I don’t understand.

Activity Monitor shows SyncThing app with 2 daemons. Both are child processes and terminate when I terminate the app. So that all looks okay.

One strange behaviour: {tray icon} -> Folders doesn’t show any contents, even though {tray icon} -> Open -> {webUI} shows 2 folders.

That sounds like Syncthing is running just fine then and it’s a problem with the macos integration (ping @jerryjacobs).

That’s got nothing to do with synced remote devices, that signifies how many different types of listeners (tcp, relay, quic) are up and listening.

As it seems like it this is a SyncThing-macOS issue not a SyncThing issue, I’ve opened this GitHub issue:

For the wrapper you should click the menubar icon -> Preferences -> Click the test button to check if the API is working. Or else you need to copy the API key from the web interface Actions -> Settings -> API key.


Brilliant! My API keys were inconsistent. Now I’ve now got the green light!

I wonder what went wrong. Could it have been the fact that I previously installed/removed SyncThing?

Also, could the software itself enforce consistency between API-key in WebGUI-Settings and in the Prefs menu-item? This looks like a Gotcha that could catch a lot of people, and it is strange for software to have 2 API-key locations…

If not, maybe a doc-note in could shake them loose?

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.