After upgrade to 29 getting trusted_proxies error

[flotillaropes]

Update to 29. Check overview. New error:
There are some errors regarding your setup.
Your “trusted_proxies” setting is not correctly set, it should be an array of IP addresses - optionally with range in CIDR notation.

I run linuxserver nextcloud container and reverse proxy through linuxserver swag container. In my config.php, per linuxserver instructions I’ve always set my trusted proxy like this:

‘trusted_proxies’ =>
array (
0 => ‘swag’,
),

Note, the swag and nextcloud container are in same compose file and on same docker network.

I googled around and found this:

fix(settings): Also verify that `trusted_proxies` only contains IP addresses...

This has always worked without errors. Suddenly after the update to 29 the error appears.

Has something changed in 29 where the trusted proxy is now required to be an IP address and can no longer be a hostname or container name? This makes no sense in a docker environment where when 2 containers are in same compose file and share same network it’s perfectly acceptable practice to use container names and docker will resolve the container names properly.

Interestingly my nextcloud seems to be working fine despite the error.

[bb77]

@flotillaropes

fix(settings): Also verify that `trusted_proxies` only contains IP addresses (with range) · 3203db8160 - mirrors/nextcloud-server - Sadium Git

This links to a third party site. Here’s the original Pull Request in the Nextcloud server repo.

So yes they seem to have added a check, that generates a warning when something else than IP addresses are used in the trusted proxies array.

@flotillaropes

This makes no sense in a docker environment where when 2 containers are in same compose file and share same network it’s perfectly acceptable practice to use container names and docker will resolve the container names properly.

I’m not a developer, so I can’t tell you what the rationale behind this change was, but feel free to open an issue here and voice your concerns.

[flotillaropes]

It’s not issuing a warning. It’s issuing an error with a big red X. The big question is can this error be ignored? It appears it can as nextcloud is working and throwing no errors and the log is clean. My understanding is if trusted proxy is incorrect, nextcloud will throw an error and be unreachable. Perhaps someone can confirm this behavior?

It’s worth mentioning the last time I documented an important bug here many months have passed along with several releases without being fixed so it doesn’t give me much confidence in doing so again.

[bb77]

@flotillaropes

The big question is can this error be ignored? It appears it can as nextcloud is working and throwing no errors.

I don’t know. But opening an issue might be a good way to find out

@flotillaropes

It’s worth mentioning the last time I documented an important bug here many months have passed along with several releases several releases without being addressed so it doesn’t give me much confidence in doing so again.

Opening an issue is probably your best chance of getting it addressed, unless you want to dig into the code to find out by yourself whether or not the error message can be ignored. Or, you could wait for someone else to find out or opening an issue, or for the developers to fix/change it again without anyone intervening…

[flotillaropes]

Understood, but probably won’t repeat the effort. However, if someone can verify my understanding that if the trusted proxy is set incorrectly, nextcloud will display a trusted proxy error and not work. Is this correct?

[bb77]

@flotillaropes

nextcloud will display a trusted proxy error and not work. Is this correct?

Well, I’d guess so.

But, it’s also quite possible that the check does not actually perform a function check, but only looks at the values in config.php and then complains if it finds anything other than IP addresses. In this context, it is of course also possible that your Docker scenario was simply not considered.

However, these are all just speculations on my part, and I can’t provide you with a definitive answer about the technical details and whether there are any negative side effects if you just ignore the message.

But maybe someone else will chime in here, or maybe you will open an issue after all, I mean the worst that can happen is that you have invested a few minutes of your time without getting any direct benefit from it. Worse things happen in life…

[flotillaropes]

@bb77

And yes, it is quite possible that the check does not actually perform a function check, but only looks at the values in config.php and then complains if it finds anything other than IP addresses. In this context, it is of course also possible that your Docker scenario was simply not considered.

I added a reply here which will hopefully receive a timely response.

[flotillaropes]

Graciously addressed quickly by the dev team. Thank you! I suggest reading the thread for the explanation, but in summary:

However you could do this:

'trusted_proxies' =>
array (
0 => gethostbyname('swag'),
),

[Zenhighzer]

Same problem… nextcloud is running in a container

my config looks like:

‘trusted_proxies’ => [‘192.168.10.70’, ‘172.17.0.1’, ‘127.0.0.1’],

In the access-logs I can see connections from my reverse proxy 192.168.10.70 … not good, because my fail2ban cant allocate failed logins from real clients anymore

[MarslMarcello]

I had a similar Issue and tried some config with IP of the server and w/o. Now it’s “127.0.0.1” only, and the error disappeared. Not sure if this is a solution we were looking for, but I will keep an eye on it with upcoming patches.

[danaj525]

So after messing around with this for a few minutes, I used the IP with no ports instead of the website name and it worked. Not sure if that’s what we need but I don’t see the error anymore.

‘trusted_proxies’ =>
array (
0 => ‘255.25.255.255’,
),