Owncloud client cannot login

I guess you’ll need to insert it in the DB manually. It should be there anyway.
If you’re using the “default official” desktop client, you can check the ones set in https://github.com/owncloud/client/blob/5cbf60c6f4c3e57cfeb679bee6e9fb28c829a562/src/libsync/theme.cpp (other clients might use different values)

Ok gotcha. I’ll try it.

Thanks!

Ok, definitely making progress!!!

It now allows me to authorize the app. The ownCloud server page now says: The application was authorized successfully. You can now close this window.

But the desktop client doesnt seem to get the message. It simply sits there with the message: “Reopen browser”, but it doesnt continue the setup. If I click Reopen Browser, it starts the authorization process again.

The redirect url is set to http://localhost:* . I would assume thats correct? Whats the next step here?

The correct client id and secret can be found here:

Can you check your database that the values match?

Yes, they match perfectly. That is what I used. I manually updated the database with those values.

The authorization is happening, but the desktop client doesn’t seem to get the message. It simply won’t move forward in the process.

I do have the callback URL as http://localhost:*

What am I missing?

If things match correctly, have a look at the desktop client logs after you made the progress.
Additionally I would recommend to have the log level set to 0 on the owncloud instance, that should give you some more hints what is happening on the server side.
Also check your apache access log that the requests from the client arrive properly at the server

Something funky is definitely going on.

In apache access logs, I see this repeated statement (seems like it keeps retrying but failing with a 401 - Unauthorized):

xxx.xxx.xxx.xxx - - [30/Jun/2019:23:50:27 +0000] “PROPFIND /remote.php/webdav/ HTTP/1.1” 401 1204 “-” “Mozilla/5.0 (Macintosh) mirall/2.5.4 (build 11456)”
xxx.xxx.xxx.xxx - xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69 [30/Jun/2019:23:50:28 +0000] “POST /index.php/apps/oauth2/api/v1/token HTTP/1.1” 200 4273 “-” “Mozilla/5.0 (Macintosh) mirall/2.5.4 (build 11456)”
xxx.xxx.xxx.xxx - - [30/Jun/2019:23:50:28 +0000] “GET /ocs/v2.php/apps/notifications/api/v1/notifications?format=json HTTP/1.1” 200 1022 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36”
xxx.xxx.xxx.xxx - - [30/Jun/2019:23:50:28 +0000] “PROPFIND /remote.php/webdav/ HTTP/1.1” 401 1204 “-” “Mozilla/5.0 (Macintosh) mirall/2.5.4 (build 11456)”
xxx.xxx.xxx.xxx - xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69 [30/Jun/2019:23:50:28 +0000] “POST /index.php/apps/oauth2/api/v1/token HTTP/1.1” 200 4273 “-” “Mozilla/5.0 (Macintosh) mirall/2.5.4 (build 11456)”

Ho do I turn on the logs on the client side on a mac? I don’t see any options in the owncloud client settings?

The repeated 401 errors only seem to happen while the owncloud client is open. After doing the oauth2 authentication, the client goes back to “Reopen browser”, but a tail -f on the apache access log shows a constant stream of 401 errors like the client keeps retrying. As soon as I close the client window, the 401 errors stop.

So I think now its just resolving the 401 and I got this beat.

Ok, got the client logging working. Seems to be the client-side of the same 401 error. At least that confirms it:

|06-30 20:16:56:409 [ warning sync.credentials.http ]:|Stop request: Authentication failed for  "https://cloud.mycloud.com/remote.php/webdav/"|
|---|---|
|06-30 20:16:56:409 [ info sync.credentials.http ]:|Refreshing token|
|06-30 20:16:56:410 [ info sync.accessmanager ]:|4 "" "https://cloud.mycloud.com/index.php/apps/oauth2/api/v1/token" has X-Request-ID "72435ce9-5c69-4e91-87e4-9bc9b85c8fc1"|
|06-30 20:16:56:410 [ info sync.networkjob ]:|OCC::SimpleNetworkJob created for "https://cloud.mycloud.com" + "" ""|
|06-30 20:16:56:724 [ info sync.networkjob ]:|Restarting "PROPFIND" QUrl("https://cloud.mycloud.com/remote.php/webdav/")|
|06-30 20:16:56:724 [ info sync.accessmanager ]:|6 "PROPFIND" "https://cloud.mycloud.com/remote.php/webdav/" has X-Request-ID "1674f316-22a1-4fd1-8411-4682ce15222d"|
|06-30 20:16:56:846 [ warning sync.credentials.http ]:|Stop request: Authentication failed for  "https://cloud.mycloud.com/remote.php/webdav/"|
|06-30 20:16:56:846 [ info sync.credentials.http ]:|Refreshing token|
|06-30 20:16:56:847 [ info sync.accessmanager ]:|4 "" "https://cloud.mycloud.com/index.php/apps/oauth2/api/v1/token" has X-Request-ID "4b95c1b7-8940-495e-9c8d-43ae71db4bca"|
|06-30 20:16:56:847 [ info sync.networkjob ]:|OCC::SimpleNetworkJob created for "https://cloud.mycloud.com" + "" ""|
|06-30 20:16:57:167 [ info sync.networkjob ]:|Restarting "PROPFIND" QUrl("https://cloud.mycloud.com/remote.php/webdav/")|
|06-30 20:16:57:168 [ info sync.accessmanager ]:|6 "PROPFIND" "https://cloud.mycloud.com/remote.php/webdav/" has X-Request-ID "75a9fa58-fd6b-4991-bb4f-e266f95fd3e7"|

I GOT IT WORKING!

I needed to add this to the Apache config for this vhost:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

But I don’t understand why. This was working all along and then suddenly stopped working. No configuration changes.

Well, I guess I shouldn’t complain.

Thanks a ton for your help! I really appreciate it!

1 Like

Hey,

i did the following search https://central.owncloud.org/search?q=“SetEnvIf%20Authorization” and found the following quite old FAQ mentioning that this is required since longer time for the client in “normal” operation:

Maybe this is now also required for Oauth2?

1 Like

Not really sure. But the protocol generally wouldn’t change from one day to the next. Nothing on the server changed, unless it was an updated client (This did start when I installed a new client on a new macbook).

So maybe that new client is now using the updated protocol? Not sure.

Thank you so much @ac1dr41n for sharing how you fixed it. I added it to my apache config and it works fine.

Fort WHM/cpanel web hosters, doing this is both complicated and flexible:

  1. Navigate to /etc/apache2/conf.d/userdata/ssl/2_4/username/FQDN.com (replace username and FQDN with your own information)
  2. Create a file with any name you like. I called mine owncloud_auth.conf (filename must in .conf)
  3. Edit the file and add the one line @ac1dr41n told us about above.
  4. Save the file.
  5. Run this command to rebuild the apache config files (the way WHM works is it compiles all the .conf files in a variety of folders and makes a single apache.conf…this allows each account on the the server to have their own “vhost” file): /usr/local/cpanel/scripts/rebuildhttpdconf
  6. Run this command to restart apache so it can read the new config: /usr/local/cpanel/scripts/restartsrv_httpd

All done!

WHM documentation that discusses the apache config include files and the two commands: https://documentation.cpanel.net/display/EA4/Modify+Apache+Virtual+Hosts+with+Include+Files

Happy synching!

1 Like

I had the same problem with client access after removing the oauth2 default clients ids in the administration settings > authentication.
What I did was just

  • Make a dbdump

  • DROP the oauth2 tables (4 tables) of the OC DB

  • Create a sql file copying the oauth2 tables creation from the dbdump file

  • Importing the sql file into the OC DB in order to create the oauth2 tables without any value on it and

  • Finally I ran the migrate command using occ (sudo -u www-data php occ migrations:execute oauth2 20170329194544) where 20170329194544 is the migration version which have the default ids for the oauth2 clients
    After that all the user were able to register the desktop and mobile clients
    My OC version is 10.4.3 running on a Debian 10 with apache.

2 Likes

Hi, I’m trying to do the same, how did you attempt to change the client id and the secret? Thank you.

Hi,
I have the same problem, but in my case all the above solution proposales have not worked.
I am still stuck with the 401 Error. I get the authorization page and I can authorize the request, but then the Desktop Client does not move forward in the process.
I am on owncloud server 10.6.0.5 and it runs on a web hoster.
My Config.php:
`<?php
$CONFIG = array (
‘instanceid’ => ‘’,
‘passwordsalt’ => '
’,
‘secret’ => '
’,
‘trusted_domains’ =>
array (
0 => '
..de’,
1 => '
**.
.de’,
),
‘datadirectory’ => ‘/kunden/homepages//htdocs/data-wolke’,
‘overwrite.cli.url’ => 'https://****.
.de’,
‘htaccess.RewriteBase’ => ‘/’,
‘dbtype’ => ‘mysql’,
‘version’ => ‘10.6.0.5’,
‘dbname’ => ‘’,
‘dbhost’ => '
.db.*.’,
‘dbtableprefix’ => ‘oc_’,
‘dbuser’ => 'dbo
’,
‘dbpassword’ => ‘’,
‘logtimezone’ => ‘CET’,
‘installed’ => true,
‘appstore.experimental.enabled’ => false,
‘theme’ => ‘’,
‘maintenance’ => false,
‘debug’ => false,
‘loglevel’ => 0,
‘log_rotate_size’ => 10485760,
‘trashbin_retention_obligation’ => ‘5, 10’,
‘default_language’ => ‘de’,
‘defaultapp’ => ‘calendar’,
‘mail_from_address’ => ‘owncloud’,
‘mail_smtpmode’ => ‘smtp’,
‘mail_domain’ => '
’,
‘mail_smtpsecure’ => ‘tls’,
‘mail_smtpauth’ => 1,
‘mail_smtpauthtype’ => ‘PLAIN’,
‘mail_smtphost’ => '
.***.de’,
‘mail_smtpport’ => ‘587’,
‘mail_smtpname’ => '
’,
‘mail_smtppassword’ => '
*’,
);

My htaccess with the changes:
`


SetEnvIfNoCase ^Authorization$ “(.+)” XAUTHORIZATION=1 RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION </IfModule> <IfModule mod_lsapi.c> SetEnvIfNoCase ^Authorization “(.+)” XAUTHORIZATION=$1
RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION


CGIPassAuth on
SetEnvIf Authorization “(.*)” HTTP_AUTHORIZATION=$1
SetEnvIfNoCase Authorization “(.+)” HTTP_AUTHORIZATION=$1

  <IfModule mod_env.c>
# Add security and privacy related headers
Header      unset X-Content-Type-Options
Header always set X-Content-Type-Options "nosniff"
Header      unset X-XSS-Protection
Header always set X-XSS-Protection "1; mode=block"
Header      unset X-Robots-Tag
Header always set X-Robots-Tag "none"
Header      unset X-Frame-Options
Header always set X-Frame-Options "SAMEORIGIN"
Header      unset X-Download-Options
Header always set X-Download-Options "noopen"
Header      unset X-Permitted-Cross-Domain-Policies
Header always set X-Permitted-Cross-Domain-Policies "none"
SetEnv modHeadersAvailable true
  </IfModule>

  # Let browsers cache CSS, JS files for half a year
  <FilesMatch "\.(css|js)$">
Header      unset Cache-Control
Header always set Cache-Control "max-age=15778463"
  </FilesMatch>
  
  # Let browsers cache WOFF files for a week
  <FilesMatch "\.woff$">
Header      unset Cache-Control
Header always set Cache-Control "max-age=604800"
  </FilesMatch>
</IfModule>

<IfModule mod_php5.c>
php_value always_populate_raw_post_data -1
php_value upload_max_filesize 513M
php_value post_max_size 513M
php_value memory_limit 512M
php_value mbstring.func_overload 0
php_value default_charset 'UTF-8'
php_value output_buffering 0
<IfModule mod_env.c>
  SetEnv htaccessWorking true
</IfModule>
</IfModule>

<IfModule mod_php7.c>
php_value upload_max_filesize 513M
php_value post_max_size 513M
php_value memory_limit 512M
php_value mbstring.func_overload 0
php_value default_charset 'UTF-8'
php_value output_buffering 0
<IfModule mod_env.c>
  SetEnv htaccessWorking true
</IfModule>
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates|changelog)/.* - [R=404,L]
  RewriteRule ^core/signature\.json - [R=404,L]
  RewriteRule ^(?:core/skeleton)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
<IfModule mod_mime.c>
  AddType image/svg+xml svg svgz
  AddEncoding gzip svgz
</IfModule>
<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>
AddDefaultCharset utf-8
Options -Indexes
<IfModule pagespeed_module>
  ModPagespeed Off
</IfModule>
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 //core/templates/403.php
ErrorDocument 404 //core/templates/404.php
<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteRule ^favicon.ico$ core/img/favicon.ico [L]
  RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
  RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff|ico|jpg|jpeg|json)$
  RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$
  RewriteCond %{REQUEST_FILENAME} !/robots.txt
  RewriteCond %{REQUEST_FILENAME} !/remote.php
  RewriteCond %{REQUEST_FILENAME} !/public.php
  RewriteCond %{REQUEST_FILENAME} !/cron.php
  RewriteCond %{REQUEST_FILENAME} !/core/ajax/update.php
  RewriteCond %{REQUEST_FILENAME} !/status.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v1.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v2.php
  RewriteCond %{REQUEST_FILENAME} !/updater/
  RewriteCond %{REQUEST_FILENAME} !/ocs-provider/
  RewriteCond %{REQUEST_FILENAME} !/ocm-provider/
  RewriteCond %{REQUEST_URI} !^/.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /
  <IfModule mod_env.c>
SetEnv front_controller_active true
<IfModule mod_dir.c>
  DirectorySlash off
</IfModule>
  </IfModule>
</IfModule>

Can please somebody help me to find the mistake :slight_smile:

Regards

I found another work around. I installed the desktop client version 2.3.4 first. Logged in with an app-password and start the sysnchronization. Afterwards I followed the upgrade path of the desktop client to the current version. So it still works.
Unfortunately I do not have an idea what is wrong with my installation.
Regards,

1 Like