desktop
desktop copied to clipboard
nextcloud
Client does not recover from standby
I am using the 3.3.6 client (x64 AppImage) on Ubuntu 21.10. The synchronisation does not recover after standby. Icon is grey.
@solaristhesun Could you share logs that are created at the moment when the problem happens after standby?
These are the logs after resuming from standby:
2021-12-16 16:43:53:746 [ info nextcloud.sync.accessmanager ]: 6 "PROPFIND" "https://next.domainremoved.com/remote.php/dav/files/sts/" has X-Request-ID "10df4d5a-6979-45cc-a
heler.com; path=/"), QNetworkCookie("ocnb1ijzw9hg=q54f7k6ndu62a03k274ap1jqlc; secure; HttpOnly; domain=next.domainremoved.com; path=/"))
2021-12-16 16:43:53:746 [ info nextcloud.sync.networkjob ]: OCC::PropfindJob created for "https://next.domainremoved.com" + "/" "OCC::ConnectionValidator"
2021-12-16 16:44:02:708 [ warning nextcloud.gui.account.state ]: ConnectionValidator already running, ignoring "[email protected]"
2021-12-16 16:44:22:700 [ info nextcloud.gui.folder.manager ]: Etag poll timer timeout
2021-12-16 16:44:22:700 [ info nextcloud.gui.folder.manager ]: Folders to sync: 1
2021-12-16 16:44:22:700 [ info nextcloud.gui.folder.manager ]: Number of folders that don't use push notifications: 1
2021-12-16 16:44:22:700 [ info nextcloud.gui.folder.manager ]: Run etag job on folder OCC::Folder(0x55acc8dcfc50)
2021-12-16 16:44:22:700 [ info nextcloud.gui.folder ]: Trying to check "https://next.domainremoved.com/remote.php/dav/files/sts/" for changes via ETag check. (time since last sync: 53 s)
2021-12-16 16:44:22:701 [ debug nextcloud.gui.folder.manager ] [ OCC::FolderMan::slotRunOneEtagJob ]: Scheduling "https://next.domainremoved.com/remote.php/dav/files/sts/" to check remote ETag
2021-12-16 16:44:22:701 [ info nextcloud.sync.accessmanager ]: 6 "PROPFIND" "https://next.domainremoved.com/remote.php/dav/files/sts/" has X-Request-ID "1fd3de3c-448e-4adc-a099-2639b2a7536e"
2021-12-16 16:44:22:701 [ debug nextcloud.sync.cookiejar ] [ OCC::CookieJar::cookiesForUrl ]: QUrl("https://next.domainremoved.com/remote.php/dav/files/sts/") requests: (QNetworkCookie("__Host-nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=next.domainremoved.com; path=/"), QNetworkCookie("__Host-nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=next.domainremoved.com; path=/"), QNetworkCookie("oc_sessionPassphrase=x59iL8myvO9c3h2gF9K%2Fiyd8zFuIibbvzMN7f%2BosKUmoAyV%2B6CgafQg65mt3xWLJMpjlgKCh%2BqCMJm%2Fe5qMGZHPpyBgE48t0f4zJljORpDXBtFjcjLiyxZ5%2BNWDSVF1B; secure; HttpOnly; domain=next.domainremoved.com; path=/"), QNetworkCookie("ocnb1ijzw9hg=q54f7k6ndu62a03k274ap1jqlc; secure; HttpOnly; domain=next.domainremoved.com; path=/"))
2021-12-16 16:44:22:701 [ info nextcloud.sync.networkjob ]: OCC::RequestEtagJob created for "https://next.domainremoved.com" + "/" "OCC::Folder"
2021-12-16 16:44:25:700 [ warning nextcloud.gui.account.state ]: ConnectionValidator already running, ignoring "[email protected]"
2021-12-16 16:44:50:700 [ warning nextcloud.sync.networkjob ]: Network job timeout QUrl("https://next.domainremoved.com/remote.php/dav/files/sts/")
2021-12-16 16:44:50:700 [ info nextcloud.sync.credentials.webflow ]: request finished
2021-12-16 16:44:50:701 [ warning nextcloud.sync.networkjob ]: QNetworkReply::OperationCanceledError "Zeitüberschreitung bei der Verbindung" QVariant(Invalid)
2021-12-16 16:44:50:701 [ warning nextcloud.sync.credentials.webflow ]: QNetworkReply::OperationCanceledError
2021-12-16 16:44:50:701 [ warning nextcloud.sync.credentials.webflow ]: "Operation abgebrochen"
2021-12-16 16:44:50:701 [ info nextcloud.sync.networkjob.propfind ]: PROPFIND of QUrl("https://next.domainremoved.com/remote.php/dav/files/sts/") FINISHED WITH STATUS "OperationCanceledError Zeitüberschreitung bei der Verbindung"
2021-12-16 16:44:50:701 [ warning nextcloud.sync.networkjob.propfind ]: *not* successful, http result code is 0 ""
2021-12-16 16:44:50:701 [ warning nextcloud.sync.credentials.webflow ]: QNetworkReply::OperationCanceledError
2021-12-16 16:44:50:701 [ warning nextcloud.sync.credentials.webflow ]: "Operation abgebrochen"
2021-12-16 16:44:50:701 [ warning default ]: QIODevice::read (QNetworkReplyHttpImpl): device not open
2021-12-16 16:44:50:701 [ info nextcloud.gui.account.state ]: AccountState connection status change: OCC::ConnectionValidator::Connected -> OCC::ConnectionValidator::Timeout
2021-12-16 16:44:50:701 [ info nextcloud.gui.account.state ]: AccountState state change: "Verbunden" -> "Netzwerkfehler"
2021-12-16 16:44:50:703 [ info nextcloud.gui.folder.manager ]: Account "[email protected]" disconnected or paused, terminating or descheduling sync folders
2021-12-16 16:44:50:704 [ debug nextcloud.sync.networkjob ] [ OCC::AbstractNetworkJob::slotFinished ]: Network job OCC::PropfindJob finished for "/"
2021-12-16 16:44:52:700 [ info nextcloud.gui.folder.manager ]: Etag poll timer timeout
2021-12-16 16:44:52:700 [ info nextcloud.gui.folder.manager ]: Folders to sync: 1
2021-12-16 16:44:52:700 [ info nextcloud.gui.folder.manager ]: Number of folders that don't use push notifications: 1
2021-12-16 16:44:52:701 [ info nextcloud.gui.folder.manager ]: Run etag job on folder OCC::Folder(0x55acc8dcfc50)
2021-12-16 16:44:52:701 [ info nextcloud.gui.folder.manager ]: Can not run etag job: Folder is busy
2021-12-16 16:45:22:700 [ warning nextcloud.sync.networkjob ]: Network job timeout QUrl("https://next.domainremoved.com/remote.php/dav/files/sts/")
2021-12-16 16:45:22:700 [ info nextcloud.sync.credentials.webflow ]: request finished
2021-12-16 16:45:22:700 [ warning nextcloud.sync.networkjob ]: QNetworkReply::OperationCanceledError "Zeitüberschreitung bei der Verbindung" QVariant(Invalid)
2021-12-16 16:45:22:700 [ warning nextcloud.sync.credentials.webflow ]: QNetworkReply::OperationCanceledError
2021-12-16 16:45:22:700 [ warning nextcloud.sync.credentials.webflow ]: "Operation abgebrochen"
2021-12-16 16:45:22:700 [ info nextcloud.sync.networkjob.etag ]: Request Etag of QUrl("https://next.domainremoved.com/remote.php/dav/files/sts/") FINISHED WITH STATUS "OperationCanceledError Zeitüberschreitung bei der Verbindung"
2021-12-16 16:45:22:700 [ debug nextcloud.sync.networkjob ] [ OCC::AbstractNetworkJob::slotFinished ]: Network job OCC::RequestEtagJob finished for "/"
2021-12-16 16:45:22:700 [ info nextcloud.gui.folder.manager ]: Etag poll timer timeout
2021-12-16 16:45:22:701 [ info nextcloud.gui.folder.manager ]: Folders to sync: 1
2021-12-16 16:45:22:701 [ info nextcloud.gui.folder.manager ]: Number of folders that don't use push notifications: 1
2021-12-16 16:45:22:701 [ info nextcloud.gui.folder.manager ]: Run etag job on folder OCC::Folder(0x55acc8dcfc50)
2021-12-16 16:45:22:701 [ info nextcloud.gui.folder.manager ]: Can not run etag job: Folder is busy
2021-12-16 16:45:27:701 [ debug nextcloud.sync.account ] [ OCC::Account::resetNetworkAccessManager ]: Resetting QNAM
2021-12-16 16:45:27:701 [ info nextcloud.sync.credentials.webflow ]: Get QNAM
2021-12-16 16:45:27:702 [ debug nextcloud.sync.connectionvalidator ] [ OCC::ConnectionValidator::checkServerAndAuth ]: Checking server and authentication
2021-12-16 16:45:27:703 [ info nextcloud.sync.accessmanager ]: 2 "" "https://next.domainremoved.com/status.php" has X-Request-ID "65aa4f12-6269-4016-80fb-13bbfb58bd7a"
2021-12-16 16:45:27:704 [ info nextcloud.sync.networkjob ]: OCC::CheckServerJob created for "https://next.domainremoved.com" + "status.php" "OCC::ConnectionValidator"
2021-12-16 16:45:27:704 [ info nextcloud.sync.credentials.webflow ]: request finished
2021-12-16 16:45:27:704 [ warning nextcloud.sync.networkjob ]: QNetworkReply::UnknownNetworkError "Der Zugriff auf das Netzwerk ist nicht gestattet." QVariant(Invalid)
2021-12-16 16:45:27:704 [ warning nextcloud.sync.credentials.webflow ]: QNetworkReply::UnknownNetworkError
2021-12-16 16:45:27:704 [ warning nextcloud.sync.credentials.webflow ]: "Der Zugriff auf das Netzwerk ist nicht gestattet."
2021-12-16 16:45:27:704 [ warning default ]: QIODevice::peek (QDisabledNetworkReply): device not open
2021-12-16 16:45:27:704 [ warning nextcloud.sync.networkjob.checkserver ]: error: status.php replied 0 ""
2021-12-16 16:45:27:704 [ warning default ]: QIODevice::peek (QDisabledNetworkReply): device not open
2021-12-16 16:45:27:704 [ warning nextcloud.sync.connectionvalidator ]: QNetworkReply::UnknownNetworkError "Der Zugriff auf das Netzwerk ist nicht gestattet." ""
2021-12-16 16:45:27:704 [ warning nextcloud.sync.credentials.webflow ]: QNetworkReply::UnknownNetworkError
2021-12-16 16:45:27:704 [ warning nextcloud.sync.credentials.webflow ]: "Der Zugriff auf das Netzwerk ist nicht gestattet."
2021-12-16 16:45:27:704 [ info nextcloud.gui.account.state ]: AccountState connection status change: OCC::ConnectionValidator::Timeout -> OCC::ConnectionValidator::StatusNotFound
2021-12-16 16:45:27:705 [ info nextcloud.gui.folder.manager ]: Account "[email protected]" disconnected or paused, terminating or descheduling sync folders
2021-12-16 16:45:27:705 [ debug nextcloud.sync.networkjob ] [ OCC::AbstractNetworkJob::slotFinished ]: Network job OCC::CheckServerJob finished for "status.php"
2021-12-16 16:45:52:700 [ info nextcloud.gui.folder.manager ]: Etag poll timer timeout
2021-12-16 16:45:52:700 [ info nextcloud.gui.folder.manager ]: Folders to sync: 1
2021-12-16 16:45:52:700 [ info nextcloud.gui.folder.manager ]: Number of folders that don't use push notifications: 1
2021-12-16 16:45:52:701 [ info nextcloud.gui.folder.manager ]: Run etag job on folder OCC::Folder(0x55acc8dcfc50)
2021-12-16 16:45:52:701 [ info nextcloud.gui.folder.manager ]: Can not run etag job: Folder is busy
I do have an issue with sync going offline as well. Could not replicate it yet by going to standby. I'll provide logs the next time this happens.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
I have a very similar issue with the Windows client. After resume from standby, all of my Windows clients take 30-60 seconds before they connect to the server (but they eventually do connect and status goes green). If I go to Network settings and change the proxy (within those 30 seconds), it immediately connects. It also immediately connects if I exit and restart the client.
My Linux systems (AppImage client) also see this problem, but it's far less often.
This occurs for both wireless and wired clients, and the network is up and working in all cases.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
I also have this on Arch linux, since 3.5.0 release candidates and still applies for 3.5.1 release. I'm not using virtual files, but client_push is enabled on MY servers. What I noticed:
- If I put my laptop to standby and resume after a short time, my instances (using client_push) are reconnected instantly (icon=green). Not so instances on 3rd-party servers (not using client_push) – they take up to 60 seconds to be reconnected.
- If I put my laptop to standby and resume after a longer time (e.g. the next morning), then
- my instances (all NC24 using client_push), e.g. cloud.seyfarth.de and some externally hosted instances (NC23, e.g. cloud.bringman.de and Hetzner StorageBox instances where I do not know whether they feature client_push) do not reconnect at all, no matter how long I wait (icon=gray). They show "Der Server hat während des Lesens des Verzeichnisses "" mit einem Fehler geantwortet: Die angegebene Konfiguration kann nicht verwendet werden.".
- Other instances on 3rd-party servers (probably not using client_push) may take up to 60 seconds but eventually do reconnect (icon=green), e.g. cloud.theater-im-steinbruch.de, cloud.computertruhe.de and cloud.bvdnet.de.
@devs: Can anyone confirm this bug so that it does not get the github-actions auto-close event every 4 weeks?
Probably related bugs:
- https://github.com/nextcloud/desktop/issues/4331 (very likely)
- https://github.com/nextcloud/desktop/issues/4450 (less so)
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
I received 3.5.2 yesterday, CHANGELOG of 3.5.2 seems to have no fixes that might have solved his issue.
It still shows the same behavior, at least for some minutes after resume. After a while (5 minutes?) SOMETIMES (about every 4th time the client is offline after resuming) it revovers though.
@nursoda
my instances (all NC24 using client_push), e.g. cloud.seyfarth.de and some externally hosted instances (NC23, e.g. cloud.bringman.de and Hetzner StorageBox instances where I do not know whether they feature client_push) do not reconnect at all, no matter how long I wait (icon=gray). They show "Der Server hat während des Lesens des Verzeichnisses "" mit einem Fehler geantwortet: Die angegebene Konfiguration kann nicht verwendet werden.".
I see the same on Manjaro. I wonder if this is Arch specific, because I don't see this on my Debian machines.
@vasyugan
I see the same on Manjaro. I wonder if this is Arch specific, because I don't see this on my Debian machines.
Rather newer kernels than Arch, but that's just a gutt feeling.
Something similar happens to me from time to time on macOS 12.4/12.5, but with one difference: the client never seems to recover. I have waited 15+ minutes. I have to restart the client whenever it happens. I tried pausing synchronization and resuming, but to no avail.
Mind that there are three states I see after recovering from standby – probably different issues?
- gray, sometimes recovers after several minutes, I see "Offline". Sometimes, the state changes from gray to red.
- red, stays that way until I change proxy settings or shutdown and restart the client; I see entries in the (local) "Activity" that state that the drive/storage is not available
- green, all seems OK, but files aren't synced anyway I experience this on my employees laptops aswell: W10, OS X, … so this should be handled in a separate issue and is prone to be related to client_push
If I go to Network settings and change the proxy (within those 30 seconds), it immediately connects. It also immediately connects if I exit and restart the client.
That indeed is sufficient, as an alternative to closing and restarting the client. Yet, this only resolves the issue as long as the system doesn't go to standby for a longer period again, no matter which proxy setting. It just seems to force a reconnect.
Updates 04.-06.08.2022: Got 3.5.4 via Arch. Looked promising: green after resume from overnight standby. However, in subsequent cases, I got gray→red – so no change.
Question: I just switched the laptop's WiFi OFF. NC sync client icon went gray. OK, Turned WiFi back ON. Icon stays gray. Shouldn't it get a system signal that network is up again, and reconnect immediately (and not only after several minutes)? Thunderbird at least seems to get one since it starts syncing right after.
I played a bit with my laptop's config and found that I still had snx (Check Point SSL Network Extender VPN Client) installed. Since I uninstalled it, I did not see a grey/red NC icon again. I will be watching more standby/resume cycles first, but ATM it seems to have been the culprit. Has anyone else that suffers this issue VPN clients installed that might interfere? While I agree that the NC sync client should be able to handle such PC config, it would significantly narrow down where to search and which workarounds do work.
I played a bit with my laptop's config and found that I still had
snx(Check Point SSL Network Extender VPN Client) installed. Since I uninstalled it, I did not see a grey/red NC icon again. I will be watching more standby/resume cycles first, but ATM it seems to have been the culprit. Has anyone else that suffers this issue VPN clients installed that might interfere? While I agree that the NC sync client should be able to handle such PC config, it would significantly narrow down where to search and which workarounds do work.
I never heard of snx and I surely never used it. So in my case, I don't think that it is related.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
I don't have snx installed any more but still have this issue, even with 3.6.0 – today however, it was only with those instances that do NOT have client_push installed.
Status/Feedback: With the current 3.6.0 client on Arch, I rarely have issues.
Search for similarities of affected users: Since a couple of days (new kernels, 5.19.9 atm) I get KDE notifications concerning my Wifi device not being ready. That reminded me of another possible cause for this issue: My Lenovo T14s is configured in UEFI to disable WiFi if Ethernet is connected. I suspect Wifi being up right after resume and then being disabled with such delay that linux sees it for some (very short) time after resuming. This could also have impact on this issue and is available not only for Lenovo devices (I know of HP and Dell devices that provided similar BIOS/UEFI settings).
Another finding: Switching proxy settings is a manual workaround. The same workaround also works to immediately load all user icons (if the user has multiple instances configured). THAT case (icons not loading) has nothing to do with standby or UEFI settings. Might there be a common cause?
I have 3.6.0 on 2 Linux Mint clients and 2 Windows clients. I have seen no improvement on any of them yet. It still refuses to connect when first resuming from standby. If I wait 30-60 seconds, it usually connects. If I go into settings and change the proxy settings it immediately connects. I have resorted to using a batch script in Windows to kill the Nextcloud process and restart it (it always connects immediately when you first start the client).
Status on Arch Linux with Kernel 6.0 (and latest 5.x): I reproducibly have a dysfunctional desktop sync client after longer standby periods solvable by switching Proxy settings forth and back. I noticed that my Thunderbird calendars (hosted on Nextcloud) now also come up with warning sign (connection issue) in such cases. I assume that something at the Linux kernel has changed, like that they issue the "network available" system bus notification while it is not. Wouldn't a simple "wait 1 sec before internally treating 'internet is back' as such" be a possible permanent workaround (at least on Linux) with little impact to all users?
Is there an easier way to make the client re-connect than click to open the settings, select network, switch Proxy and close it? Like sending a UNIX SIGNAL "reload your config" or similar (e.g. using killall)?
I do run latest manjaro stable on a notebook: manjaro-5.15.78-1-MANJARO
NC Desktop Client:
Version 3.6.2git. For more information please click [here](https://docs.nextcloud.com/desktop/3.6/).
This release was supplied by Nextcloud GmbH
Built from Git revision [2a703f](https://github.com/nextcloud/desktop/commit/2a703f26b7f77451ad157fcaa215d7e99a4b4015) on Nov 10 2022, 17:54:23 using Qt 5.15.7, OpenSSL 3.0.7 1 Nov 2022
What I see: most of the time after recoverting from standby the client doesn't reconnect. In all other cases the notebook maybe wasn't in standby?
What i always do: exit NC Desktop Client and restart it ;(
Same on Ubuntu 22.04.1 running NC 3.6.2 on a Dell XPS 7590.
My /etc/systemd/logind.conf has this line: HandleLidSwitch=hibernate
So maybe it's hibernate, not suspend, that NC can't recover from.
