28.0.3.2 → 29.0.0.19： issues about .htaccess and .well-known

[huangwb8]

28.0.3.2 → 29.0.0.19： issues about .htaccess and .well-known

[witchent]

@huangwb8 Since your are getting both the data directory and the .well-known setup checks failing in your environment simultaneously, the above that I just posted may be relevant. Because both keep trying until they find a host that responds with an valid status code. Maybe audit your trusted_domains and overwrite.cli.url value fully:

* Make sure there aren't any old no longer in-use hostnames/IP addresses.
* Make sure also that they don't resolve to different things from the container's perspective (mismatched internal versus external DNS), etc.

Actually I just did that as well (deleted all trusted domains except for the one I am normally using) and it seems to have fixed the warning. Maybe I broke something (that list grew a bit over the years) but then I hopefully remember what I did. So thank you for giving me the push of doing this.

[joshtrichards]

@huangwb8 Since your are getting both the data directory and the .well-known setup checks failing in your environment simultaneously, the above that I just posted may be relevant. Because both keep trying until they find a host that responds with an valid status code. Maybe audit your trusted_domains and overwrite.cli.url value fully:

• Make sure there aren't any old no longer in-use hostnames/IP addresses.
• Make sure also that they don't resolve to different things from the container's perspective (mismatched internal versus external DNS), etc.

[hugalafutro]

Can confirm after removing all trusted_domains apart from the single one where nextcloud resides and restarting the container the warning is gone. Not sure why I had the local docker network and external IP there as well, but they're gone now along with the error.

In trusted_proxies I have the external ip of the machine (the reverse proxy runs on the same machine), 127.0.0.1 and ::1 - the latter 2 to make local push service working and none of these setting seem to trigger the warning as I didn't touch them.

In any case many thanks for pointing the right direction, although I believed there is no issue the existence of the warning kept nagging at the back of my head.

[joshtrichards]

@hugalafutro My guess it is a false positive since that check (the data directory security check) just got migrated to a new API, but it may not be a bug necessarily (though that's certainly possible). What it does it send an HTTP/HTTPS request to all of all your trusted_domains and your overwrite.cli.url with your datadirectory appended + .ocdata - eg.

https://domain1.com/var/nc_data/.ocdata
https://domain2.com/var/nc_data/.ocdata
https://ipaddress1/var/nc_data/oc.data

I say it could be a bug, but may not be one because it may be something weird like one of your configured trusted_domains actually resolves elsewhere.... and that "elsewhere" happens to return a 200 HTTP code to the above queries. That was what one person (below, in part) reported.

Related: nextcloud/server#45087

[whoamiTM]

Can confirm after removing all trusted_domains apart from the single domain that I have HA Proxy resolving to nextcloud, and restarting the jail, the warning is finely gone. I removed localhost and the jails local IP address.

[huangwb8]

As you suggested, delete unavailable trusted domains also works for me by solving the .htaccess issue.

By the way, the .well-known still exists. In the 29.0.0.19 version, Calendar could not be installed in my nextcloud, which might be the chief culprit.

Thanks for all you guys! This issue can be just closed for a while.

[invalidplayername]

For the well known part, there are older issues where the issue has been solved by adding corresponding blocks in the nginx config. Although, the code hasn't made its way into the nextcloud repo yet:
nextcloud/server#38035 (comment)

[huangwb8]

@invalidplayername

First, I used nginx as reverse proxy manager, where I had added :

location /.well-known/caldav {
    return 301 $scheme://$host/remote.php/dav;
}

location /.well-known/webfinger {
    return 301 $scheme://$host/index.php/.well-known/webfinger;
}

Second, my nginx configuration of nextcloud-fpm (raw in https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/with-nginx-proxy/mariadb/fpm) had been added:

location ^~ /.well-known {
            location = /.well-known/carddav { return 301 /remote.php/dav/; }
            location = /.well-known/caldav  { return 301 /remote.php/dav/; }

            location = /.well-known/webfinger  { return 301 /index.php/.well-known/webfinger;}
            location = /.well-known/nodeinfo  { return 301 /index.php/.well-known/nodeinfo;}

            location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
            location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

            # Let Nextcloud's API for `/.well-known` URIs handle all other
            # requests by passing them to the front-end controller.
            return 301 /index.php$request_uri;
        }

These settings work well in 28.0.3.2, where the .well-known error did not appear.

By the way, the .htaccess issue seemed to be a more serious problem. Any suggestions?

[joshtrichards]

Does the DNS for "yournextcloud.com" resolve to the same IP address from within the Nextcloud app container as it does from the outside? The various setup checks have been migrating from being browser based to being server-side. They run through your trusted_domains and overwrite.cli.url and run from the container itself now.

Either way, these sound like either upstream (server) or config matters. I see nothing that suggests these are specific to the image.

[huangwb8]

@joshtrichards

The related contents in the config.php are as following:

'trusted_domains' =>
array (
0 => '192.168.1.100',
1 => 'yournextcloud.com',
),
'overwritehost' => 'yournextcloud.com:2443',
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'http://yournextcloud.com:2443',

These settings work well in the past versions of Nextcloud.

I checked the logs after I peformed a new security & setup warnings checking:

According to the picture, the .well-known error seemed to be corelated with the availability of 80 port.

For some reasons, I cannot use 80 and 443 in my server, that's why I use the other port (2443) to replace 443. I don't known why the .well-known checking is involving URLs like http://yournextcloud.com:80, which I have never used.

Any suggestions?

[tinysun]

I have the same problem here, I deployed it directly on the physical machine.

[AGagarin]

Same issue after installation on VPS with VM script. Your data directory and files are probably accessible from the internet. The .htaccess file is not working.

Has the identical setup on another VM with Nextcloud 28 no issues.

[joshtrichards]

These settings work well in the past versions of Nextcloud

@huangwb8:

As I said: the checks used to all (mostly) run from your browser. They are now (mostly) migrated to a new API that runs them from the server/container. This isn't a Docker matter, but a Nextcloud Server matter. It's an incremental change in progress throughout the v28+ branches.

I do note your config looks odd:

 'overwritehost' => 'yournextcloud.com:2443',
 'overwriteprotocol' => 'https',
 'overwrite.cli.url' => 'http://yournextcloud.com:2443',

These contradict each other. One is using http on 2443 and the other https.

Since you're using the Docker image you may also want to confirm the output of occ config:list system (i.e. your real running config) truly reflects what you posted. For example, the overwrite* parameters specified via Compose would overwrite those since the reverse-proxy.config.php takes priority over the config.php.

I have the same problem here, I deployed it directly on the physical machine.

Same issue after installation on VPS with VM script.

@tinysun & @AGagarin: Then you're in the wrong place. This repository is solely for the Docker image.

As it stands this Issue appears to be for matters that are a mixture of (possibly) upstream bugs (Nextcloud Server not the Docker image) or, in most cases, config matters that are arising as new problems... due to changes with how the setup checks function as of Nextcloud Server v28/v29. I suggest following up at the Help Forum.

[witchent]

I use the nextcloud-fpm docker image with podman and nginx as proxy, and I get the same message about .htaccess which seems weird to me. Don't have the .well-known problem though, that still seems to work.

[hugalafutro]

config matters that are arising as new problems... due to changes with how the setup checks function as of Nextcloud Server v28/v29

I use different docker image and the issue is there as well from the day of update to NC29 so I'd say upstream, but more importantly;

is it then:
a) all good as it was before, just the config.php parser throwing an error in some configurations
b) my nextcloud data was exposed to internet for last ~3 years while nextcloud claimed all is well ?

Not trying to assign blame, just gauge the extent of the issue. I'm leaning towards a) as I didn't do any config changes for months (last change was to move the whole nc dir to new mount path of a new storage) and run my nc in cloud with fair amount of firewall probing going on and the server comes up A++ in the Qualys SSL test and all the firewall probers like nikto etc. I tried got blocked before they even started by crowdsec.

How could I try to access a file directly to see if it is indeed accessible without logging in to confirm whether this is indeed an issue and not just spurious warning?

[Banditen01]

Couldn't figure this out, then I found this and changed in previous working docker compose file. Maybe can help someone !!??