[BUG] <title>The data folder and your files are probably accessible from the Internet.

[luke6464]

Is there an existing issue for this?

• I have searched the existing issues

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

- OS:Debian
- How docker service was installed:

CPU architecture

x86-64

Docker creation

version: "3.7"
services:
# NextCloud Container
  nextcloud:
   image: linuxserver/nextcloud:latest
   container_name: nextcloud-ls-app
   volumes:
    - /srv/dev-disk-by-uuid-26932a7e-0c50-4123-ba7f-834f0f369220/nextcloud-ls/nc-config:/config
    - /srv/dev-disk-by-uuid-26932a7e-0c50-4123-ba7f-834f0f369220/nextcloud-ls/nc-data:/data
   environment:
    PUID: 1002
    PGID: 100
    TZ: Europe/Rome
   ports:
    - 8443:443
   depends_on:
    - mariadb
   restart: unless-stopped

# Database Container
  mariadb:
   image: linuxserver/mariadb:latest
   container_name: nextcloud-ls-db
   volumes:
    - /srv/dev-disk-by-uuid-26932a7e-0c50-4123-ba7f-834f0f369220/nextcloud-ls/db-config:/config
   environment:
    PUID: 1002
    PGID: 100
    TZ: Europe/Rome
    MYSQL_ROOT_PASSWORD: ************
    MYSQL_DATABASE: nextcloud-ls-db
    MYSQL_USER: nextcloudlsdb
    MYSQL_PASSWORD: ****************
    MYSQL_HOST: nextcloud-ls-db
   ports:
    - 3306:3306
   restart: unless-stopped

Container logs

root@OMV-AMD64:~# docker logs nextcloud-ls-app
[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] 02-default-location: skipped
[migrations] done
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1002
User GID:    100
───────────────────────────────────────

using keys found in /config/keys
Initializing nextcloud 29.0.0.19 (this can take a while) ...
Setting permissions
Initializing finished
[custom-init] No custom files found, skipping...
[ls.io-init] done.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[darkmattercoder]

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?

[j0nnymoe]

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.

[darkmattercoder]

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

[darkmattercoder]

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',
   ),

[GuiPoM]

I have the same issue, and in the trusted domains array only my domain is listed, no ip or local ip.

[RFBomb]

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',
);

[j0nnymoe]

Or you could configure your setup correctly so it's the same address internally and externally.

[RFBomb]

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

[j0nnymoe]

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.

[GuiPoM]

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.

[j0nnymoe]

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',
  ),```

[Parad0xs]

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,
);

[MrMeeb]

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.

[MrMeeb]

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.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.