kitsab's picture

Hello,

I'm using Promox and installed the nextcloud-turnkey-15.2.1 to an LXC container.

I'm able to SSH into the machine.

I modified /var/www/nextcloud/config/config.php and added IPs from my local network.

  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'bkmpc.duckdns.org',
    2 => '192.168.1.240',
    3 => '192.168.1.252',
    4 => '192.168.1.230',
  ),
*192.168.1.204 is my nextcloud LXC IP address.

.252 is the Proxmox Server / .240 is my notebook / .230 is my tablet.

I restarted apache2 service, during my configuraton I also restared the LXC container a few times.

trying to access the web interface from my local network  leads into a screen which tells me that it is required to configure "trused_domains".

I try to access the webinterface by https://192.168.1.204/nextcloud or https://192.168.1.204/nextcloud:443 from my clients .230 or .240

I haven't got an idea what I can do, to configure the trusted domains correctly.

In my opinion it is already configured well, but still in accessable.

Thanks for tips and suggestions.

Best regards

Kitsab

Forum: 
Jeremy Davis's picture

It looks like the spam trap was catching you and that's probably why you couldn't edit your post. Anyway, I've added you to the "contributors" group so you should be able to skip most of the spam traps now. I also cleaned up one of the other threads and will also remove the other duplicate when I finish posting here. I also edited this one with the updated info for the IP typo.

So it seems like you misunderstand the notion of what the "trusted_domains" is/does. It sets the domains that your server can be contacted on, not the clients connecting! It protects your server from what is referred to as a Host Header Poisoning attack.

So if you want to connect to your nextcloud via IP address and/or bkmpc.duckdns.org, then it just needs to be like this:

'trusted_domains' => 
  array (
    0 => '192.168.1.204',
    1 => 'bkmpc.duckdns.org',
  ),

You'll need to restart Apache to apply the change. I.e.:

systemctl restart apache2

Note I removed localhost as there isn't much point of including localhost when you're running it on a headless server - without a web browser... Although you could always leave it there if you wanted, it won't do any harm...

kitsab's picture

Hello,

sorry for the late reaction, I was busy those days.
 

I already understood the meaning of trusted hosts. I have to add the devices from where I want to access the web interface to configure Nextcloud.

Target was to be able to configure nextcloud using the web interface.

I began with:

'trusted_domains' => 
  array (
    0 => '192.168.1.240', <-- it's my notebook 
    1 => '192.168.1.230', <- it is my tablet
  ),

I used those two devices as I was wondering why I couldn't open my web interface always hitting the issue "trusted domains are not configured well".

I added more and more IPs and finally localhost to try:

curl https://localhost/nextcloud -k -v

[code]

< Location: https://localhost/index.php/login
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Robots-Tag: none
< X-Download-Options: noopen
< X-Permitted-Cross-Domain-Policies: none
< Referrer-Policy: no-referrer
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8

* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact
[/code]

 

when I use https://192.168.1.204/nextcloud -k -v (which is same as localhost, it's nextcloud's IP)

[code]

<p>
        Please contact your administrator. If you are an administrator, edit the &quot;trusted_domains&quot; setting in config/config.php like the example in config.sample.php.    </p>
[/code]

* If I add 192.168.1.204 to the trusted hosts list it acts like localhost.

 

For me this looks like only contained IP/DNS in config.php trusted_domains section can access web interface (on local machine).

As soon as I'm trying this from another machtine like my notebook from the same network and same subnet I'm hitting errors.

To me it looks like all traffic from outside the nextcloud LXC container is not accepted, even if the IPs of the clients are specified inside trusted domains section in config.php.

Thanks for the feedback so far.

Best regards

 

Kitsab

Jeremy Davis's picture

I haven't explicitly tested it recently, but I did test the current appliance prior to release and my notes confirm that it was working for me?!

I suspect that your issues may be networking related?! FWIW I always use bridged networking with a static IP on my (Proxmox) LXC containers and everything "just works". But I suspect if you are using some other configuration, then that may explain your troubles? If you are using NAT routing or something similar, then in essence your Nextcloud server is being reverse proxied. That would certainly explain why it's not working...

FWIW, from my notes, this is how I had configured "trusted domains":

'trusted_domains' => 
  array (
    0 => '192.168.1.110',  'www.nextcloud.test', 

When I get a chance, I'll have another look and see if I can recreate your issue.

kitsab's picture

Hello Jeremy,

thanks for answering.

I'm using Proxmox server over bridged network interfaces vmbr0 and (vmbr1 not used)

x.x.x is 192.168.1.*

Proxmox server got a static IP x.x.x.252

All LXC containers have own staitc IPs:

x.x.x.201 freeradius server

x.x.x.202 vdr (video disk recorder)

x.x.x.203 samba share provider

x.x.x.204 nextcloud

All machines are in the same subnet and got access to x.x.x.x/24

In my opinion network is correctly configured.

I'm also able to SSH into nextcloud server.

Proxy is not used at all.

Thanks and best regards

Kitsab

Jeremy Davis's picture

That all sounds like it's configured exactly as per mine. So TBH, I have no idea why it appears to work ok for me, but not for you?!

So to ensure that there wasn't something I was missing, I just created a fresh container and tested it and it "just works" for me - as expected?! Here's the process I just took:

  • Downloaded the v15.2 Nextcloud template via Proxmox UI.
  • Created a new Proxmox Nextcloud container similar to your notes - IP 192.168.1.111/24.
  • Created a hosts file entry for 'nextcloud.test' (pointing to 192.168.1.111) on my laptop (FWIW IP of my laptop is 192.168.1.82).
  • Logged into the new container via SSH. I.e.: br>
    ssh root@nextcloud.test
  • Completed the firstboot questions (giving nextcloud.test when asked about the domain).
  • Opened my web browser on my laptop and typed 'nextcloud.test' into the address bar.
  • Clicked through the self signed certificate security warning.
  • Logged in using username "admin" and the password I set on firstboot.

FWIW, here's the relevant lines from my /var/www/nextcloud/config/config.php file, exactly as they appear (I used '[...]' to indicate the lines above and below):

[...]
  'trusted_domains' => 
  array (
    0 => 'localhost',
1 => 'nextcloud.test',
  ),
[...]

With those settings, if I browse to my container directly via the IP address (i.e. https://192.168.1.111/) I get the message:

Access through untrusted domain br> Please contact your administrator. If you are an administrator, edit the "trusted_domains" setting in config/config.php like the example in config.sample.php. Further information how to configure this can be found in the documentation.

As a further test, I added the LAN IP address to the "trusted domains" so the relevant section of it now looks exactly like this (I indented the '1' entry so it looks a bit nicer and used '[...]' again to denote lines above and below):

[...]
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'nextcloud.test',
    2 => '192.168.1.111',
  ),
[...]

And restarted Apache:

systemctl restart apache2

And refreshed the browser page (that was still on https://192.168.1.111/ - with the "untrusted domains" message displaying) and now I can log in!?!

So there is clearly something unique to your setup that is different from mine and the process that I tried. I can't reproduce your issue so I'm not really sure what might be going on? Perhaps it's worth you following the steps that I just took as documented above and see if it works like that?

kitsab's picture

Hello,

thank you for testing this.

I now started over and found an issue which I already had installing the container which caused the problems.

There was an issue I can't install the image with the following Proxmox output:

extracting archive '/var/lib/vz/template/cache/debian-9-turnkey-nextcloud_15.2-1_amd64.tar.gz'
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted

Total bytes read: 1378150400 (1.3GiB, 80MiB/s)
tar: Exiting with failure status due to previous errors
Logical volume "vm-103-disk-0" successfully removed
TASK ERROR: unable to create CT 103 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - -z --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/103/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2

I found a post somewhere which adviced to edit the tar.gz file and remove the directories /var/spool/postfix/dev/urandom and /var/spool/postfix/dev/random this solved the problem with installer error.

But may could this lead into the issue I experience trying to access the web interface?

Thanks and best regards

Kitsab

Jeremy Davis's picture

The workaround you note (removing /var/spool/postfix/dev/urandom and /var/spool/postfix/dev/random) is a legitimate workaround for running our containers on Proxmox as unprivileged.

Thanks for noting it, but I see no reason why that would cause the issue you are experiencing. The workaround you note only affects the operation of Postfix (the mail transfer agent that is pre-installed with TurnKey). And even for that, it should only affect LDAP authentication (so a very specific sub-set of users in a very specific use case).

So unfortunately, I'm 99% sure that that would make no difference at all to the default functioning of the appliance in general and Nextcloud in particular.

FWIW I usually run privileged containers (which is another workaround to the issue; i.e. "untick" the "unprivileged container" box on the first page of the "Create new CT" dialog). Incidentally, we intend to make changes in v16.0 so that our containers will run unprivileged by default - with no workaround required.

Does you new container work as expected?

kitsab's picture

Hello,

 

big thanks to you patients with me.

 

I found the problem after trying around a lot. 

I used my client's address inside the trusted domain entry - your exampel with "nextcloud.test" was giving me a good hint and then I read the trusted domains documentation again.

There was is a statement: "Users are allowed to log into Nextcloud only when they point their browsers to a URL that is listed in the trusted_domains setting."

Then I got it - I've got to enter the nextcloud CTs own IP or the nextcloud domain address which is locally "nextcloud.bk" - and it works.

 

Great thanks to your support.

 

Best regards

 

Kitsab

 

Jeremy Davis's picture

Sorry I missed that as the potential issue. I'm glad that you worked it out in the end though!

Add new comment