How to test if my files are not accessible from the internet?

Nextcloud version: 29.0.1.1

The issue you are facing:
Since the upgrade to version 29, I am getting this error message in “Security & setup warnings”:

There are some errors regarding your setup.

Your data directory and files are probably accessible from the internet. The .htaccess file is not working. It is strongly recommended that you configure your web server so that the data directory is no longer accessible, or move the data directory outside the web server document root.

The upgrade to 29.0.1 did not fix it unfortunately.
While I suspect that it is a bug (perhaps [Bug]: 'Data directory protected' check failing · Issue #45087 · nextcloud/server · GitHub), I would like to be sure, so how can I test if the error message is right?

I am not entirely sure how that “accessible from the internet” would work. My assumption was that it means that somebody has to guess username and filepaths and then try the URL, like in case of a default file:

https://<nextclouddomain>/data/<username>/files/Nextcloud.png

If I use that URL in the browser, I get

“Page not found The page could not be found on the server or you may not be allowed to view it.”

But the message is displayed no matter if I am logged in or not, so this does not seem to be a valid test?

I would move the Date directory from the DocumentRoot anyway, whether the webserver/htaccess-configuration is correct or not. If something is misconfigured somewhere (error in htaccess, error in update, error in apache/nginx etc) then you have the problem. But yes, your descriptions sound as if the test was faulty in your case.

What do you mean by

Is it an invalid method for testing or is it a valid one that did not work because of some technical issue?

Your method sounds to me like a good way to test whether the files can be accessed externally :slightly_smiling_face:

You should definitely try to get rid of the message. It is most likely an error in the web server configuration, see e.g. here.

For the Nextcloud installation, it is recommended not to store the datadirectory in the web server path. This way you would not have the problem at all.

@mritzmann
And if I am logged in, I should be able to access the file, yes? Then perhaps I am using the wrong path?

@devnull
But the error was not displayed in earlier versions, so was it wrong then or is it wrong now (AllowOverride All is included in my apache2.conf)?
The support of my webhoster said that the data directory is outside of webroot, I used their oneclick installer and assume that they configured it well.
Moving the data directory retroactively seems not possible without root.

I am not sure if I understand webroot correctly:

  1. webroot and document root are the same, yes?
  2. webroot is defined in apache2.conf and there might be multiple webroot entries (e.g. for subdomains), yes?
  3. nextcloud data directory is literally /foo/bar/nextcloud/data/ or is it /foo/bar/nextcloud/data/<username>/files/ ?
  4. if apache2.conf contains DocumentRoot "/foo/bar" that means that /foo/bar/nextcloud/data/ is in webroot and should be moved e.g. to /foo/, yes?
  5. if apache2.conf contains DocumentRoot /foo/bar/nextcloud in addition to DocumentRoot "/foo/bar" that does not change the fact that /foo/bar/nextcloud/data/ is in webroot, yes?

Yes

Yes, every vhost (or subdomain) can have its own webroot.

Usually, the 1st is meant. The 2nd is the raw data directory of a particular user, the file structure just like (s)he sees it in the web interface. However, in its parent dir, there is more sensitive data from other apps and meta data, and in the 1st there is NC-wide app and meta data. One must not be able to access any of those directly, no matter whether logged in or not.

The apache2.conf can define a global DocumentRoot. But in case, every <VirtualHost> block (usually defined in separate files in /etc/apache2/sites-enabled/ configs) defines its own DocumentRoot (=webroot), overriding the default.

In any case, if /foo/bar/nextcloud/data/ exists, it is within your webroot, since /foo/bar/nextcloud must be within your webroot to function, or is the webroot itself. Indeed, it is a good idea to move it outside of the webroot, following method 1 of my HowTo. But it is just an additional security measure. The .htaccess file located in your data directory should prevent direct access to it OOTB. If it does not work, there is something wrong about your configuration. See here: Installation on Linux — Nextcloud latest Administration Manual latest documentation
The AllowOverride All directive makes Apache2 read and respect .htaccess files, which should in turn prevent direct access and mute the admin panel warning.

It is moreless exactly what Nextcloud itself does in mentioned check :slightly_smiling_face:. It checks whether the .ocdata file within the data dir is accessible: server/apps/settings/lib/SetupChecks/DataDirectoryProtected.php at master · nextcloud/server · GitHub

2 Likes

@MichaIng Thank you for your extensive answer!

To get a better understanding of what should happen, I momentarily renamed the htaccess in the nextcloud data directory (there are no personal files atm) and tested
https://<nextclouddomain>/data/<username>/files/Nextcloud.png again in the browser: the image was displayed and after renaming htaccess back, I got Page not found The page could not be found on the server or you may not be allowed to view it like before, so it seems my htaccess file works, but if my files were outside of webroot that test would have failed even without the htaccess, like it should.

Unfortunately, without root, there is not much I can do about it. A fresh installation using the Web installer might be my only option, but since I haven’t installed anything outside of using one-click installers, I am not sure if it will work without root.

That warning is generated here:

and is thrown if the environmental value htaccessWorking is not set.

That vallue is set in the .htaccess file in this line:

if mod_env is loaded in apache2.

Since you are on a hoster, it might be possible that mod_env is not loaded and that would explain why you got this message. Nothing else!

If you have got full access to your webserver, you could find out if mod_env is loaded with this call

~$ sudo apachectl -M 2>/dev/null | grep env_module

it should echo this:

 env_module (shared)

Much and good luck,
ernolf

4 Likes