Please try passing below environment variable to your nextcloud docker container:
"NEXTCLOUD_TRUSTED_DOMAINS=nextcloud.example.com",
Please try passing below environment variable to your nextcloud docker container:
"NEXTCLOUD_TRUSTED_DOMAINS=nextcloud.example.com",
Based on the documentation, this variable is used for autoconfiguration when the container is initialized, after which time it has no effect.
I have set the trusted_domains
value through the configuration command, as explained in another discusssion.
trusted_hosts should the name/ip of your reverse proxy (in docker usually the container_name)
trusted_domain is the hostname you use to access you application like nextcloud.my.domain
there are only few variables please read and understand the reverse proxy manual carefullyā¦ and once it doesnāt work collect configs and logs so we can see what is going wrong
Here is my configuration. I use nginx reverse proxy, which I had to learn as I came from Apache. Iām a non-expert in both, having worked in IT years ago.
Everything works on my system. I need to point out that some of the entries I could have removed as theyāre redundant and you will see a lot of # where Iāve edited out config and not returned to clean up the files so apologies for the mess.
192.168.1.4 is my server.
192.168.1.1 is my router.
nextcloud.domainname.com represents my domain name edited for privacy.
I use the reverse proxy to handle the SSL from acme and the config for CALDAV and CARDDAV.
I havenāt seen your configuration but wwe has give you the answer correctly. Although, I think you need to see an example.
My nextcloud is in a docker. I always upgrade nextcloud inside the docker, rather than the docker itself. Be aware of differences like php versions etc. I would not recommend simply copying my config but trying to check the differences between mine and yours.
Happy to try and help, but Iām very busy at the moment with some tight deadlines so apologies if I donāt respond in a hurry. Once again, Iām not an expert but Iāve invested a lot of time getting my system how I want it. The experts may even read my config and laugh but it gets an A+ security rating from Nextcloud when I do a security check.
NOTE: The intention was to upload my config files in a quote. The quote function on this forum thread is terrible!!
You can pull it from here:
Nextcloud and nginx reverse proxy configuration
Let me know if this helps, Iād like to know if I helped somebody
Also, Iām running similarly to copaxyās configuration. My docker is sitting on unRaid.
@wwe: I suppose I had confused trusted_hosts
and trusted_domains
.
I have now set trusted_domains
to the domain name for use by the client browser, and trusted_hosts
to the name of the container as understood by Docker. I have kept also trusted_proxies
unset.
I no longer see the error message generated by Nextcloud, but instead find that the Nextcloud returns a redirect command that affects the domain name. This change causes further problems.
How would I configure Nextcloud to keep from redirecting to a different host name than was originally used by the client?
I am sorry if these answers might be available from the documentation, but after reviewing it, I find a great deal of confusion from the various manuals and deployment styles.
brainchild, you need to consider that we have to imagine what your issue is, because youāre not providing enough information ie. screenshots, logs, etc.
If you are using a reverse proxy, why would you leave it unset? You need to tell Nextcloud to trust that proxy.
Also, did you look at the configuration in the link that Iāve shared with you?
Youāve provided very little information to try and get the issue resolved.
At this time, I am trying to understand which variables should take which values for us to expect the application to behave as desired.
Once we reach that point, it may be helpful for me to share logs, configuration files, and so. For the time being, I would rather get advice on the proper settings for the variables. I have no reason for not setting trusted_proxies
other than not currently having reached an understanding of what value it should have for the particular configuration.
Unfortunately, as I say, the various documents have caused me confusion about how each variable is used in different contexts.
As long as I am not understanding what value the variables should take, I feel that screenshots and logs are more likely to be distracting than helpful. Thanks.
Uuhhmmā¦okay . I guess we all need to decide what our troubleshooting methodology looks like. Iāll leave up the link to my configuration, it may help others.
Good luck!
@conradp24: I think your idea of troubleshooting methodology is fine. It may be more helpful, however, to think of my inquiry as about understanding the meanings of the configuration variables, rather than as about troubleshooting.
did you read Nexcloud documentation? all the variables are clear described there. docker documentation explains how to use them in docker environment
the variables clearly described there:
overwritehost
set the hostname of the proxy. You can also specify a port.overwriteprotocol
set the protocol of the proxy. You can choose between the two options http and https.overwritewebroot
set the absolute web path of the proxy to the Nextcloud folder.overwritecondaddr
overwrite the values dependent on the remote address. The value must be a regular expression of the IP addresses of the proxy. This is useful when you use a reverse SSL proxy only for https access and you want to use the automatic detection for http access.
If you still hit some issue please describe the problem in detail, so we can understand it and help you to solve it.
I had read the documentation, and found it quite confusing.
The most recent problem was resolved by setting overwriteprotocol
to https
, though it seems to me this particular inference is impossible from the documentation alone. At present, I believe the entire installation is functioning, at least with respect to the issues immediate to my question.
I would like to express my view that the documentation for the container might be improved greatly through giving it a more direct and accessible structure, as well as clarification of how the various explanations for container usage relate to the general usage of the application. A helpful approach might be giving a clear indication of whether any explanation of the former simply reiterates the design of the application generally, or rather illustrates augmented or distinctive behavior compared to the latter.
Comments such as the following would be helpful, in the appropriate case:
The following summarizes Nextcloud behavior, which is described in greater detail in the general manual.
Nextcloud running from the official Docker container behaves differently from a regular installation the following ways.
The documentation for the configuration options in the general manual, for the most part, also is confusing and unclear.
Generally, helpful documentation of a configuration parameter includes answers to a combination of several of the following questions:
Following are some examples, for various parameters, of documentation that might be much more helpful than those in the current revision of the manual:
overwriteprotocol
: May be set to either ofhttp
orhttps
.Nextcloud normally assumes that the client should use same protocol, that is, secure versus insecure HTTP, for access to Nextcloud, as used by any proxy, and will try to change the address for client access accordingly, by returning a HTTP redirect directive each time the client uses the other protocol. If the protocol for client access is different than for access by the proxy , then this this value must be set to the protocol to be used by the client. For example, if the connection between Nextcloud and the proxy is insecure, but clients are to use a secure connection, then this value must be set to
https
.
trusted_hosts
: The host names, as appears in the address, clients are allowed to use for accessing Nextcloud.For security, Nextcloud allows access only through host names designated in the site configuration. Access through other host names will generate an error page. This value always should be set to the allowed host names for access directly by the client, even if the client is accessing Nextcloud through a reverse proxy. Note this parameter is different from
trusted_domains
, which establishes trust for the reverse proxy.
I agree this might be be described better for beginnersā¦ You went a hard way to understand how it works - please write either a guide here or even better create a pull request with improved version of the manualā¦
My summary - Nextcloud running behind reverse proxy (especially docker) has no idea how the client can reach resources like filesā¦
say you have a docker container called nextcloud and you access it using public DNS record https://mynextcloud.dyndns.xyz. you reverse proxy traefik/nginx/apache terminates TLS and sends all requests without TLS to your nextcloud container. by default Nextcloud would use the protocol of incoming request and build the URL for *mycat.png as http://nextcloud/files/mycat.png to make URLs on Nextcloud work your container must build URLs like https://mynextcloud.dyndns.xyz/files/pictureofmycat.png where
OVERWRITEPROTOCOL
OVERWRITEHOST
trusted_proxies
define the proxy host which is allowed to perform requests for another clientsBased on certain comments in the documentation, I came to understand that many proxies save information about the original request in extended header fields. Might Nextcloud apply the values of those fields to resolve a resource address appropriate for the original request form the client?
trusted_proxies variable instructs Nextcloud to check x_forwarded_for (and x_real_ip?) flags. but maybe not every piece of information is passed (by every proxy). I think the overwrite* settings are the most stable solution.
My suggestion is to use whatever fields are made available by the proxy to guess as accurately as possible how to reconstruct the client address, even if those same fields may not be available from other proxies. This design simplifies site configuration in many cases. The main drawback is reduced portability of the same application deployment through different proxies, but I suggest that this problem is a smaller inconvenience compared to the alternative, since changing proxies on the same site is not a common event.
With respect to the logic currently in place, explained to some degree in the manual, and which you have tried to clarify, I remain very confused. Hopefully, someone who understands the design would be able to update the manual to make it more helpful for those with limited familiarity of these systems.
If I might make one more suggestion, rather than separate fields for hosts and protocols, I would find it simpler to provide a list of full addresses (e.g. http://cloud.domain.xyz
) of possible base addresses for client access, and let the application choose the best match from the list based on the fields available in the request header.
I agree full fqdn like ābase URLā (full address in your words) would be the simplest solution both for administration, programming and understandingā¦ most likely current situation results from history and as everybody knows how it works there is little motivation to change itā¦ I assume multiple different base URL are not really common so there is no common need to add thisā¦
You are welcome to adopt the code and file a pull request at Github.
Well, I never feel good when someone comments āeveryone knowsā, followed by something I donāt know.
I believe it is common, actually. Many hosts are accessed by different names, or protocols, especially when the same one is used both within and beyond a local network.
I got a new problem after I think I solved the proxy one similar to brainchild:
Your data directory and files are probably accessible from the internet because the .htaccess file does not work. For information how to properly configure your server, please see the documentation.
I found the following potential solution, however, my brain is burn and I dont know what to do with this: [FIXED] Htaccess file is not working
I try to edit the config.php by accessing docker from the command prompt and powershell (Win10) however once reached the files, neither nano config.php or vi config.php would work, saying it wasnt a ābashā command or something to that endā¦I also tried notepad config.php and notepad.exe config.php with the same fate! kill me now!
Thanks to @wwe and everyone else that postedā¦ I did fix one one of issues similar to brainchild after reading through the post and reading the documentation exhaustively. @brainchild not sure if you fix your issue but adding the overwrite host/protocol/webroot to mine did the trick - Iām sharing my config in case it helps someone else.
.
Potential Solution to ProxyPass issue
My Setup:
References for the example:
Steps:
version: "3"
# some from: https://www.cloudsavvyit.com/12476/how-to-self-host-a-collaborative-cloud-with-nextcloud-and-docker/
services:
nextcloud:
image: nextcloud:latest # not sure if this is the best/optimal choice - recommendations/comments welcome!
restart: always
ports:
- 8080:80
environment:
- MYSQL_HOST=db
- MYSQL_DATABASE=db
- MYSQL_USER=nextcloud
- MYSQL_PASSWORD=passExample
- NEXTCLOUD_TRUSTED_DOMAINS=localhost example.mainsite.com # each option should be separate by a space as per documentation - not sure if I need more/less at this point
- TRUSTED_PROXIES=192.168.1.A example.mainsite.com # each option should be separate by a space as per documentation - not sure if I need more/less at this point
- OVERWRITEHOST=example.mainsite.com # from: https://help.nextcloud.com/t/docker-reverse-proxy-and-trusted-domains/117891/26
- OVERWRITEPROTOCOL=https
- OVERWRITEWEBROOT=nextcloud # from documentation and help from the forum - thank U!
volumes:
- nextcloud:/var/www/html
db:
image: mariadb
restart: always
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
volumes:
- db:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=passExample
- MYSQL_PASSWORD=passExample
- MYSQL_DATABASE=db
- MYSQL_USER=nextcloud
volumes:
db:
nextcloud:
.
Partial Proxy Pass config from nginx:
#
### NextCloud ###
location /nextcloud/ {
rewrite /nextcloud/(.*) /$1 break;
proxy_pass http://192.168.1.B:8080/;
proxy_redirect http://192.168.1.B/ https://;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
#
Hey guys , I think i am in the same situation. I am using ngrok which is a reverse proxy. abasically what it does is that it gives your localhost a url which you can use to access it from anywhere. Once i have the url i get the trusted doamin error when i click on the link.