desktop
desktop copied to clipboard
nextcloud
wake up from suspend - The specified configuration cannot be used.
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
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
- start sync client
- suspend coputer
- 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.
-
Client logfile: https://gist.github.com/Tealk/4be122cdcb13a74e3ff7ed723f6da067
-
Web server error log: No errors in the log
-
Server logfile: nextcloud log (data/nextcloud.log):
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 [[email protected]] 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 ]: "[email protected]" 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
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.
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}
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):
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.
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.
Same problem with nextcloud server v1.47.2 and nextcloud client v3.5.1git (git revision 930206f06c023f031008ea6ce511ee0fbe2e4ae1).
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.
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.
@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
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?
@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?
@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.
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.
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!
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.
This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!
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.
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
@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.
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
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
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.
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?
@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
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.
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.
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!