Open luke6464 opened 1 month ago
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
I can confirm that behaviour after update to 29.0.0
What should we do to address that issue? I actually think it might be a false-positive, since I am not able to actually access files from the internet, however some swag config for example could lead to this? Dunno. How to further investigate?
From some initial investigations I've done on this, it doesn't seem to be something that needs to be fixed within the container but more the permissions set on your /data
mount. When upgrading to v29 on my host, I don't have this warning at all.
My permissions do not look too suspicious. But I just found: https://help.nextcloud.com/t/after-upgrade-from-28-to-29-i-have-data-directory-and-your-files-are-probably-accessible-from-the-internet/189882/1
Not yet read that one, but will later
For me it helped to remove the ip of my server in the local lan from the array of trusted Domains:
'trusted_domains' =>
array (
- 0 => '192.168.178.99',
- 1 => 'my.domain.xyz',
+ #0 => '192.168.178.99',
+ 0 => 'my.domain.xyz',
),
I have the same issue, and in the trusted domains array only my domain is listed, no ip or local ip.
For me it helped to remove the ip of my server in the local lan from the array of trusted Domains:
'trusted_domains' => array ( - 0 => '192.168.178.99', - 1 => 'my.domain.xyz', + #0 => '192.168.178.99', + 0 => 'my.domain.xyz', ),
I can confirm this workaround works, but it also prevents accessing it locally using the IP address.
Here is my config.php (that produces the issue - I want to access it using local ip for the hardwired pc's, so commenting it out isn't ideal)
<?php
$CONFIG = array (
'instanceid' => 'id,
'passwordsalt' => 'SaltedFoo',
'secret' => 'NaFool,
'trusted_domains' =>
array (
0 => '192.168.1.210',
1 => 'My.Domain.XYZ.org',
),
'trusted_proxies' =>
array (
0 => '192.168.1.211',
1 => '192.168.1.210',
),
'datadirectory' => '/data',
'dbtype' => 'mysql',
'version' => '29.0.2.2',
'overwrite.cli.url' => 'https://My.Domain.XYZ.org',
'dbname' => 'NextCloudDB',
'dbhost' => 'nextcloud_db:3306',
'dbport' => '',
'dbtableprefix' => 'oc_',
'mysql.utf8mb4' => true,
'dbuser' => 'user',
'dbpassword' => 'pass',
'installed' => true,
'filesystem_check_changes' => 1,
'memcache.local' => '\\OC\\Memcache\\APCu',
'filelocking.enabled' => true,
'memcache.locking' => '\\OC\\Memcache\\APCu',
'upgrade.disable-web' => true,
'loglevel' => 2,
'maintenance' => false,
'maintenance_window_start' => 3,
'default_phone_region' => 'US',
);
Or you could configure your setup correctly so it's the same address internally and externally.
Or you could configure your setup correctly so it's the same address internally and externally.
So if the reverse proxy goes down for whatever reason, I lose access to it locally as well? This was a working configuration prior to v29
You could say that about anything that might go down for whatever reason. Note all these changes are security changes nextcloud are making and are outside of our control.
Again, the workaround mentionned is not one. As I mentionned I have that security warning even though my trusted domains section only list my domain, not local ip, nothing else. I also noticed that sometimes it gets duplicated, I do not know if a default configuration is sometimes merge with it, but I had to remove a second entry when I upgrade to version 29.
Could be formatting maybe of the array. Unfortunately I'm not able to reproduce, initially I thought the error was relating to filesystem permissions issues but it seems it's not.
'trusted_domains' =>
array (
0 => 'nc.domain.com',
),
'dbtype' => 'mysql',
'version' => '29.0.0.19',
'trusted_proxies' =>
array (
0 => '172.16.0.0/12',
1 => '127.0.0.1',
2 => '::1',
),```
workaround : I found a workaround on this page with '' but i'm not sure if the server understand .domain.xyz or * domain.xyz (who mean all Internet domain are trust) :
'trusted_domains' =>
array (
0 => '.*.mydomain.xyz',
),
Same error for me on a fresh install. When i replace mydomain.xyz by local IP adresse, i'v got an other message about "URL .well-known, failed on : `/.well-known/webfinger"
$CONFIG = array (
'datadirectory' => '/data',
'instanceid' => 'id',
'passwordsalt' => 'salt',
'secret' => 'secret',
'trusted_domains' =>
array (
#0 => '192.168.1.xxx:xxxx',
0 => 'mydomain.xyz',
),
'dbtype' => 'mysql',
'version' => '29.0.2.2',
'overwrite.cli.url' => 'https://mydomain.xyz',
'dbname' => 'nextcloud_db',
'dbhost' => 'nextcloud-db:xxxx',
'dbport' => '',
'dbtableprefix' => 'oc_',
'mysql.utf8mb4' => true,
'dbuser' => 'user',
'dbpassword' => 'password*',
'installed' => true,
'memcache.local' => '\\OC\\Memcache\\APCu',
'filelocking.enabled' => true,
'memcache.locking' => '\\OC\\Memcache\\APCu',
'upgrade.disable-web' => true,
);
I'm also affected by this. I had an unused local DNS name and a WAN DNS name in trusted_domains
. Removing the local one did not fix the issue. This included recreating the container after making the change.
This post explains how this error is detected - the idea seems to be that the PHP variable htaccessWorking
is set to true
by Apache in the .htaccess
file. In installation.php
this variable is checked. If not set to true
, the warning is shown. Since this container uses Nginx as its web-server, my guess would've been that this value isn't being set at all. But that might not be the whole story, since reproduction seems inconsistent, and there are mentioned workarounds here that apparently work.
Via discussion in nextcloud/server#45087, I determined that the new Nextcloud API that creates these warnings is quite fragile. In my case, the checker was expecting a 4**
return code when checking http://cloud.domain.com/var/nc_data/.ocdata
(the endpoint used for testing file access), so the fact that nginx was returning a 302
on the http
endpoint led to the error being provided. If the checker had followed the redirect instead, it would've been fine.
By adding listen 80;
to my nginx config, the issue went away. Now, instead of nginx doing the http
-> https
redirect, Nextcloud does it at an application level instead.
There seem to generally be some issues around this new API causing lots of false positives. Not following redirects, not accounting for external auth providers, etc. nextcloud/server#44234 is another example.
Is there an existing issue for this?
Current Behavior
Greetings, from version 29.0.0 I get the following error message: The data folder and your files are probably accessible from the Internet. The .htaccess file does not work. We strongly recommend that you configure the server so that the data folder is no longer accessible or move the folder out of the root of the web server. This didn't happen with the previous version 28.x.x. Can you help me Thank you.
Expected Behavior
No Error!
Steps To Reproduce
Linux Debian - Container Docker-Compose
Environment
CPU architecture
x86-64
Docker creation
Container logs