[Bug]: After update to 29: Some headers are not set correctly on your instance about server

[MatteoPaier]

I can reproduce the problem with Authentik SAML SSO. Maybe the issue should indeed be reopened (or the discussion moved to a new one).

Probably related also to #44234.

[Ra72xx]

Authentik, OpenID, Nextcloud in a subdir, Nginx proxy configured as officially documented, problem occurs after update to NC29. Please reopen!

[jiriks74]

Got rid of it by modifying the compose file. The setup I used as a base had a hostname defined and that's why it resolved to the container and not the proxy.

[joshtrichards]

@gravelfreeman Well, the appropriate place to follow-up would be #44234 in that case :)

[jiriks74]

I have the same issue. Could you please provide instructions on how to fix it?

Like I said, remove/change the hostname: nextcloud.somedomain.eufrom your compose file

[0x09AF]

I don't have hostname configured in my compose file, but got this error after upgrading to 29. Is there another fix?

[jiriks74]

What is your setup. Like is the server local, behind proxy, etc. What IP is the container resolving the hostbame to? (Run dig your.domain inside the container)

[warioishere]

I dont use docker, just plain selft installation

[Patta]

I can confirm, that all security headers are set and also approved by securityheaders.com, but after upgrading from nextcloud 28.0.6 to 29.0.2 a warning is displayed in the settings/admin/overview that some headers are not set correctly.
Plain installation with nginx.

[xundeenergie]

Authentik, OpenID, Nextcloud in a subdir, Nginx proxy configured as officially documented, problem occurs after update to NC29. Please reopen!

Same here!

[gravelfreeman]

Why is it closed if it's not resolved yet?

[joshtrichards]

Do each of your configured trusted_domains resolve to your proxy/TLS terminator from the perspective of your Nextcloud Server? That is, if you run curl from within your Nextcloud Docker container does it hit your proxy (and therefore see those headers)? That's the most common culprit since most of the tests are running from the server itself rather than you're browser these days.

[jiriks74]

For whatever reason dig running directly from the container resolves to the container IP rather than the public one.

[mikesteele81]

I have the same problem. With Nextcloud 28 I made sure that the self-test would hit the reverse proxy's internal address by including an entry within /etc/hosts to override what DNS would otherwise provide.

[VPaulV]

I have the same issue. Could you please provide instructions on how to fix it?

[0x09AF]

@jiriks74 I am not too sure if I have the exact same error but the symptoms are similar, appeared after upgrading to v29. Here's the error: Could not check that your web server serves security headers correctly, unable to query `` For more details see the documentation ↗
dig inside the container resolves the same as from the outside - to Cloudflare IPs

[wvxx]

I'm having the same issue since upgrading to 29, dig ran from within the container resolves to my public IP address, I've no hostname set on my container as well, trusted proxies are set properly.

Any ideas? ;)
Thanks.

[jiriks74]

@0x09AF

unable to query ``

This seems like Nextcloud doesn't have it's hostname set properly?

I've no hostname set on my container as well, trusted proxies are set properly.

If it's the same error I suspect that Nextcloud doesn't know it's url and you cannot query an empty string

---

What are your proxy settings?

[wvxx]

If it's the same error I suspect that Nextcloud doesn't know it's url and you cannot query an empty string

What are your proxy settings?

I might have expressed myself a bit unclearly. I mean that I get the warnings in my nextcloud admin settings despite curl telling me that all headers are enabled.

I have trusted_proxies set to IP of my traefik container as well as public IP, like I said above dig ran from the nextcloud container shows my public IP address.

[0x09AF]

@0x09AF

unable to query ``

This seems like Nextcloud doesn't have it's hostname set properly?
My docker-compose hasn't changed in a few years I have been running Nextcloud. Could you point me to the right env variable or a line in config.php?
Thanks

[warioishere]

I am also having this issue, baremetal nextcloud installation. I dont havy any ReverseProxy infront of my NC
they headers are set if i curl my domain.

[tuxArg]

Hi, I've just had this message too. I solved it allowing container IP login in limit_login_to_ip app. I hope it helps.

[xundeenergie]

Same here. Plain installation without container... and i get the same warnings Since upgrade to 29.

[lexxxel]

same, I run nextcloud from a lxc container and checked with curl - everything looks OK from there. (My reverse proxy is also traefik on another lxc container somewhere in the network)

[kocouj1]

I've Nextcloud 29.0.1 and have some problem. I can see that all headers are send but I'm getting security warning.

[nicolas-parmentier]

Same here, running Nextcloud 29.0.1 with docker (had same behavior with 29.0.0). dig inside the container returns the public IP of my reverse proxy. Everything looks fine.
From the container, with a curl command, i can see the headers well configured:

curl -v nextcloud.mydomain.com

< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block

[nick-oconnor]

@joshtrichards I think the probe is following redirects. With OIDC, unauthenticated requests to the root URL are redirected to the provider. I see a request for / made by Nextcloud Server Crawler which is getting redirected to my provider. I'm curious if that's the request that's checking for headers. If that's the case, this issue should be reopened.

[05/Jun/2024:03:56:56 +0000] "GET / HTTP/1.1" 302 0 "-" "Nextcloud Server Crawler" 105 0.034 [apps-nextcloud-nextcloud] [] [<ip redacted>]:80 0 0.033 302 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /login HTTP/1.1" 302 0 "-" "Nextcloud Server Crawler" 110 0.021 [apps-nextcloud-nextcloud] [] [<ip redacted>]:80 0 0.021 302 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /apps/user_oidc/login/2 HTTP/1.1" 303 0 "-" "Nextcloud Server Crawler" 127 0.028 [apps-nextcloud-nextcloud] [] [<ip redacted>]:80 0 0.028 303 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /api/oidc/authorization?<params redacted> HTTP/1.1" 302 945 "-" "Nextcloud Server Crawler" 766 0.001 [core-authelia-http] [] [<ip redacted>]:9091 945 0.001 302 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /?<params redacted> HTTP/1.1" 200 1053 "-" "Nextcloud Server Crawler" 996 0.000 [core-authelia-http] [] [<ip redacted>]:9091 1053 0.000 200 <trace redacted>

[warioishere]

@joshtrichards I think the probe is following redirects. With OIDC, unauthenticated requests to the root URL are redirected to the provider. I see a request for / made by Nextcloud Server Crawler which is getting redirected to my provider. I'm curious if that's the request that's checking for headers. If that's the case, this issue should be reopened.

[05/Jun/2024:03:56:56 +0000] "GET / HTTP/1.1" 302 0 "-" "Nextcloud Server Crawler" 105 0.034 [apps-nextcloud-nextcloud] [] [<ip redacted>]:80 0 0.033 302 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /login HTTP/1.1" 302 0 "-" "Nextcloud Server Crawler" 110 0.021 [apps-nextcloud-nextcloud] [] [<ip redacted>]:80 0 0.021 302 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /apps/user_oidc/login/2 HTTP/1.1" 303 0 "-" "Nextcloud Server Crawler" 127 0.028 [apps-nextcloud-nextcloud] [] [<ip redacted>]:80 0 0.028 303 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /api/oidc/authorization?<params redacted> HTTP/1.1" 302 945 "-" "Nextcloud Server Crawler" 766 0.001 [core-authelia-http] [] [<ip redacted>]:9091 945 0.001 302 <trace redacted>
[05/Jun/2024:03:56:56 +0000] "GET /?<params redacted> HTTP/1.1" 200 1053 "-" "Nextcloud Server Crawler" 996 0.000 [core-authelia-http] [] [<ip redacted>]:9091 1053 0.000 200 <trace redacted>

very good point! Could be the cause, I am also using external auth server (SAML SSO Keycloak)
I have another private server which doesnt use the Keycloak Server for authentication, same setup, but it doesnt show the error!

[joshtrichards]

Folks, just because you're seeing the same warning, doesn't mean it's always the same underlying cause. :-)

If you're using external authentication then #44234 sounds more relevant.

This issue is closed because the original reporter's situation was addressed (they closed it). Their cause was a DNS/hostname matter (which is a common reason for this error to occur because it means the test doesn't run against the proper service).

Other than external authentication (#44234), this is a configuration matter (at least as far as known causes go).

The reason you're seeing this trigger after an upgrade is because, in part, the checks are getting better and more sensitive, but mostly because the checks are running server-side rather than client-side now. So if there are configuration problems within your server environment (i.e. mismatched DNS, weirdly configured trusted_domains and overwrite.cli.url values in your Nextcloud config.php, etc.) that is coming out.

So take follow-up to the help forum if you're not in the #44234 camp. ;-)

[gravelfreeman]

@joshtrichards I'm in the #44234 camp. Using Traefik + SSO with Authelia. If I disable SSO, the warning disappears. Is it a config issue or there's really an issue? Because if it's only a config issue there's a lot of people waiting in this issue.