Trusted_domain not resolving

Hello,

First time posting here, so sorry if I am missing any of the standard etiquette.

I’ve been struggling getting NC 16 working on an Ubuntu 18.0.4 based Azure VM the past couple days. I finally have everything looking like it’s working for the most part, however I cannot get the trusted_domains setting to stick. I’ve looked at everything I can find that seems relevant here and none of the solutions have handled my problem.

I did start on one path (using Nginx ) which ended up not working, then started over using Apache2. On first attempt, I couldn’t get several things working, so I scrapped it all and started over. Now on second attempt I’ve gotten all the way to having a UI that I can access using http://publicIPAddress/nextcloud/, however I cannot get it working on https with my custom domain. I do have the domain correctly setup with DNS records, and everything checks out using the tools I can think of, but it just keeps giving me this:

nc_trusted_domains

So here’s what my config.php file says right now:

$CONFIG = array (
  'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => 'cloud.exampledomain.org',
    2 => 'cloud.exampledomain.org/nextcloud/',
    3 => 'publicIPAddress',
  ),
  'datadirectory' => '/var/www/html/nextcloud/data',
  'dbtype' => 'sqlite3',
  'version' => '16.0.3.0',
  'overwrite.cli.url' => 'https://cloud.exampledomain.org/nextcloud/',
  'installed' => true,
  'instanceid' => 'ocf1qjz3z0nu',
);

EDIT: I got this file by using occ and have not manually modified anything except the overwrite.cli.url field. Everything else is as written by occ.

Also, all of the various SSL config what handled with certbot & LetsEncrypt automatically.

I’m not very well versed with linux (which doesn’t help) but I have seen some similar topics that are as yet still unanswered.

Any advice is greatly appreciated!

Array index #2 in your trusted domains is unnecessary (possibly not supported either since it’s a path and not a domain?) as it’s covered by index #1. I would remove it.

Are you using a reverse proxy? If so, the domain or IP the proxy is using to contact the backend server must be trusted (for example the server’s local IP or hostname).

Also just a couple things I would mention that I noticed above. You’ll want to move your data directory out from under the web folders and put it somewhere such as /srv/nextcloud/data. And I’m not sure what issues with performance or limitations you may run into using SQLite.

So I removed #2. That was one that I added just to try it, but it doesn’t make any difference. I also added the local IP for the VM to the trusted domains, but that hasn’t done anything either.

I’m not entirely sure how Azure handles the traffic. I know that there is a public IP that is connected directly to the CM, but it does also have a cloud vnet. This is in the 10.0.x.x/24 range, and I added this just in case, although I don’t think that will do anything either because I think this vnic is only used for communicating with other Azure resources, and not the client.

I will definitely move this, but for the moment I’m most concerned with getting https to work with my domain. :confused: Also, I’m a little confused by the sqlite3 entry because I configured everything for MariaDB (so I would expect mysql probably)…

I think you need a domain who’ve like .com .something other, because my Windows Network Domain which is look like “mycompany” ore “localhost” also doesn’t work.

PS: Im sorry for my Englisch, I will work on it.

Check your web server logs to see what page is being requested.

So I looked through all the logs I though could be relevant, and I haven’t found anything substantial.

From what I can tell, the requests do correctly go to, web-root (in my case /var/www/html/nextcloud/) and are then fetching index.php and so one with the various .css and .js scripts related to the index page.

I did a side-by-side comparison using MS Edge and Chrome (Incognito) with everything being cleared between tests. I’ve dumped virtually everything here in pastebin, so you can check them out.

I did find some blocks in the ufw log, however they were all for the same Chinese IP address, nothing even close to the IPs I would be looking for. Also, these IPs were logged again while I was testing and monitoring the logs.

Oh, so one last strange thing (that I suppose could create issues) is that I have 2 “nextcloud” directories in /var/www

Here’s a little tree of what I mean:

tree /var/www/
├── html
│   └── nextcloud
│       ├── 3rdparty
│       ├── AUTHORS
│       ├── COPYING
│       ├── apps
│       ├── config
│       ├── console.php
│       ├── core
│       ├── cron.php
│       ├── data
│       ├── index.html
│       ├── index.php
│       ├── lib
│       ├── occ
│       ├── ocm-provider
│       ├── ocs
│       ├── ocs-provider
│       ├── public.php
│       ├── remote.php
│       ├── resources
│       ├── robots.txt
│       ├── settings
│       ├── status.php
│       ├── themes
│       ├── updater
│       └── version.php
└── nextcloud
    ├── 3rdparty
    ├── AUTHORS
    ├── COPYING
    ├── apps
    ├── config
    ├── console.php
    ├── core
    ├── cron.php
    ├── data
    ├── index.html
    ├── index.php
    ├── lib
    ├── occ
    ├── ocm-provider
    ├── ocs
    ├── ocs-provider
    ├── public.php
    ├── remote.php
    ├── resources
    ├── robots.txt
    ├── settings
    ├── status.php
    ├── themes
    ├── updater
    └── version.php

As far as I know, this isn’t a problem, but I did find an entry in one of the logs in this directory… so maybe its pulling portions of data from the wrong location…? :thinking:

Just in case, here’s the line from /var/www/nextcloud/data/nextcloud.log

{"reqId":"H4gQaaf1gyD3dn0lhoz9","level":3,"time":"2019-07-15T20:16:22+00:00","remoteAddr":"xxx.xxx.xxx.xxx","user":"admin","app":"index","method":"GET","url":"\/nextcloud\/index.php\/apps\/theming\/img\/core\/filetypes\/folder.svg?v=0","message":{"Exception":"OCP\\Files\\NotPermittedException","Message":"Could not create folder","Code":0,"Trace":[{"file":"\/var\/www\/nextcloud\/lib\/private\/Files\/AppData\/AppData.php","line":155,"function":"newFolder","class":"OC\\Files\\Node\\Folder","type":"->","args":["0"]},{"file":"\/var\/www\/nextcloud\/apps\/theming\/lib\/ImageManager.php","line":155,"function":"newFolder","class":"OC\\Files\\AppData\\AppData","type":"->","args":["0"]},{"file":"\/var\/www\/nextcloud\/apps\/theming\/lib\/ImageManager.php","line":170,"function":"getCacheFolder","class":"OCA\\Theming\\ImageManager","type":"->","args":[]},{"file":"\/var\/www\/nextcloud\/apps\/theming\/lib\/Controller\/IconController.php","line":87,"function":"getCachedImage","class":"OCA\\Theming\\ImageManager","type":"->","args":["icon-core-filetypes_folder.svg"]},{"file":"\/var\/www\/nextcloud\/lib\/private\/AppFramework\/Http\/Dispatcher.php","line":166,"function":"getThemedIcon","class":"OCA\\Theming\\Controller\\IconController","type":"->","args":["core","filetypes\/folder.svg"]},{"file":"\/var\/www\/nextcloud\/lib\/private\/AppFramework\/Http\/Dispatcher.php","line":99,"function":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->","args":[{"__class__":"OCA\\Theming\\Controller\\IconController"},"getThemedIcon"]},{"file":"\/var\/www\/nextcloud\/lib\/private\/AppFramework\/App.php","line":126,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->","args":[{"__class__":"OCA\\Theming\\Controller\\IconController"},"getThemedIcon"]},{"file":"\/var\/www\/nextcloud\/lib\/private\/AppFramework\/Routing\/RouteActionHandler.php","line":47,"function":"main","class":"OC\\AppFramework\\App","type":"::","args":["OCA\\Theming\\Controller\\IconController","getThemedIcon",{"__class__":"OC\\AppFramework\\DependencyInjection\\DIContainer"},{"app":"core","image":"filetypes\/folder.svg","_route":"theming.Icon.getThemedIcon"}]},{"function":"__invoke","class":"OC\\AppFramework\\Routing\\RouteActionHandler","type":"->","args":[{"app":"core","image":"filetypes\/folder.svg","_route":"theming.Icon.getThemedIcon"}]},{"file":"\/var\/www\/nextcloud\/lib\/private\/Route\/Router.php","line":297,"function":"call_user_func","args":[{"__class__":"OC\\AppFramework\\Routing\\RouteActionHandler"},{"app":"core","image":"filetypes\/folder.svg","_route":"theming.Icon.getThemedIcon"}]},{"file":"\/var\/www\/nextcloud\/lib\/base.php","line":975,"function":"match","class":"OC\\Route\\Router","type":"->","args":["\/apps\/theming\/img\/core\/filetypes\/folder.svg"]},{"file":"\/var\/www\/nextcloud\/index.php","line":42,"function":"handleRequest","class":"OC","type":"::","args":[]}],"File":"\/var\/www\/nextcloud\/lib\/private\/Files\/Node\/Folder.php","Line":162,"CustomMessage":"--"},"userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko\/20100101 Firefox\/67.0","version":"16.0.3.0"}

So, I decided to alter the other config.php file located at /var/www/nextcloud/config/config.php,
and lo and behold, this worked!

So what I’m trying to understand now, is which directory is actually being used!? :confused: It seems like the /var/www/html/… should be used, but also like it’s using /var/www/… so I’m a little bit lost.

That all being the case, is there a way to easily separate the conponents that are in use and determine if this directory (/var/www/html/nextcloud/…) can be deleted?

That would be a question for your web server configuration. But, I would hazard a guess that the one where your config changes take effect is the correct one. You should probably move/delete the other to avoid confusion.

You’re correct.

I’m going to close/mark this answered at this point because this particular point is resolved. I’m guessing that at some point, probably re-running the install via occ, i created a new dir that overwrote various config files.

Anyway, thanks and I’m sure I’ll be getting more help down the road. :sweat_smile: