search

nextcloud / desktop

đź’» Desktop sync client for Nextcloud
https://nextcloud.com/install/#install-clients
GNU General Public License v2.0
2.97k stars 784 forks source link

wake up from suspend - The specified configuration cannot be used. #4331

Open Tealk opened 2 years ago

Tealk commented 2 years ago

How to use GitHub

Actual behaviour

When I suspend the computer and then wake it up again I get the following error message in the sync client: "The server responded with an error while reading the directory "": The specified configuration cannot be used."

when i restart the sync client everything works smoothly

Steps to reproduce

  1. start sync client
  2. suspend coputer
  3. wake up computer

Client configuration

Client version:

Operating system:

OS language: EndeavourOS, 5.16.11-arch1-1, GNOME 41.4

Qt version used by client package (Linux only, see also Settings dialog):

Client package (From Nextcloud or distro) (Linux only): community/nextcloud-client

Installation path of client:

Server configuration

Nextcloud version: 23.0.2

Storage backend (external storage):

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer logs.

  1. Client logfile: https://gist.github.com/Tealk/4be122cdcb13a74e3ff7ed723f6da067

  2. Web server error log: No errors in the log

  3. Server logfile: nextcloud log (data/nextcloud.log):

simonspa commented 2 years ago

I am experiencing the same issue, but have one more bit of information to add:

The client has two accounts configured on my PC, one connecting to a NC 22.2 (apparently without NC Notify Push) the other to a NC 23.0 installation (with a NC Notify Push server). Interestingly, the issue only appears with the 23.0 server, the other account shows a successful sync even after waking up from suspend.

Might this be a Push issue?

2022-03-28 08:20:58:982 [ debug nextcloud.sync.database.sql ./src/common/ownsql.h:145 ] [ OCC::SqlQuery::bindValue ]:   SQL bind 1 9062580476048031110
2022-03-28 08:20:58:982 [ debug nextcloud.sync.database.sql ./src/common/ownsql.cpp:295 ]   [ OCC::SqlQuery::exec ]:    SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum, e2eMangledName, isE2eEncrypted  FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
2022-03-28 08:20:58:983 [ debug nextcloud.sync.database.sql ./src/common/ownsql.h:145 ] [ OCC::SqlQuery::bindValue ]:   SQL bind 1 9062580476048031110
2022-03-28 08:20:58:983 [ debug nextcloud.sync.database.sql ./src/common/ownsql.cpp:295 ]   [ OCC::SqlQuery::exec ]:    SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum, e2eMangledName, isE2eEncrypted  FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
2022-03-28 08:20:58:983 [ debug nextcloud.sync.database.sql ./src/common/ownsql.h:145 ] [ OCC::SqlQuery::bindValue ]:   SQL bind 1 9062580476048031110
2022-03-28 08:20:58:983 [ debug nextcloud.sync.database.sql ./src/common/ownsql.cpp:295 ]   [ OCC::SqlQuery::exec ]:    SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum, e2eMangledName, isE2eEncrypted  FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
2022-03-28 08:20:58:983 [ debug nextcloud.sync.database.sql ./src/common/ownsql.h:145 ] [ OCC::SqlQuery::bindValue ]:   SQL bind 1 9062580476048031110
2022-03-28 08:20:58:983 [ debug nextcloud.sync.database.sql ./src/common/ownsql.cpp:295 ]   [ OCC::SqlQuery::exec ]:    SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum, e2eMangledName, isE2eEncrypted  FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
2022-03-28 08:20:59:169 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:1069 ]: <========== Sync finished for folder [cloud] of account [user@cloud.domain.tld] with remote [https://cloud.domain.tld/remote.php/dav/files/user/]
2022-03-28 08:21:18:154 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:867 ]:  Etag poll timer timeout
2022-03-28 08:21:18:154 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:871 ]:  Folders to sync: 2
2022-03-28 08:21:18:154 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:881 ]:  Number of folders that don't use push notifications: 1
2022-03-28 08:21:18:154 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:898 ]:  Run etag job on folder OCC::Folder(0x560888d41280)
2022-03-28 08:21:18:154 [ info nextcloud.gui.folder ./src/gui/folder.cpp:331 ]: Trying to check "https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/" for changes via ETag check. (time since last sync: 155 s)
2022-03-28 08:21:18:154 [ debug nextcloud.gui.folder.manager ./src/gui/folderman.cpp:696 ]  [ OCC::FolderMan::slotRunOneEtagJob ]:  Scheduling "https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/" to check remote ETag
2022-03-28 08:21:18:154 [ info nextcloud.sync.accessmanager ./src/libsync/accessmanager.cpp:78 ]:   6 "PROPFIND" "https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/" has X-Request-ID "8df793bd-c76c-4628-b789-61822d05a8ea"
2022-03-28 08:21:18:154 [ debug nextcloud.sync.cookiejar ./src/libsync/cookiejar.cpp:90 ]   [ OCC::CookieJar::cookiesForUrl ]:  QUrl("https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/") requests: (QNetworkCookie("__Host-nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.otherdomain.tld; path=/"), QNetworkCookie("__Host-nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.otherdomain.tld; path=/"), QNetworkCookie("oc_sessionPassphrase=oy5IriBtLb3Br0xQLyjIa0Roto6T41XYyDMEMAjqa8pUGNB7hLUNYmf%2FKkuvO%2FiAJgsuDOmPC9CaFBBHddwmMi4qS6uEvk2Vyiyy5JdpaOzCht038CdUW8uB4GxzlmcC; secure; HttpOnly; domain=cloud.otherdomain.tld; path=/"), QNetworkCookie("oc9zyu47ewik=nv13rgbdi2rceleq2r2fkkvlc2; secure; HttpOnly; domain=cloud.otherdomain.tld; path=/"))
2022-03-28 08:21:18:155 [ info nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:361 ]:    OCC::RequestEtagJob created for "https://cloud.otherdomain.tld" + "/" "OCC::Folder"
2022-03-28 08:21:18:396 [ info nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:425 ]: request finished
2022-03-28 08:21:18:396 [ info nextcloud.sync.networkjob.etag ./src/libsync/networkjobs.cpp:109 ]:  Request Etag of QUrl("https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/") FINISHED WITH STATUS "OK"
2022-03-28 08:21:18:396 [ debug nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:298 ]    [ OCC::AbstractNetworkJob::slotFinished ]:  Network job OCC::RequestEtagJob finished for "/"
2022-03-28 08:21:23:154 [ debug nextcloud.sync.pushnotifications ./src/libsync/pushnotifications.cpp:257 ]  [ OCC::PushNotifications::pingWebSocketServer ]:    Ping websocket server
2022-03-28 08:21:23:184 [ debug nextcloud.sync.pushnotifications ./src/libsync/pushnotifications.cpp:237 ]  [ OCC::PushNotifications::onWebSocketPongReceived ]:    Pong received in time
2022-03-28 08:21:25:154 [ info nextcloud.sync.accessmanager ./src/libsync/accessmanager.cpp:78 ]:   2 "" "https://cloud.domain.tld/ocs/v1.php/cloud/user?format=json" has X-Request-ID "2e15b2d0-276c-4f18-9681-407008a2d72c"
2022-03-28 08:21:25:155 [ debug nextcloud.sync.cookiejar ./src/libsync/cookiejar.cpp:90 ]   [ OCC::CookieJar::cookiesForUrl ]:  QUrl("https://cloud.domain.tld/ocs/v1.php/cloud/user?format=json") requests: (QNetworkCookie("__Host-nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.domain.tld; path=/"), QNetworkCookie("__Host-nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.domain.tld; path=/"), QNetworkCookie("oc_sessionPassphrase=iGIxaDNq2lrLDrdKhWyMNkwtmG4ANujScbPpKnuxt7byIsylwu7k63N1ST%2FsF1H%2BKgITOodEn2TMZtyUEYtvc4syItFSBVYLz0le5smSXh%2Bofxn098flfl59QefUuYMm; secure; HttpOnly; domain=cloud.domain.tld; path=/"), QNetworkCookie("oc0e7rzi20xo=9d4021da69b91e7f48e67576abc8e19b; secure; HttpOnly; domain=cloud.domain.tld; path=/"))
2022-03-28 08:21:25:157 [ info nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:361 ]:    OCC::JsonApiJob created for "https://cloud.domain.tld" + "ocs/v1.php/cloud/user" "OCC::UserInfo"
2022-03-28 08:21:25:157 [ info nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:425 ]: request finished
2022-03-28 08:21:25:157 [ warning nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:224 ]: QNetworkReply::NetworkSessionFailedError "The specified configuration cannot be used." QVariant(Invalid)
2022-03-28 08:21:25:157 [ warning nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:227 ]:  QNetworkReply::NetworkSessionFailedError
2022-03-28 08:21:25:157 [ warning nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:228 ]:  "The specified configuration cannot be used."
2022-03-28 08:21:25:157 [ info nextcloud.sync.networkjob.jsonapi ./src/libsync/networkjobs.cpp:881 ]:   JsonApiJob of QUrl("https://cloud.domain.tld/ocs/v1.php/cloud/user?format=json") FINISHED WITH STATUS "NetworkSessionFailedError The specified configuration cannot be used."
2022-03-28 08:21:25:157 [ warning nextcloud.sync.networkjob.jsonapi ./src/libsync/networkjobs.cpp:887 ]:    Network error:  "ocs/v1.php/cloud/user" "The specified configuration cannot be used." QVariant(Invalid)
2022-03-28 08:21:25:158 [ info nextcloud.sync.accessmanager ./src/libsync/accessmanager.cpp:78 ]:   2 "" "https://cloud.domain.tld/remote.php/dav/avatars/user/128.png" has X-Request-ID "5b771cee-4a3e-42f6-aa11-4e92fa777efb"
2022-03-28 08:21:25:158 [ debug nextcloud.sync.cookiejar ./src/libsync/cookiejar.cpp:90 ]   [ OCC::CookieJar::cookiesForUrl ]:  QUrl("https://cloud.domain.tld/remote.php/dav/avatars/user/128.png") requests: (QNetworkCookie("__Host-nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.domain.tld; path=/"), QNetworkCookie("__Host-nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.domain.tld; path=/"), QNetworkCookie("oc_sessionPassphrase=iGIxaDNq2lrLDrdKhWyMNkwtmG4ANujScbPpKnuxt7byIsylwu7k63N1ST%2FsF1H%2BKgITOodEn2TMZtyUEYtvc4syItFSBVYLz0le5smSXh%2Bofxn098flfl59QefUuYMm; secure; HttpOnly; domain=cloud.domain.tld; path=/"), QNetworkCookie("oc0e7rzi20xo=9d4021da69b91e7f48e67576abc8e19b; secure; HttpOnly; domain=cloud.domain.tld; path=/"))
2022-03-28 08:21:25:159 [ info nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:361 ]:    OCC::AvatarJob created for "https://cloud.domain.tld" + "" "OCC::UserInfo"
2022-03-28 08:21:25:159 [ debug nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:298 ]    [ OCC::AbstractNetworkJob::slotFinished ]:  Network job OCC::JsonApiJob finished for "ocs/v1.php/cloud/user"
2022-03-28 08:21:25:159 [ info nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:425 ]: request finished
2022-03-28 08:21:25:159 [ warning nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:224 ]: QNetworkReply::NetworkSessionFailedError "The specified configuration cannot be used." QVariant(Invalid)
2022-03-28 08:21:25:159 [ warning nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:227 ]:  QNetworkReply::NetworkSessionFailedError
2022-03-28 08:21:25:160 [ warning nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:228 ]:  "The specified configuration cannot be used."
2022-03-28 08:21:25:160 [ debug nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:298 ]    [ OCC::AbstractNetworkJob::slotFinished ]:  Network job OCC::AvatarJob finished for ""
2022-03-28 08:21:46:154 [ debug nextcloud.gui.account.state ./src/gui/accountstate.cpp:262 ]    [ OCC::AccountState::checkConnectivity ]:   "otheruser@cloud.otherdomain.tld" The last ETag check succeeded within the last  30 s ( 29 s). No connection check needed!
2022-03-28 08:21:48:153 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:867 ]:  Etag poll timer timeout
2022-03-28 08:21:48:154 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:871 ]:  Folders to sync: 2
2022-03-28 08:21:48:154 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:881 ]:  Number of folders that don't use push notifications: 1
2022-03-28 08:21:48:154 [ info nextcloud.gui.folder.manager ./src/gui/folderman.cpp:898 ]:  Run etag job on folder OCC::Folder(0x560888d41280)
2022-03-28 08:21:48:155 [ info nextcloud.gui.folder ./src/gui/folder.cpp:331 ]: Trying to check "https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/" for changes via ETag check. (time since last sync: 185 s)
2022-03-28 08:21:48:155 [ debug nextcloud.gui.folder.manager ./src/gui/folderman.cpp:696 ]  [ OCC::FolderMan::slotRunOneEtagJob ]:  Scheduling "https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/" to check remote ETag
2022-03-28 08:21:48:155 [ info nextcloud.sync.accessmanager ./src/libsync/accessmanager.cpp:78 ]:   6 "PROPFIND" "https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/" has X-Request-ID "18a073cb-ae32-4a69-ab6d-bc83e17cf78b"
2022-03-28 08:21:48:155 [ debug nextcloud.sync.cookiejar ./src/libsync/cookiejar.cpp:90 ]   [ OCC::CookieJar::cookiesForUrl ]:  QUrl("https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/") requests: (QNetworkCookie("__Host-nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.otherdomain.tld; path=/"), QNetworkCookie("__Host-nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=cloud.otherdomain.tld; path=/"), QNetworkCookie("oc_sessionPassphrase=oy5IriBtLb3Br0xQLyjIa0Roto6T41XYyDMEMAjqa8pUGNB7hLUNYmf%2FKkuvO%2FiAJgsuDOmPC9CaFBBHddwmMi4qS6uEvk2Vyiyy5JdpaOzCht038CdUW8uB4GxzlmcC; secure; HttpOnly; domain=cloud.otherdomain.tld; path=/"), QNetworkCookie("oc9zyu47ewik=nv13rgbdi2rceleq2r2fkkvlc2; secure; HttpOnly; domain=cloud.otherdomain.tld; path=/"))
2022-03-28 08:21:48:156 [ info nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:361 ]:    OCC::RequestEtagJob created for "https://cloud.otherdomain.tld" + "/" "OCC::Folder"
2022-03-28 08:21:48:824 [ info nextcloud.sync.credentials.webflow ./src/gui/creds/webflowcredentials.cpp:425 ]: request finished
2022-03-28 08:21:48:824 [ info nextcloud.sync.networkjob.etag ./src/libsync/networkjobs.cpp:109 ]:  Request Etag of QUrl("https://cloud.otherdomain.tld/remote.php/dav/files/otheruser/") FINISHED WITH STATUS "OK"
2022-03-28 08:21:48:824 [ debug nextcloud.sync.networkjob ./src/libsync/abstractnetworkjob.cpp:298 ]    [ OCC::AbstractNetworkJob::slotFinished ]:  Network job OCC::RequestEtagJob finished for "/"
2022-03-28 08:21:53:154 [ debug nextcloud.sync.pushnotifications ./src/libsync/pushnotifications.cpp:257 ]  [ OCC::PushNotifications::pingWebSocketServer ]:    Ping websocket server
2022-03-28 08:21:53:188 [ debug nextcloud.sync.pushnotifications ./src/libsync/pushnotifications.cpp:237 ]  [ OCC::PushNotifications::onWebSocketPongReceived ]:    Pong received in time
andreashaerter commented 2 years ago

Same problem with Nextcloud Server 23.0.3 and nextcloud-client-3.4.4 on Fedora 35 x64. Completely restarting the client or system fixes the problem till the next stand-by. It seems that the problem did not exist with Nextcloud Server 22.x but the same client version. I got three accounts configured in my client.

github-actions[bot] commented 2 years ago

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!

nursoda commented 2 years ago

I encounter the same bug on Arch with Nextcloud Sync Client 3.5.0 (release). After resuming from standby, I see this in the client settings for each self-hosted cloud (accessed via external/official IPv4): grafik Nothing I tried in the client solves the issue – but re-starting the client does (until I suspend the laptop again). I'm using WiFi with the Laptop and I suspect a timing issue/race condition in the Nextcloud Desktop client for Linux. I'm using Client Push on NGINX with sockets.

arturi commented 2 years ago

Same issue on Fedora 36 deep sleep with Nextcloud Desktop Appimage 3.5.0.

Witcher01 commented 2 years ago

Experiencing the same error with an instance hosted by Hetzner via their "Storage Share", the client is running on Arch Linux (Linux 5.18.7, Nextcloud client version 3.5.1).

It's getting rather irritating after a few months of experiencing this issue on almost every suspend-wake cycle and having to restart the client.

Borroot commented 2 years ago

Same problem with nextcloud server v1.47.2 and nextcloud client v3.5.1git (git revision 930206f06c023f031008ea6ce511ee0fbe2e4ae1).

coelner commented 2 years ago

It is possible to get the client running again, if you change between no proxy and system proxy or vice versa (doesn't matter). I don't know why, but maybe a new connection handling is established.

nursoda commented 2 years ago

Great finding. It hints to the root cause (network signals to be ready but is not; desktop client relys on that signal but does not verify). My proposal for a possible solution: Treat initial phase after "connection (re)established" differently in terms of either a short delay prior to connect, or some verification that the assumed established connection actually works – and if not close and reconnect. One could even go for ("after network is back, ( wait N seconds¹,) close connection and reconnect ".

Questions unclear to me: Is this Linux specific? Does this only happen with client_push enabled?

However, it smells. IIRC, the issue arose for me after I installed a new kernel, not after installing a new version of the desktop client. I've been scrolling through the Linux kernel changelog for the kernel I just installed now and see quite some fixes there that could possible related. So, IF it would be JUST Linux specific, then the proposal above poses rather a workaround.

But introducing some kind of end-to-end connection verification would improve reliability on all platforms.

Âą Unsure on how long N would have to be to catch all kinds of network connection though. Personally, I wouldn't mind 5 or even 10 seconds, but there certainly are people that would disagree to wait "for so long without reason", especially in case they don't suffer the reconnect issue at all.

mgallien commented 2 years ago

@Tealk sorry for being slow to answer thanks a lot for the logs do you still have an issue from your log file, it is not really clear what is going on because after the failed network requests (same error you have reported) the next ones are being done successfully I tried to reproduce but suspending for a few seconds is clearly not the only condition to reproduce

Tealk commented 2 years ago

currently i am not even sure if the problem still exists

the nextcloud icon in the taskbar always indicated that there was no connection; maybe that was just a visual problem?

nursoda commented 2 years ago

@Tealk It definitely still exists for me, also on recent kernels. I sometimes have a grey icon that sometimes turns green after a while and sometimes doesn't, and I just had the case that the sync icon shows green but does not recognize new files. (The latter has not been described in THIS bug yet and may be out-of-scope for this issue.)

@mgallien I'd be happy to provide logs aswell. How should I produce / filter them?

andreashaerter commented 2 years ago

@Tealk It definitely still exists for me, too. nextcloud-client-3.5.2-1 on Fedora 36 with newest 5.18.13-200.fc36.x86_64 kernel. Nextcloud Server 24.0.1 and 24.0.3. It is not only a visual problem. The Client does not sync anymore while "The specified configuration cannot be used." happens.

markusstraub commented 2 years ago

For everybody who needs a workaround (on Linux):

Use a systemd user service and restart that after every sleep/hibernate. Heavily inspired by this helpful blog post

~/.config/systemd/user/nextcloud.service

[Unit]
Description=nextcloud
After=default.target

[Service]
ExecStart=/usr/bin/nextcloud
LimitNOFILE=65535:65535

[Install]
WantedBy=default.target

~/.config/systemd/user/nextcloud_restart.service

[Unit]
After=sleep.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c nextcloud_restart

[Install]
WantedBy=sleep.target

~/.local/bin/nextcloud_restart

#! /bin/bash
# wait a few seconds until wifi connection is up..
# that's also the reason why we need this extra shell script
sleep 10
systemctl --user restart nextcloud

~/.config/systemd/user/watch_sleep.service

[Unit]
Description=watch for sleep signal to start sleep.target

[Service]
ExecStart=/bin/bash -c watch_sleep
Restart=on-failure

[Install]
WantedBy=default.target

~/.local/bin/watch_sleep

#!/bin/bash
dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member=PrepareForSleep" | while read x; do
    case "$x" in
        *"boolean false"*) systemctl --user --no-block stop sleep.target;;
        *"boolean true"*) systemctl --user --no-block start sleep.target;;
    esac
done

~/.config/systemd/user/sleep.target

[Unit]
Description=User level sleep target
StopWhenUnneeded=yes

Copy these files to the according location and systemctl --user enable <SERVICENAME> the respective services.

Also deactivate the autostart functionality in the nextcloud client itself.

github-actions[bot] commented 2 years ago

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!

nursoda commented 2 years ago

For everybody who needs a workaround (on Linux): …

I tried to get that to work for me but struggled and ultimately did not succeed. It just didn't work (and had side effects), so I reverted all changes to my user's systemd setup. But anyway, this bug is about finding the root cause.

github-actions[bot] commented 1 year ago

This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!

andreashaerter commented 1 year ago

This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!

Issue is still existing, could someone re-open it?

$ nextcloud --version
Nextcloud version 3.5.4git
Git revision fea9863097e3abfc372695f5e0e3846e37cecbcb

$ dnf info nextcloud-client

Installed Packages
Name         : nextcloud-client
Version      : 3.5.4
Release      : 1.fc36
Architecture : x86_64
Size         : 13 M
Source       : nextcloud-client-3.5.4-1.fc36.src.rpm
Repository   : @System
From repo    : updates
Summary      : The Nextcloud Client
URL          : https://nextcloud.com/install/#install-clients
License      : LGPLv2+ and GPLv2
Description  : Nextcloud-client enables you to connect to your private Nextcloud
             : Server. With it you can create folders in your home directory,
             : and keep the contents of those folders synced with your Nextcloud
             : server. Simply copy a file into the directory and the Nextcloud
             : Client does the rest.
nursoda commented 1 year ago

There's something wrong with the auto-close bot!

bardo commented 1 year ago

Same behavior on Arch Linux and Nextcloud Desktop 3.6.0:

$ pacman -Q nextcloud-client 
nextcloud-client 2:3.6.0-2

$ nextcloud --version
Nextcloud version 3.6.0git
Git revision ccc9f8930bb45f911da8e23ab5b7d35f615d7ca2
Using Qt 5.15.6, built against Qt 5.15.6
Using Qt platform plugin 'xcb'
Using 'OpenSSL 1.1.1q  5 Jul 2022'
Running on Arch Linux, x86_64
andreashaerter commented 1 year ago

@mgallien could you remove the stale label / re-open this issue? It still affects many plattforms and laptop users, it was not solved. Please let me know if any additional information can be provided.

https://github.com/nextcloud/desktop/issues/4331#issuecomment-1192560867 and https://github.com/nextcloud/desktop/issues/4331#issuecomment-1206647671 are helpful workarounds but are no real solution.

mgallien commented 1 year ago

so far, if I understand correctly, this is the bearing management code inside Qt and our code that are interacting badly we are in the process of moving to Qt6 were this code is much simpler (and probably without this issue) hopefully, I can soon provide experimental AppImage to test it if any of you are interested in providing feedback

mgallien commented 1 year ago

to all affected people, could try again to give me detailed steps (including which desktop:workspace you use and the network manager like systemd-networkd or NetworkManager, ...) I have never ever had the issue so it is hard to debug it

nursoda commented 1 year ago

I'm so sorry I did not have the time to meet and debug with you at the Nextcloud conference.

If that helps, we could do an interactive session (screenshare) on my computer, but even there it's hard to debug since it only happens upon wakeup from standby and hibernantion.

Please specify what to set/record locally, like using strace or what to extract from syslog / system journal.

I'm on a Lenovo T14s Gen1 (with Ryzen 7 PRO 4750U) using Arch with KDE Plasma and Networkmanager, nextcloud-client 2:3.6.0-2.

Tealk commented 1 year ago

to all affected people, could try again to give me detailed steps

I would like to help, I am running arch gnome42, what kind of data do you need?

mgallien commented 1 year ago

@nursoda no worries, we should still be able to move forward without having to meet in person @tealk @nursoda my best bet would be to run the desktop client with extra logging enabled (will be very verbose, so be careful with your disc usage)

export QT_LOGGING_RULES="*=true"
nextcloud

would probably be possible to limit the logging rules to only the Qt bearer management code but I do not remember how to find the proper logging category

Tealk commented 1 year ago

with the current version or the experimental AppImage?

nursoda commented 1 year ago

Thanks! I'll do it with the latest release Arch provides.

br4yd commented 1 year ago

Hi, having the same error. Only restarting the client helps. Tried to do the logging you suggested in https://github.com/nextcloud/desktop/issues/4331#issuecomment-1270162665 but it doesn't show anything unusual as far as I understand. However this bug can be reproduced by installing Fedora 36 Workstation on a Laptop and installing Nextcloud. After starting the client everything works, until you close the laptop and open it back up. As soon as the laptop goes out of the hibernation mode the error mentioned everywhere here will appear. grafik I also enabled the logging and copy pasted everything here: https://gist.github.com/br4yd/a330ef5ecc3f6965bdd645dbedf39540

System information:

OS: Fedora Linux 36 (Workstation Edition)
Host: 82EY IdeaPad Gaming 3 15ARH05
Kernel: 5.19.15-201.fc36.x86_64
DE: GNOME 42.5
CPU: AMD Ryzen 5 4600H
GPU: AMD RENOIR (OnBoard)
dGPU: NVIDIA GeForce GTX 1650

Nextcloud Desktop Version: 3.6.0 (Fedora)
Nextcloud Server Version: 24.0.5

Hope this helps. The bug at least can be pretty annoying.

Edit: If you need more information please ask and I will try to provide them.

github-actions[bot] commented 1 year ago

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!

Darklesss commented 1 year ago

Despite the bot continually trying to close this issue, it's still a problem and still (apparently) affecting lots of us. I'm experiencing it on a tablet running Manjaro with Gnome 42.4 and Nextcloud 3.6.1. I keep the device in suspend when not using it. Have to change the network proxy settings after each time I use Nextcloud on that device to be sure my changes are synced with the server.

It doesn't seem to be happening on my laptop running PopOS 22.04 with Plasma 5.24.6 and Nextcloud 3.4.2.

I'm happy to provide logs or test the new appimage with QT6 if that would help resolve the issue. Thanks.

github-actions[bot] commented 1 year ago

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!

nursoda commented 1 year ago

Ping to make sure this does not get auto-closed. Folks, this really should get some attention. Very annoying, every day.

github-actions[bot] commented 1 year ago

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!

futtta commented 1 year ago

Please keep this open until a root-cause & solution can be found.

nursoda commented 1 year ago

This bug would have long been fixed if NC folks were using Linux with recent kernels :)

arturi commented 1 year ago

It's hard to believe it's been that long :(Recent Fedora 37 + GNOME — I restart NextCloud each time after sleep, otherwise sync is broken.

@mgallien, @dragotin, @ogoffart, @ckamm, can someone please look into this?

dragotin commented 1 year ago

@arturi sorry, this is forked software that I am not involved with. Good luck!

github-actions[bot] commented 1 year ago

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!

jkhsjdhjs commented 1 year ago

We need a bot that posts a comment here every month.

meonkeys commented 1 year ago

Is this a dup of #4084 ?

Also, in case it helps: I see this behavior on a laptop, but not a desktop. The client running on the laptop struggles to connect after resuming from suspend, sometimes taking a minute or longer or perhaps never going from gray to green. The client running on the desktop goes green shortly after resuming from suspend. I have a suspicion it is related to the timing between:

  1. when networking is 100% available (interfaces are up, routes are established, DNS works, etc)
  2. when the Nextcloud desktop client first tries to connect to the server

The desktop is hardwired and the laptop is on wifi.

Again, just a suspicion... I haven't debugged this carefully.

UPDATE Sep 8 2023: I think the problem with the Nextcloud client on my laptop is because this script is installed. It is a hack for some System76 laptops to work around a problem with wifi hardware. It is fired upon resume from sleep, pauses, then restarts NetworkManager. It's odd that this System76 hack doesn't appear to affect my Signal private messenger desktop client, because it makes the Nextcloud client take a couple minutes to reconnect. Now I use a systemd script to kill the Nextcloud client before suspend. On resume, my script waits a few seconds, then starts the Nextcloud client. Seems to work well enough for a hack to work around a hack to work around a wifi hardware issue.

owenjm commented 1 year ago

The comment above about changing proxy settings suggested this quick and dirty fix:

diff --git a/src/gui/creds/webflowcredentials.cpp b/src/gui/creds/webflowcredentials.cpp
index 9958d1b7d..c3f138038 100644
--- a/src/gui/creds/webflowcredentials.cpp
+++ b/src/gui/creds/webflowcredentials.cpp
@@ -13,6 +13,7 @@
 #include <QLabel>

 #include "accessmanager.h"
+#include "accountmanager.h"
 #include "account.h"
 #include "configfile.h"
 #include "theme.h"
@@ -227,6 +228,10 @@ bool WebFlowCredentials::stillValid(QNetworkReply *reply) {
     if (reply->error() != QNetworkReply::NoError) {
         qCWarning(lcWebFlowCredentials()) << reply->error();
         qCWarning(lcWebFlowCredentials()) << reply->errorString();
+        const auto accounts = AccountManager::instance()->accounts();
+       for (auto account : accounts) {
+           account->freshConnectionAttempt();
+       }
     }
     return (reply->error() != QNetworkReply::AuthenticationRequiredError);
 }

(This is exactly what's called when the proxy is changed in gui/networksettings.cpp.)

This works without issues for me. It makes sense that if there's a credential error we should reconnect, but from a quick skim of the code, it seems there's no way to trigger a new connection attempt to the server after a validation error. Once there's a network session error we just end up stuck. (Note that we never seem to hit the code thrown into gui/accountstate.cpp, lines 302 and following, that was added to try to catch similar issues. Not entirely sure why.)

I've only just started using Nextcloud, but what I've observed agrees with the comment immediately above mine. This issue only happens when wireless network connectivity is lost. It can be easily reproduced on wifi by pausing sync, disconnecting the network, waiting a few seconds, reconnecting the network and resuming sync (suspend/resume is irrelevant, it's the network disconnection that goes along with suspend that seems to matter IME). This only happens on wifi, not on ethernet (even after manually disconnecting and reconnecting the ethernet network).

Can anyone confirm that this fixes the problem?

(also linking in #4084, as I agree that it may be the same issue.)

nursoda commented 1 year ago

Could you share your test build (elf binary?) or should I try building?

owenjm commented 1 year ago

Best to build from source if you can:

The build dependencies are a little undocumented. For Ubuntu 22.04, I needed to install the following packages to get the client working correctly (including showing the main dialog window). Other distros will probably need something similar:

sudo apt install extra-cmake-modules libqt5quickwidgets5 libqt5quickcontrols2-5 libqt5quick5 qml-module-qt-labs-platform libkf5kio-dev libkf5config-dev qtwebengine5-dev libqt5webview5-dev libqt5webenginewidgets5 libqt5webengine5 libqt5webengine-data libqt5webenginecore5 doxygen sphinx-common qttools5-dev qttools5-dev-tools qtbase5-private-dev qtbase5-dev libqt5gui5 libkf5archive-dev qtquickcontrols2-5-dev libqt5websockets5-dev qml-module-qtquick-layouts qml-module-qtquick-dialogs qml-module-qtquick-controls qml-module-qtquick-controls2 qml-module-qtquick2 libqt5quick5 libqt5quickwidgets5 libqt5quickcontrols2-5 qtquickcontrols2-5-dev qtquickcontrols2-5-private-dev qml-module-qt-labs-platform libqt5quick5 libqt5quickwidgets5 libqt5quickcontrols2-5 qtquickcontrols2-5-dev qtquickcontrols2-5-private-dev
meonkeys commented 1 year ago

@owenjm wrote:

this quick and dirty fix

Nice!

Does that try to connect once, or repeatedly? The desktop client should try to connect repeatedly with a logarithmic backoff between attempts, IMHO.

owenjm commented 1 year ago

Does that try to connect once, or repeatedly? The desktop client should try to connect repeatedly with a logarithmic backoff between attempts, IMHO.

It should just be a single attempt each time there's an validation error. The code will call AccountState::freshConnectionAttempt():

void AccountState::freshConnectionAttempt()
{
    if (isConnected())
        setState(Disconnected);
    checkConnectivity();
}

And then AccountState::checkConnectivity(), with state = disconnected, will send us straight to the code that was added a while back in order to catch and fix some very similar issues:

(from within that function, and just look at the comments that were added for the disconnected case ... :)

if (isConnected()) {
        // Use a small authed propfind as a minimal ping when we're
        // already connected.
        conValidator->checkAuthentication();
    } else {
        // Check the server and then the auth.

        // Let's try this for all OS and see if it fixes the Qt issues we have on Linux  #4720 #3888 #4051
        //#ifdef Q_OS_WIN
        // There seems to be a bug in Qt on Windows where QNAM sometimes stops
        // working correctly after the computer woke up from sleep. See #2895 #2899
        // and #2973.
        // As an attempted workaround, reset the QNAM regularly if the account is
        // disconnected.
        account()->resetNetworkAccessManager();

        // If we don't reset the ssl config a second CheckServerJob can produce a
        // ssl config that does not have a sensible certificate chain.
        account()->setSslConfiguration(QSslConfiguration());
        //#endif
        conValidator->checkServerAndAuth();
    }

The problem was that we weren't hitting that code earlier, because we were still coming up as connected, but with a network session error.

I haven't debugged it any more than this -- it's maybe (?) possible that better checks in the checkAuthentication() routine would also fix this? But if the bug is stemming from an issue with QNAM as the code comments above suggest, then I think this is the right way to handle this.

github-actions[bot] commented 1 year ago

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!

mayonezo commented 1 year ago

Problem still persists.

github-actions[bot] commented 1 year ago

This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!

arturi commented 1 year ago

Unfortunately, still getting problems on Fedora 38. Less than before, but very unreliable still: at any point after sleep/wakeup sync can stop working, toggling proxy on/off in settings makes it work again.