Hi. I have launched nextcloud snap. The server is located in the subnet 192.168.1.0. And there is access to the server and files from this subnet. However, when I want to connect from a different subnet (a different VLAN) then, although I can go to the nextcloud website and log in to my account, but I can’t browse or create new files. Anyone know how to solve this problem?
Please use browser dev tools (F12) and there Network. Then you can see the requests between your browser and your Nextcloud server. Post errors in the output.
For example, when it wants to open some file. Of course, this file is on the server, because from another subnet I can open it.
any ideas? ;]
Test this settings in your config/config.php
'overwrite.cli.url' => 'https://your.domain.com',
'overwriteprotocol' => 'https',
This did not help, still the same problem.
array (
'host' => '/tmp/sockets/redis.sock',
'port' => 0,
),
'log_type' => 'file',
'logfile' => '/var/snap/nextcloud/current/logs/nextcloud.log',
'logfilemode' => 416,
'instanceid' => 'oc7b8x9zwree',
'passwordsalt' => 'eLA0IAuhIWbKd/VCacYVQnomSD214c',
'secret' => 'yU1+C7PfyTVpWLdsa21FddD6JoNrYDcYFjbdOW1XyXbr',
'trusted_domains' =>
array (
0 => '192.168.1.16',
1 => 'nc.mydomain.pl',
),
'datadirectory' => '/var/snap/nextcloud/common/nextcloud/data',
'dbtype' => 'mysql',
'version' => '22.2.3.0',
'overwrite.cli.url' => 'https://nc.mydomain.pl',
'overwriteprotocol' => 'https',
'dbname' => 'nextcloud',
'dbhost' => 'localhost:/tmp/sockets/mysql.sock',
'dbport' => '',
'dbtableprefix' => 'oc_',
Delete this file at once!
You have now exposed salt, secrets and other sensitive information.
Copy your config into notepad and anonymize sensitive information, like secrets, slats, keys, passwords, hostnames and ports.
Now to elaborate on what @devnull wrote:
'overwrite.cli.url' => 'https://your.domain.com',
'overwriteprotocol' => 'https',
What you entered was correct. However you are connecting from another subnet so these trusted domains needs to be ezxpanded with the network address of the other subnet:
0 => '192.168.1.16',
1 => 'nc.mydomain.pl',
Like this (both adding the network address (the first IP of the other subnet) and adding the gateway of your current subnet as trusted domains. Especially the latter is important, because isolated on the other subnet, it cannot just reach the domain on the 192.168.1.16, but instead on the gateway IP (typically the first 192.168.1.1) for 192.168.1.0
However it depends on how basic your network topology is setup, or if you uses more advanced features:
0 => '192.168.1.16',
1 => 'nc.mydomain.pl',
2 => '192.168.2.0',
3 => '192.168.1.1',
I changed this information before uploading 
2 Likes
Good. My heart started racing. 
2 Likes
Actually you might need to add your LAN gateway as trusted proxy. However as I am using Reverse proxy to route between different networks, I have never had to dable with this, and only needed to concern myself with trusted_proxies.
AH! I noticed a keyword in this from your screenshot. CSP policy denies cross domain (crossing subnets are considered cross domain in HTTP) is preventing you from executing the command. The path is translated to the file ID, but that is prevented due to CSP.
@PustyB
I changed on my server to:
0 => '192.168.1.16',
1 => 'nc.mydomain.pl',
2 => '192.168.28.0', - subnet address
3 => '192.168.28.131', - my adress ip
but it didn’t work
AH! I noticed a keyword in this from your screenshot. CSP policy denies cross domain (crossing subnets are considered cross domain in HTTP) is preventing you from executing the command. The path is translated to the file ID, but that is prevented due to CSP.
@PustyB
So what should I do? Surely there must be some way to access from a separate subnet.
If your NC host is:
192.168.1.16
Then the gateway of your NC host most likely is
192.168.1.1
Thats the IP you needs to add.
If your other subnet is
192.168.28.0
Then thats all you needs to add for that subnet.
Basic networking (if not using more advanced features) uses NAT and portforwarding.
In a traditional network setup that would mean:
If I am on a host with the IP 192.168.28.131 and I wants to reach a resource on 192.168.1.16, I would make port forwarding on my router/gateway at 192.168.1.1 on port 80 and 443, so all I needed to do was to point to 192.168.1.1 in my browser, and I would be routed to the web resource on 192.168.1.16.
When hitting the webserver on your NC host, it will read the NAT address ( 192.168.28.0 or 192.168.1.1) as the requested address. It is the address which is read from the connection session header, which you needs in the trusted domains.
'trusted_domains' =>
array (
0 => '192.168.1.16',
1 => 'nc.mydomain.pl',
2 => '192.168.28.0',
3 => '192.168.28.131',
4 => '192.168.1.253', - 1.0 gateway
5 => '192.168.1.0',
6 => '192.168.31.254', - 28.0 - gateway (this is /22 network)
),
I can get to all other services running on the 1.0 network without a problem. Even as I mentioned to nextcloud I can get to, log into my account, change settings, install plugins. However, I can’t create or open files.
Maybe I’m editing the wrong file? I have the snap versions. The location of config.php that I am editing is: /nextcloud/current/nextcloud/config
I suspects your CSP policy then. You got a clue in your web developer tool console. Besides that, I have not experienced any issues in the product itself, which relates to this, so I suspect something in your infrastructure. You could setup a reverse proxy somewhere to manage proxying to all your different services, and make due with port mappings in all service networks. Thats an idea, not an explanation to your current challenge.
1 Like
I am back again with the same problem.
How can I edit the CSP or disable it by test to see if it’s definitely the CSP’s fault?
I have Nextcloud v25.0.6 which I installed using SNAP on an Ubuntu 22.04
Sorry but the proposed solutions here don’t really make any sense. Your problem has nothing to do with the trusted domain settings, matter of fact it has probably nothing to do with Nextcloud at all. If your network would be configured correctly, you wouldn’t need to add any gateway addresses as trusted domains, because that’s not at all how this works.
The error message in Nextcloud is telling you that you are trying to access a resource (a PDF in this case) with a different domain than you are logged in with. I can’t tell you why this is happening, but again, I highly doubt that this has anything to do with Nextcloud, and under no circumstances it should be solved by disabling any CSP checks, and it can’t be solved by adding any gateway addresses as trusted domains either.
The only thing I can say for sure is that in a properly configured network, ideally with proper DNS resolution in place, you would only need one, or at most two trusted domain entries, namely your FQDN and maybe the IP address of the server. If you’re running a proxy in front of your Nextckloud it gets a bit more complicated, but you never ever need to enter any gateway addresses as a trusted domain or as trusted proxy or literally anywhere at all.
I’m ashamed to write about it, but the problem lay in nextcloud’s configuration, specifically in the “File access control” application, in which I set at the very beginning of setting up nextcloud’s server access only from the 1.0/24 network. Eh, that I didn’t look into these settings before just trying to configure trusted domains or CSP. 
thanks @bb77 for telling me not to look for the problem in those settings
2 Likes