Syncing issues

[Nordanis]

Hey,

I have difficulty turning on syncing as clicking on the accounts icon doesn't do anything and clicking on the "Turn on Settings Sync" button provides the following error message:

Error while turning on Settings Sync. No authentication providers are available.

This might be connected to a similar issue #144471 discussed in the main repo of VS Code. VS Code seems to be requiring gnome-keyring, libsecret and libgnome-keyring (maybe just on of those).

Is this a permission issue that can be solved via Flatseal or by adding a path?

Thanks for answering,

Nordanis

[thorrrr]

I have same issue logged in with my Githib credentials

[2022-10-07 09:13:31.018] [settingssync] [info] Using settings sync service https://vscode-sync.trafficmanager.net/
[2022-10-07 09:13:31.018] [settingssync] [info] Auto Sync is disabled.
[2022-10-07 09:15:45.530] [settingssync] [info] Did reset the local sync state.
[2022-10-07 09:15:45.561] [settingssync] [info] Settings: Not synced yet. Last sync resource does not exist.
[2022-10-07 09:15:45.660] [settingssync] [info] Settings: Not synced yet. Last sync resource does not exist.
[2022-10-07 09:15:45.826] [settingssync] [info] Keybindings: Not synced yet. Last sync resource does not exist.
[2022-10-07 09:17:33.963] [settingssync] [info] Request failed https://vscode-sync.trafficmanager.net/v1/manifest
[2022-10-07 09:19:45.867] [settingssync] [info] Request failed https://vscode-sync.trafficmanager.net/v1/resource/keybindings/latest
[2022-10-07 09:19:45.868] [settingssync] [error] RequestFailed (UserDataSyncError) syncResource:unknown operationId:unknown: Connection refused for the request 'https://vscode-sync.trafficmanager.net/v1/resource/keybindings/latest'.
at R.request (vscode-file://vscode-app/app/extra/vscode/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js:83:146108)
at async R.readResource (vscode-file://vscode-app/app/extra/vscode/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js:83:142525)
at async f.getRemoteUserData (vscode-file://vscode-app/app/extra/vscode/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js:83:31520)
at async f._sync (vscode-file://vscode-app/app/extra/vscode/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js:83:21873)
at async t.getPreviews (vscode-file://vscode-app/app/extra/vscode/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js:83:132467)
[2022-10-07 09:19:45.973] [settingssync] [info] Settings: Stopped synchronizing settings.
[2022-10-07 09:19:45.993] [settingssync] [info] Did reset the local sync state.

[kevindurb]

Same here, on a fresh install I can’t click the account button

[thorrrr]

Same issue no syncing

[Binly42]

might try #195 (comment)

[exil0867]

Can confirm.

[exil0867]

Switching to the official release fixed the issue.

FYI i'm on Fedora 38 (minimal setup) with KDE Plasma as DE.

[exil0867]

I could only reproduce the issue on Fedora 38.

[exil0867]

The issue is also reproducible on the immutable versions of Fedora (Silverblue and Kinoite).

[mlawson-tt]

This issue (at least for me) appears to have something to do with kwallet in a fresh install of Fedora Kinoite 38. I couldn't enable settings sync due to what appears to be the same issue as above (the Settings Sync option wouldn't even show up when clicking on the Accounts button), but going into System Settings -> KDE Wallet, unchecking the Enable the KDE wallet subsystem button, and then rebooting seems to have completely fixed the problem.

I don't use kwallet anyway, so this workaround works totally fine for me, but it may a bit problematic for those that do use kwallet. Maybe kwallet needs some additional permissions through flatpak/flatseal that gnome-keyring doesn't or something?

[dzavodnikov]

Same on Linux Mint 21.2 Cinnamon

[mtalexan]

By following the recommendations here https://code.visualstudio.com/docs/editor/settings-sync#_troubleshooting-keychain-issues I was able to determine that it couldn't connect to the kwallet DBUS endpoint.
You have to add org.kde.kwalletd5 to the Session Bus Talks of Flatseal (or I think --talk=org.kde.kwalletd5 on the CLI?).

That said, I still can't get it to work. The logs now say it's able to correctly detect and connect to the KWallet, but it says it "can't detect an authentication service" the second time it checks, after it gets the GitHub token back (it checks before trying for the token and succeeds).

The official Microsoft site suggest trying to force the password storage to use a couple gnome variants, one of which supposedly forces it to use the org.freedesktop.secretstore DBUS endpoint, but that exhibits the identical problem.

My best guess is that KWallet is refusing the storage request from VSCode without ever prompting the user or registering that the connection was even made, but does successfully reply the "do you exist" check VSCode does as the first connection.

[mtalexan]

I solved it!

---

TL;DR

The Session Dbus "Talk" permissions you need to add are"

• org.kde.kwalletd5
• org.kde.KWallet.*
  (I think on the CLI this looks like --talk="org.kde.kwalletd5" --talk="org.kde.KWallet.*")

You also must manually disable keytar in the VSCode settings.

In VSCode, open the command-pallet and go to Preferences: Configure Runtime Arguments. In the JSON editor that opens, add a comma to the last existing item, then add the following after it:

"disable-keytar": true

(you can test this change without making it permanet by setting --disable-keytar=true on the CLI)

When you start Settings Sync and pick GitHub, it will open your browser to authenticate. That will then prompt you to pick the VSCode flatpak as the program to open the vscode:// link in. You won't see any response to this except maybe the window being raised.

VSCode will still be sitting waiting for the GitHub token. Just wait a few minutes until it times out. The notification will then ask if you want "to use a local server". I know it's weird and wrong, but pick "Yes". It will actually receive and process the GitHub token at this point.

---

How the Sausage Was Made:

Apparently Microsoft's documentation is incorrect/out-of-date on a number of key points:

1. --password-store="gnome-libsecret" does not implement the secret store backend (org.freedesktop.secretstore)
2. --password-store="kwallet5" currently does the same thing internally as --password-store="kwallet", but it states a different name first
3. keytar is not disabled, even though it's been "replaced"

When debugging using the recommended command-line options, you can see that it errors out trying to connect to certain DBUS endpoints. They're listed as org.kde.KWallet.enable and org.kde.KWallet.close. If you use Flatseal (a GUI for Flatpak permissions management), and skim some other Flatpaks that use KWallet, like Brave Browser, you see that they all include a Session DBus permission for org.kde.kwalletd5 as well. So those two DBUS permissions need to be added manually.

Also when skimming the logs and looking for the word "key", I noticed that disable-keytar was set to false. That's exactly the opposite of what the Microsoft documentation said, so I tried disabling it. Low and behold it seamlessly got to the GitHub authentication step.

I'd been banging my head on why the GitHub token was generated by my browser and sent back to VSCode thru a vscode:// URI succesfully, but VSCode just kept spinning saying it was waiting for the GitHub response. I went digging online while it kept running and didn't come back to it for a while. When I did come back to it, there was a different notification asking if I wanted to "use a local server" instead, something I'd declined before. I took a chance just to see what would get screwed up and picked "yes" this time. It immediately started syncing my settings from my GitHub account (!?).

[aasseman]

Thanks @mtalexan !
In my case just adding these to the D-Bus permissions fixed it:

• org.kde.kwalletd5
• org.kde.KWallet.*

[mtalexan]

Thanks @mtalexan ! In my case just adding these to the D-Bus permissions fixed it:

* org.kde.kwalletd5

* org.kde.KWallet.*

The keytar part of the fix was actually manual fixing of a VSCode bug, so it sounds like they've finally fixed it.