We run a Nectcloud instance on Hetzner and using Keycloak ID server witch allows SSO with SAML.
On the browser everything works great, but we can’t login into Nextcloud with the Desktop Client.
Android Client works too, but with the Desktop client the process stucks when I want to give Acces to the files.
The client shows then this state forever. The same siutation is when I using the app token instead of password. When I look in my settings I see there both Desktop and Android client are connected properly, so I assume the error is neither at the server or the Keycloak side. It must be a Desktop Client issue.
I have installed client Windows version: Version 2.5.1final (build 20181204).
And Ubuntu ppa version 2.5.1. It is the same issue.
Nextcloud Version is: Nextcloud 15.0.2
The usual way to enable app access is by setting-up individual app passwords, because they will
work wothout a 2FA dialog. Check-out Settings->Personal->Security->Devices and Sessions.
As far as I remember different ways to authenticate should be displayed.Choose user/password
and directly enter the account details instead of using this simplified authentication.
@j-ed if you read the issue carefully, you see that the same issue occurs with app token. O do you mean something else with “individual app passwords”.
I have in mind that “Grant access” is only shown if the simplified way of authentication has been selected, which means you enter you’ve already logged in via your web browser and want to create
a new app token on the fly.
If you’ve created an app token manually and want to use it, you have to choose alternative login via app token first
and enter the login and app token in a second step.
I’ve just logged-out and in by going that way on my PC and it worked like a charme and without any problem.
Due to the fact that there is always room for misunderstanding it is always better to asked twice
Have you tried to start the Nextcloud client from the command line providing the “–logwindow” command line switch? Maybe it prints-out valuable information about the root cause of the problem.
Is it necessary to upgrade to NC Server V15 to get the SSO Service work properly for NC Desktop Client V2.5.1 or should it also work with NC Server V13?
in our case we still stuck after putting the login credentionals in the Microsoft ADFS Login screen the Token is not accepted. that SSO service still works with many other SSO Applikations.
With NC Desktop Client V2.3.3.1 the ADFS Credential Login Page does not appear and we just see a whitescreen.
Could someone provide me please with the necessary structure of the NC Desktop Client Webtoken - How has the NC Desktop client “claim rule” must look like?? - maybe that´s why the Webtoken is not provided
I’m not meant the logging of the server, but the logging of the Nextcloud desktop client. It start logging what it is doing right after you’re starting it. So it might be possible that he helps to understand why it could login. Example
|[OCC::FolderMan::setupFolders |Setup folders from settings file|
|---|---|
|[OCC::defaultJournalMode |Detected filesystem "NTFS" for "C:/Users/<user>/Nextcloud/._sync_4bc7bcd5f0e.db"|
|[OCC::ConfigFile::setupDefaultExcludeFilePaths |Adding user defined ignore list to csync: "C:/Users/<user>/AppData/Roaming/Nextcloud/sync-exclude.lst"|
|[OCC::FolderMan::addFolderInternal |Adding folder to Folder Map OCC::Folder(0x1bd7b2f8660) "1"|
|[OCC::FolderMan::scheduleFolder |Schedule folder "1" to sync!|
|[OCC::FolderMan::scheduleFolder |Folder is not ready to sync, not scheduled!|
|[OCC::ownCloudGui::slotSyncStateChange |Sync state changed for folder "https://<nextcloud--server-fqdn>/remote.php/webdav/" : "Not yet Started"|
|[OCC::SyncJournalDb::checkConnect |sqlite3 version "3.24.0"|
|[OCC::SyncJournalDb::checkConnect |sqlite3 journal_mode= "wal"|
|[OCC::ClientProxy::setupQtProxyFromConfig |Set proxy configuration to use NO proxy|
|[OCC::WebFlowCredentials::fetchFromKeychain |Fetch from keyhchain!|
|[OCC::SocketApi::slotNewConnection |New connection QLocalSocket(0x1bd7b223430)|
|[OCC::SocketApi::slotNewConnection |New connection QLocalSocket(0x1bd7b222790)|
|[OCC::SocketApi::slotNewConnection |New connection QLocalSocket(0x1bd7b222c50)|
|[OCC::AccountState::slotCredentialsFetched |Fetched credentials for "https://<nextcloud-server-fqdn>" attempting to connect|
|[OCC::WebFlowCredentials::createQNAM |Get QNAM|
|---|---|
|[OCC::AccessManager::createRequest |2 "" "https://<nextcloud-server-fqdn>/status.php" has X-Request-ID "8178d6b2-3222-4c0c-b8dd-9742dcbd6e27"|
|[OCC::AbstractNetworkJob::start |OCC::CheckServerJob created for "https:/</nextcloud-server-fqdn>" + "status.php" "OCC::ConnectionValidator"|
|[OCC::WebFlowCredentials::slotFinished |request finished|
|[OCC::WebFlowCredentials::stillValid |Still valid?|
...
The only thing which catches my attention is the mixed writing of the login name “YMudasar”.
I don’t know if this has any effect in this case but it might be worse to test a login with only lowercase
characters or similar how the user has been created…
The ""Unknown error" at the end of the log seems also be no real error because I can see it
in my log file too, although I’m using a normal login/password authentication for the desktop client
app authentication.
