[Solved] Can't login when using DNS Alias

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 20.0.6
Operating system and version (eg, Ubuntu 20.04): Raspberry PI OS (Docker container)
Apache or nginx version (eg, Apache 2.4.25): nginx 1.14.2
PHP version (eg, 7.4): 7.3

The issue you are facing:

I am using duckdns for a dynamic DNS, but I also have my own domain pointing at the duckdns domain. When using the cloud.myname.duckdns.org everything works fine, but when using cloud.mydomain.tld (which has an ALIAS record pointing to the duckdns address), I am unable to get past the login screen. Every time I try to login the page reloads. I’m guessing there are some redirection problems, but I can’t see anything in the logs.

Is this the first time you’ve seen this error? (Y/N):

Steps to replicate it:

  1. Setup nextcloud in a Docker container and use the nginx configuration from the documentation
  2. Create a duckdns subdomain
  3. Add an ALIAS or CNAME record from a subdomain on another DNS server to the duckdns subdomain
  4. Try to login using the new domain name

The output of your Nextcloud log in Admin > Logging:

No new log messages were outputted when trying to log in

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/home/pi/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/home/pi/nextcloud/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'instanceid' => '...',
  'passwordsalt' => '...',
  'secret' => '...',
  'trusted_domains' =>
  array (
    0 => 'cloud.mydomain.xyz',
    1 => 'cloud.myname.duckdns.org',
  ),
  'datadirectory' => '/home/pi/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '20.0.6.1',
  'overwrite.cli.url' => 'https://cloud.myname.xyz',
  'dbname' => 'nextcloud',
  'dbhost' => '172.25.0.11',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => '...',
  'installed' => true,
  'appstoreenabled' => true,
);

The output of your Apache/nginx/system log in /var/log/____:

No new log messages here either

Edit: The issue no longer occurs when using a CNAME record instead of ALIAS. I thought I had already tried this, but the browser probably had cached the DNS resolution. So in case anyone else runs into the same problem, make sure you are using a CNAME record and not a web alias.

I am using a similar setup, tho everytime I load nextcloud using a Private Tab, or I log out I am greeted with a Message telling me that there have been to many failed login attempts from that IP. I get that message on different PCs with different IPs, but I guess thats due to my Nginx Proxy Manager setup, as each request has its IP as an origination IP.

  • Cloudflare with Zero Trust Tunnel and Nginx Proxy Manager for Remote access
  • Pihole with a Local DNS Records (A/AAAA) and the same Nginx Proxy Manager, so I don’t have to leave my network if I use it internally

As I read your initial post I also check out the CNAME record, but in my case the Domain and the Target would be the same which Pihole prohibits.

I also checked the logs in var/log/**/*.log, but nothing, also nothing is visible in the containers log.

Did you figure out the root cause of the issue.