@sfadschm Can you include a bit more of the log file before that first line, so we can check what went on there? Also, what is the time of "sleep" and the "wake up" time?

@erikjv Extended the gist accordingly. It looks like 8:33 was the time that the computer went into deep sleep. Before that, there is a long period of "Host XXX not found" log entries, likely because WLAN was inactive during sleep.
After waking up the computer on 10:59, we see some "Host not found" errors again, likely because it takes some time for the computer to reconnect to the WLAN network.

Unfortunately, there does not seem to be any indication in the Windows setting that tell after which time the OS goes into "deep sleep". "Closing the lid" is simply set to "sleep", yet behaviour differs depending on whether it is opened/woken up 30 mins later (no OC issue, Win11 password prompt shows up immediately) or after a longer time of ~2 h (OC logs out).

It appears that the "deep sleep" I was talking about is actually called "hibernate" in Windows. I will check BIOS setting to see if that is scheduled after a certain time of "sleep".

Addendum:
Today the same behavior appeared after a normal sleep of about 30min. As far as I can tell for the first time.

Unfortunately, logs were turned off. Will add some more if it happens again.

Next time it happens, can you include The last few (20?) lines before the ConnectionValidator::StatusNotFound messages?

Updated the GIST again to include anything between the last "#### Discovery End ####" and the first "#### Discovery Start ####". The first "ConnectionValidator::StatusNotFound" appears on line 69.

Here goes the link again:
https://gist.github.com/sfadschm/21d18d9306627f951f101d03625d6766

Will add another gist when it appears again.

What happens in sequence is:

• when Windows wakes up, the network becomes available shortly after the applications are woken up (DHCP?)
• also, when Windows goes back to sleep, the network disappears first before the applications are put to sleep (probably so they can handle any incomplete network requests)
• then, when the last token refresh is long enough in the past, the authentication token needs refreshing
• then, when this succeeded, the client tries to do a request using the new token
• then, when the network disappears before any response has been received, and stays unavailable for the next 2 retries, the user is logged out:

24-11-13 07:48:22:404 [ debug sync.credentials.oauth ]  [ OCC::AccountBasedOAuth::fetchWellKnown ]:     starting CheckServerJob before fetching "/.well-known/openid-configuration"
24-11-13 07:48:22:451 [ info sync.httplogger ]: "74a8fb13-7452-4ce4-b0d6-f20e3880b950: Response: GET 0 (Error: Network unreachable,46ms) https://ocis.cloud.de/status.php Header: { } Data: []"
24-11-13 07:48:22:451 [ warning sync.checkserverjob ]:  error: status.php replied 0
24-11-13 07:48:22:451 [ debug sync.credentials.oauth ]  [ OCC::AccountBasedOAuth::fetchWellKnown::::operator() ]:       CheckServerJob failed, error: "Invalid HTTP status code received for status.php: 0"
24-11-13 07:48:22:451 [ warning sync.credentials.http ]:        Too many failed refreshes 3 -> log out

(The previous 2 attempts are in the log file right in front of this snippet.)

The fix is not to retry those jobs when there is no network available, or to not invalidate the credentials when the network disappeared.

Thanks for the analysis ! The described sequence of events sounds like what Windows "modern standby" is intended to do, so seems legit.

Rechecking connection after a failed attempt seems like the more natural approach to me.

Btw. What is the lifetime of the authentication token? Because this error on some days occured 3-5 times. Such short lifetime appears a little over the top on a first glance.

A draft fix has been implemented by @erikjv - feel free to grab the client from here - https://github.com/owncloud/client/actions/runs/11892365157?pr=11984

Note: this also has a new feature that you might be interested in: in the settings there is now an option "Move remotely deleted files to the local trash bin instead of deleting them".

Will test it for a few days and give feedback if the error occurs again. The implementation looks robust however.

The trash bin feature sounds great!

No occurence so far.