This help me resolve this problem.
Only thing to change was to add port in trusted domains
1 => '192.168.0.100:6443',
This help me resolve this problem.
Only thing to change was to add port in trusted domains
1 => '192.168.0.100:6443',
Nextcloud version (eg, 29.0.5): 29.0.1
Operating system and version (eg, Ubuntu 29.04): Rocky Linux 9.4
Apache or nginx version (eg, Apache 2.4.25): 2.4.57
PHP version (eg, 8.3): 8.3.7
The issue you are facing:
I’m getting a warning message within my settings:
So I tried to find some solutions but nothing from what I found solved the issue.
I even moved out my data folder now from the public_html folder, so it’s not even visible from the net anymore, but still seeing that error.
Also trusted domains and overwrite cli are correct in my eyes
'trusted_domains' =>
array (
0 => 'my.domain',
),
'overwrite.cli.url' => 'https://my.domain',
Someone wrote to use *.my.domain under trusted domains and here I than just get an error that I’m accessing from an untrusted domain
In my http config I checked also the overwrite:
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
Require all granted
Is this the first time you’ve seen this error? (Y/N): Y
The output of your Nextcloud log in Admin > Logging:
empty
The output of your config.php file in /path/to/nextcloud
(make sure you remove any identifiable information!):
<?php
$CONFIG = array (
'instanceid' => '',
'passwordsalt' => '/QokUhQNO',
'secret' => '',
'trusted_domains' =>
array (
0 => 'my.domain',
),
'datadirectory' => '/my_data_folder',
'dbtype' => 'mysql',
'version' => '29.0.1.1',
'dbname' => '',
'dbhost' => 'localhost',
'dbport' => '',
'dbtableprefix' => 'oc_',
'overwrite.cli.url' => 'https://my.domain',
'mysql.utf8mb4' => true,
'dbuser' => '',
'dbpassword' => '',
'installed' => true,
'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => 'localhost',
'port' => 1234,
),
'maintenance' => false,
'theme' => '',
'loglevel' => 2,
'updater.release.channel' => 'stable',
'app_install_overwrite' =>
array (
0 => 'unsplash',
1 => 'occweb',
2 => 'apporder',
3 => 'files_readmemd',
),
'default_phone_region' => 'LU',
'default_locale' => 'de_DE',
'remember_login_cookie_lifetime' => 172800,
'session_lifetime' => 86400,
'mail_smtpmode' => 'sendmail',
'mail_sendmailmode' => 'smtp',
'mail_from_address' => 'service',
'mail_domain' => 'domain.xyz',
'defaultapp' => 'apporder',
'simpleSignUpLink.shown' => false,
'twofactor_enforced' =>
array (
'false' => '',
),
'maintenance_window_start' => 1,
);
I’m now a bit lost as I don’t know what to do as next test - As I wrote even when moving out my data folder I’m still getting this message
The data folder has 770 as chmod and it is owned by the domain owner
The folders for the different users are drwxr-xr-x
Thanks for any idea and help
Hi @ISeeTWizard
You should have used the search function of the forum.
Read this please, maybe it explains your issue:
Much and good luck,
ernolf
Hi
like mentioned I searched for it and I found several entries and tried all of them
[root@web ~]# httpd -M
Loaded Modules:
*
*
env_module (shared)
*
*
So I also checked that this module is loaded, which it is as you see on the return I got
Upgraded to 29.0.2 and still same issue
I still don’t see how my data folder could be accessible from the net when it doesn’t even exist anymore in the public folder but somewhere else on the server
I am glad to see that I am not the only one facing this problem - I have tried all above suggestions but none of the worked for me.
I can’t solve this either; I’ve removed all IP entries from my trusted domains section, and upgrading to 29.0.2 and I get the warning. My data directory is not in my www/nextcloud directory, but I’m still concerned due to the warning so I can’t upgrade my prod system until I have this solved
Are there any other suggestions? This is preventing me and likely others from upgrading to Nc29. I don’t want to risk data leak, and I don’t think in my example it’s at risk because of where my data directory is stored, but I don’t want to take the risk either
This solved my problem! Thanks a lot!
Sadly this doesn’t work for me. Adding my port to it and then trying to login indicates the site isn’t added to trusted domains and I can’t login. Reloaded Apache before testing as well.
I can confirm this
many reported changing something with the trusted_domain entry or the overwrite.cli.url dit help them but nothing helps on my install
Thanks!
Removing localhost
from trusted_domains
and appending a port on the remaining elements as shown below made the error go away for me also.
# grep -A 5 -i trusted_domains config/config.php
'trusted_domains' =>
array (
0 => 'example.com:443',
),
);
Maybe something to do with how my proxy setup handles stuff on port 80?
Looking at the docs, it doesn’t seem like having a stricter setting here should be a problem, so long as you can still access your instance OK.
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#trusted-domains
It’d be nice to see some clearer guidance about this issue in the update issues thread though - it took me way too long to convince myself that everything was OK with my instance and figure out how to address the problem.
I wish this worked for me. Adding :443 to the end, and then trying to login to my site says it’s not in the trusted domains and I can’t login at all. Removing :443 works. And port 443 is open via my firewall and routed to my server
Yep you are right - I tried it to but didn’t work
By the way I don’t use a proxy or similar - I attack my Cloud directly within my Apache Configuration
How is it possible to throw an error for something that isn’t even accessible from the web as the data folder is outside the web accessible folder?
It’s simply illogic and for me a bug!
NC29 is the first version I regret to have upgraded to…
totally agree
Bug still present with 29.0.3
I did a new test:
I did a new fresh install and here I don’t get that error
I compared all the settings (which are the same in the config file - except the URL as I installed as subdomain for testing)
Also the same apps activated - the same rights on the folders
So I simply don’t see why on the one install there is this error and on the other one not - I simply don’t see any logic within this
Something seems to have caused a value to be added to my trusted_domains
that triggered this error again. Perhaps it was the update to 29.0.3? I’m not sure, just noticed it in the console after rebooting my server today. I now have something like:
# grep -A 5 -i trusted_domains config/config.php
'trusted_domains' =>
array (
0 => 'example.com:443',
1 => 'example.com',
),
);
Removing the new entry at index 1 caused the error to stop being triggered for me once more.
FWIW I’m using a pretty simple nginx reverse proxy config. to pass traffic to my Nextcloud All-in-One instance running in Docker. SSL is terminated by nginx on my Docker host. My nginx config looks like this:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com ;
<...SSL config, etc.>
location / {
proxy_connect_timeout 60;
proxy_read_timeout 60;
proxy_send_timeout 60;
proxy_intercept_errors off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://localhost:<Nextcloud Apache docker container port>;
}
<...other stuff probably not related to this issue>
}
I also have overwrite.cli.url
set like:
# grep "overwrite.cli.url" config/config.php
'overwrite.cli.url' => 'https://example.com/',
I think if your proxy setup differs to this a lot you might need to configure your trusted_domains
and overwrite.cli.url
differently to what I’m using.
See the docs:
overwrite.cli.url
trusted_domains
this might be possible for setups with a proxy
but I have this message without the data in the public accessbible area and no proxy at all - direct access trough apache
something is wrong with this check - but what - I don’t know
for me I’m ignoring it now
That’s fair enough, the check does look to just be a false positive anyway.