How to solve "Access through untrusted domain" when using DuckDNS and OMV/Docker


I am installing nextcloud on openmediavault as a docker image, using a domain name and using subfolders. Something like ‘’.

I am using the standard docker-compose file from openmediavault: [How-To] Nextcloud with Letsencrypt using OMV and docker-compose - Guides - openmediavault and of course I configured nginx proxy for the subdirectory as well as nextcloud config.php file for trusted domains.

This is working fine but is of course not safe as trusted domain contain a star instead of IPs or a domain name

$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'ocapj1ywa0lp',
  'passwordsalt' => 'XXX',
  'secret' => 'XXX',
  'trusted_domains' =>
  array (
    0 => '',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'nextcloud',
  'dbhost' => 'nextclouddb',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'oc_admin',
  'dbpassword' => 'apo3Y6kXTPkvguOTqyl9gBSjokWYDD',
  'installed' => true,
  'trusted_proxies' =>
  array (
    0 => 'swag',
  'overwritewebroot' => '/nextcloud',
  'overwrite.cli.url' => '',
  'trusted_domains' =>
  array (
    0 => '*',

But if I replace it with

'trusted_domains' =>
  array (
    0 => '',

Note: yes, trusted_domains are defined two time, but I can also merge it in a single entry with 0=> and 1=> but it has no impact at all on the final behavior.

Then I cannot log to nextcloud with the famous error “Access through untrusted domain”. I am looking for any log file where I can understand why the incoming request is rejected. It must have something to do with the use of swag as nextcloud works with a direct https access (and thus an untrusted certificate) or with that star.
But I can’t find any technical log explaining why it is rejected and how to solve it.

Here is the full docker-compose config, just in case:

version: "2"
    container_name: nextcloud
      - PUID=998
      - PGID=100
      - TZ=Europe/Paris #change Time Zone if needed
      - /srv/dev-disk-by-uuid/appdata/nextcloud/config:/config
      - /srv/dev-disk-by-uuid/appdata/nextcloud/data:/data
      - mariadb
    ports: # uncomment this and the next line if you want to bypass the proxy
      - 450:443
    restart: unless-stopped
    container_name: nextclouddb
      - PUID=998
      - PGID=100
      - MYSQL_ROOT_PASSWORD=mariadbpassword  #change password
      - TZ=Europe/Paris #Change Time Zone if needed
      - /srv/dev-disk-by-uuid/appdata/nextclouddb:/config
    restart: unless-stopped
    image: linuxserver/swag         #swag is the replacement for letsencrypt (see link below)
    container_name: swag
      - NET_ADMIN
      - PUID=998
      - PGID=100
      - TZ=Europe/Paris
      - #insert your domain name - yourdomain.url
      - SUBDOMAINS=www,
      - VALIDATION=http 
      - /srv/dev-disk-by-uuid/appdata/swag:/config
      - 10443:443
      - 10080:80
    restart: unless-stopped

As it works well by disabling the trusted_domains, I hope it is quite easy to fix !


In general the trusted_domain parameter need to be set to the name under which you’re going to access the server. It doesn’T contain the networks etc. from which you’re accessing the server. If you, by any kind, proxy an access and use an ip address in the configuration to access the server, that need to be added to the Nextcloud configuration too.
The log file of your web server should usually show from which ip address an access is coming and to which server or ip address it is going. So I would recommend to start there with your investigations.

Thank you for your answer.

I manage to find a clue by activating the verbose logs and having a look to nextcloud logs.
I don’t know for which reason (swag, nginx …) but the incoming url name was and not

I never have seen that in any tutorial I have found, it might have something to do with the subdomain from the docker-compose file, but even on the omv forum where this file is there is no mention of a required www. prefix.

But it seems to be working. I have a full backup, I will try it again from scratch to check if I manage to have it working again and if it was the proper fix to have all containers working together.

1 Like