[Bug]: Unable to sync right after logon in Gnome

[bvn13]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Fedora 35/36 with Gnome
Nextcloud Desktop Sync 3.4.4

Nextcloud client is adjusted to sync for last month already. I don't reboot my laptop since that. Nextcloud is in startup applications list in Gnome Tweaks Tool.
Today I revealed the following.
When I logon into Gnome session, Nextcloud client starts very quickly. But it is not synced. In Settings on first tab there is no local path to sync.
But all become OK right after I quit and start Nextcloud client again.

Steps to reproduce

see above

Expected behavior

see above

Which files are affected by this bug

settings

Operating system

Linux

Which version of the operating system you are running.

Fedora 36

Package

Distro package manager

Nextcloud Server version

24.0.2

Nextcloud Desktop Client version

3.4.4

Is this bug present after an update or on a fresh install?

Fresh desktop client install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No response

Additional info

Nextcloud Desktop Client
Version 3.4.4 (KDE). For more information please click here.
Using virtual files plugin: off

org.kde.Platform-5.18.7-200.fc36.x86_64

[camilasan]

Make sure you are running the latest recommended version of the desktop client. The latest version can be seen by checking https://nextcloud.com/install/#install-clients.

Could you please try 3.5.1 or 3.5.1 if available and report back? If the problem persists, we will need your client and server logs.

[claucambra]

Could you also check if the GNOME Keyring is unlocked when the client begins?

Without access to the keyring the client cannot provide the server with your account passwords, and thus it needs to wait for authorisation

[bvn13]

The latest version is not working in my case unfortunately, so I'll check it later separately.

How to check GNOME Keyring is unlocked? I don't enter any password in order GNOME Keyring to be unlocked.

[claucambra]

The latest version is not working in my case unfortunately, so I'll check it later separately.

Is this the AppImage version? If not, please try that :)

How to check GNOME Keyring is unlocked? I don't enter any password in order GNOME Keyring to be unlocked.

If your distribution has correctly configured it then the keyring should be unlocked on boot, but in some cases you are prompted for a password shortly after boot to provide a password.

You can try to unlock the keyring manually by typing into the terminal: gnome-keyring-daemon --unlock <your desktop password>

[bvn13]

gnome-keyring-daemon --unlock does not eat my password and does not prompt it if it is absent. I am unable to check if it unlocked.

[GuillaumeAmat]

For the record, I've got the same behavior for a few weeks. Using the v3.5.2 via Flathub.

[claucambra]

Could you try the official AppImage version of the client and check if this still happens?

[GuillaumeAmat]

Could you try the official AppImage version of the client and check if this still happens?

I'll try to do that in the coming days 👌

This morning (as almost every day), after entering my session (with credentials), Nextcloud desktop didn't sync.

I naively tried to run gnome-keyring-daemon --unlock, but it outputs nothing and never ends.

Quitting and relaunching Nextcloud "fixed" it again.

[GuillaumeAmat]

Could you try the official AppImage version of the client and check if this still happens?

Hey there, I'm trying the official AppImage for weeks now, and it always successfully connect to the server when I log in to my OS session 🎉

I'm a bit confused that neither the RPM nor the Flatpak versions are launched correctly, even though they seem to use the launch mechanism (e.g.: OS "hook" at login time) 🤔

[claucambra]

Could you try the official AppImage version of the client and check if this still happens?

Hey there, I'm trying the official AppImage for weeks now, and it always successfully connect to the server when I log in to my OS session 🎉

I'm a bit confused that neither the RPM nor the Flatpak versions are launched correctly, even though they seem to use the launch mechanism (e.g.: OS "hook" at login time) 🤔

Sorry, forgot to mention -- there was a recent fix regarding the gnome-keyring, I'm glad the issue is resolved! :)

[GuillaumeAmat]

@claucambra Reading your comment, I switched back to the Flatpak version, which is also on 3.6.0, but the issue remains.

Has the gnome-keyring fix been released already? In the 3.6.0? 🤔

[claucambra]

The fix is relevant to our AppImage generation scripts: #4830

That means no changes in the Flatpak if the packagers have not changed the way they are bundling the client

[bvn13]

Version 3.6.0 from FlatPak has no such error.
It starts and connects as expected.

[jbingram]

No I am on 3.6 and I have the same problem here. It's been more than a year that the succession flatpak versions all need to be opened and closed as many times as needed, in order to start logging in (offline -> online status), change color, and synchronize.
The fedora rpm version or Arch version do not have this issue.
Is it a question of flatpak rights? I don't know. I tried to play with them on flatseal, but I am scarred of doing something wrong.
In any case this bug has been around for far far too long and it is really starting to be frustrating to waste sometimes 15 mn after booting the computer doing only: click nextcloud icon (not synchronising) -> killing the app with gnome-Usage -> click nextcloud icon -> kill the app in gnome-Usage -> click on nextcloud icon -> etc ...) . Would be great if this bug was finally fixed. Thanks and keep up the good work!