Server: Login and grant access hangs on fresh NC18 Docker install

[samsalway]

Steps to reproduce

1. Setup a new Nextcloud Docker container (with Traefik reverse-proxy, not sure if that's relevant)
2. Follow the initial setup to create admin account
3. Attempt to login as admin

Expected behaviour

Should redirect to default page (app/files)

Actual behaviour

Web browser stays on the login page, but manually navigating to root URL loads normally (i.e. login has worked).

Server configuration

Operating system:
Docker 19.03.5 inside Ubuntu 18.04.3

Web server:
nextcloud docker container (not fpm version)

Database:
mariadb docker container

PHP version:
PHP 7.3.13

Nextcloud version:
18.0.0

Updated from an older Nextcloud/ownCloud or fresh install:
Fresh as bro

Where did you install Nextcloud from:
Docker container

Signing status:
No errors have been found.

List of activated apps:
Enabled:

• accessibility: 1.4.0
• activity: 2.11.0
• calendar: 2.0.1
• cloud_federation_api: 1.1.0
• comments: 1.8.0
• contacts: 3.1.6
• dav: 1.14.0
• federatedfilesharing: 1.8.0
• federation: 1.8.0
• files: 1.13.1
• files_external: 1.9.0
• files_pdfviewer: 1.7.0
• files_rightclick: 0.15.2
• files_sharing: 1.10.1
• files_trashbin: 1.8.0
• files_versions: 1.11.0
• files_videoplayer: 1.7.0
• firstrunwizard: 2.7.0
• logreader: 2.3.0
• lookup_server_connector: 1.6.0
• nextcloud_announcements: 1.7.0
• notes: 3.1.1
• notifications: 2.6.0
• oauth2: 1.6.0
• onlyoffice: 4.1.1
• password_policy: 1.8.0
• photos: 1.0.0
• privacy: 1.2.0
• provisioning_api: 1.8.0
• recommendations: 0.6.0
• serverinfo: 1.8.0
• settings: 1.0.0
• sharebymail: 1.8.0
• spreed: 8.0.0
• support: 1.1.0
• survey_client: 1.6.0
• systemtags: 1.8.0
• text: 2.0.0
• theming: 1.9.0
• twofactor_backupcodes: 1.7.0
• updatenotification: 1.8.0
• viewer: 1.2.0
• workflowengine: 2.0.0
  Disabled:
• admin_audit
• documentserver_community
• encryption
• mail
• user_ldap

Nextcloud configuration:

{
"system": {
"htaccess.RewriteBase": "/",
"memcache.local": "\OC\Memcache\APCu",
"apps_paths": [
{
"path": "/var/www/html/apps",
"url": "/apps",
"writable": false
},
{
"path": "/var/www/html/custom_apps",
"url": "/custom_apps",
"writable": true
}
],
"instanceid": "REMOVED SENSITIVE VALUE",
"objectstore": {
"class": "OC\Files\ObjectStore\S3",
"arguments": {
"bucket": "salway-nextcloud",
"autocreate": true,
"key": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"hostname": "sgp1.digitaloceanspaces.com",
"port": 443,
"use_ssl": true,
"region": "sgp1",
"use_path_style": false
}
},
"passwordsalt": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"cloud.salway.net"
],
"trusted_proxies": "REMOVED SENSITIVE VALUE",
"datadirectory": "REMOVED SENSITIVE VALUE",
"dbtype": "mysql",
"version": "18.0.0.10",
"overwrite.cli.url": "http://cloud.salway.net",
"dbname": "REMOVED SENSITIVE VALUE",
"dbhost": "REMOVED SENSITIVE VALUE",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"filelocking.enabled": false,
"maintenance": false,
"mail_from_address": "REMOVED SENSITIVE VALUE",
"mail_smtpmode": "smtp",
"mail_sendmailmode": "smtp",
"mail_domain": "REMOVED SENSITIVE VALUE"
}
}

Are you using external storage, if yes which one:
Yes, DigitalOcean Spaces, singapore.

Are you using encryption:
No

Are you using an external user-backend, if yes which one:
No

Client configuration

Browser:
Brave 1.2.42

Operating system:
Windows 8.1

Logs

Web server error log

Not sure how to do this with the docker container.

Nextcloud log (data/nextcloud.log)

It's huge, but nothing new gets logged during login attempts.

Browser log

THIS LOOKS LIKE A CLUE! (the last line)

JQMIGRATE: Migrate is installed, version 1.4.1
globals.js:66 Backbone is deprecated: please ship your own, this will be removed in Nextcloud 20
ne @ globals.js:66
globals.js:66 Handlebars is deprecated: please ship your own, this will be removed in Nextcloud 20
ne @ globals.js:66
/apps/theming/manifest?v=0:1 Manifest: property 'start_url' ignored, should be same origin as document.
login?clear=1:1 Refused to send form data to 'http://cloud.salway.net/' because it violates the following Content Security Policy directive: "form-action 'self'".

[abno85]

Same problem with an existing (bare-metal) installation of Nextcloud 17.0.2 behind an Apache reverse proxy.

I migrated a 15.0.11 installation from a Debian 9 installation to new Debian 10 container and upgraded Nextcloud from 15 -> 16 -> 17.
The former Debian 9 host now upgrades the connection to HTTPS and forwards it to the new Debian 10 container serving Nextcloud via HTTP.

Even though I added the following parameters to the config.php, I get the same browser error message as samsalway after submitting the login-form data.

'overwrite.cli.url' => 'https://nextcloud.address.tld/',
'overwritehost' => 'nextcloud.address.tld',
'overwriteprotocol' => 'https',
'overwritecondaddr' => '^192\\.168\\.123\\.1$', # IP of the reverse proxy
'overwritewebroot ' => '/',

After authenticating the login form does not automatically redirect to Nextcloud and all links inside the database (oc_activity) are generated as http links.

[kesselb]

https://github.com/nextcloud/server/issues/13713 and some of the referenced issues should help. I guess the overwritecondaddr is wrong here. You are actually looking for trusted_proxies.

[abno85]

Sorry, I forgot to paste that line, trusted_proxies was set as well:

'trusted_proxies' =>
  array (
    0 => '192.168.123.1',
  ),

But I just removed overwritecondaddr from my config and that seemed to do the trick!
No more errors and wrong URLs in the database, thank you!

[gu1ll0me]

Same here with HAProxy in front of NC18-Docker. Adding 'overwriteprotocol' => 'https', solve the problem for me.

[samsalway]

Wow, thanks for everyone's help. I had trusted_proxies set to '172.21.0.0/16' because that's the internal network traefik is using. I've added 'overwriteprotocol' => 'https', and while doing that I noticed 'overwrite.cli.url' => 'http://...' so I changed that to https too. Now everything works!

I wonder if this is a result of how Traefik does the automatic certificates with LetsEncrypt. I had it configured with automatic redirect and automatic certificates, which means the very first request gets redirected to https and gets a certificate error because there is no certificate yet. Meanwhile Traefik acquires the certificate and a few seconds later https works. I wonder if that first http request gets through to nextcloud and it seeds the config.php with the http URL. I'm massively speculating here but wouldn't be hard to test.

[samsalway]

I did some tests with another fresh docker install and only one change is required to fix the issue, as @michaudg said, 'overwriteprotocol' => 'https',.

[fredericrous]

I am using traefik in swarm as well. I didn't need to edit trusted_proxies. However I had to change overwrite.cli.url from http to https. I also set overwriteprotocol to https but I don't know if this one is needed. The issue occurred after upgrading from 17.x to 18.x. I am using the official nextcloud docker image. I hope update to nextcloud 19 won't reproduce the same issue..

[kesselb]

@samsalway so this was actually a configuration issue right?

[samsalway]

@kesselb yes, fixing the configuration is the solution. That was not obvious however, because the installation mostly works, it's just this one weird side effect that highlights the problem. Reading through the docker hub readme and nextcloud examples there is no mention of this configuration needing to be changed for https.

[kesselb]

https://github.com/docker-library/docs/blob/master/nextcloud/README.md#using-the-apache-image-behind-a-reverse-proxy-and-auto-configure-server-host-and-protocol?

[fredericrous]

so configuring OVERWRITEHOST and OVERWRITEPROTOCOL should do the trick? only for people using the official nextcloud image and not the linuxserver/nextcloud one that supports setting the PGID/PUID? I personally run the official image.
https://github.com/nextcloud/docker/pull/1048

[samsalway]

@kesselb who put that there! That's embarrassing 😳, obviously I didn't read everything I needed to.

@fredericrous yeah looks like that's what I should have done.

Thanks for the help, should I go ahead and close this?

[fredericrous]

@samsalway when you opened the issue that commit wasn't there 🤪

[steffres]

Putting 'overwriteprotocol' => 'https' into config.php also worked for my setup which consists of the official nextcloud docker image (right now v19) plus a traefik container in front as reverse proxy.