Maybe document subfolder based access (example)

[joshtrichards]

There's a distinction between a subfolder installation of Nextcloud (i.e. somewhere under the docroot) and merely making Nextcloud reachable via a subfolder style URL (https://domain.tld/nextcloud). The former is not something relevant to this image, while the latter is a config matter (including reverse proxy integration)

There's probably an opportunity to improve upstream documentation and/or our docs & examples here at the Docker level.

I mention this so that maybe we can finally close out the following issues:

• #401
• #1919
• #2187
• #1047

[tzerber]

Current setup: latest fpm NC running at nextcloud_app:80, config.php allowing the domains below. Proxy listening on https://x.domain.com and NC working fine, then added secondary https://y.domain.com pointing to another working service(not nextcloud). Then added location https://y.domain.com/nextcloud pointing to nextcloud_app:80 to the proxy, and upon opening said url NC forwarded me to the / of the y.domain.com. I know apache rewrite can do this kind of magic, but out of the box it's not working here, so I doubt only proxy config is enough. Probably custom config for fpm variant and custom rewrite config for apache variants because nginx/apache approach to this is different.

[joshtrichards]

There are a couple of ways of approaching this, but here's the one I just tested.

• Just stick with the standard (non-subdirectory) config for web
• Then on your reverse proxy[1]:
  • add a standard proxy pass config for location /nextcloud/
  • have the proxy strip /nextcloud/ from the URI
• Set OVERWRITEWEBROOT=/nextcloud on the app service container so that URLs generated by Nextcloud are correct externally
• Set TRUSTED_PROXIES=172.28.0.0/12 or whatever you prefer for your environment

In the examples below, the Caddy work definitely works (I just tested it). The Nginx should work / should be equivalent:

[1] Reverse proxy configurations:

Nginx

location /nextcloud/ {
    proxy_pass http://web/;

Note: the backslash above is critical otherwise the URI prefix will not be stripped.

Ref: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

Caddy

:80, :443 {
	handle_path /nextcloud/* {
    		reverse_proxy web:80
	}
}

Ref: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#examples

[rriemann]

There are a couple of ways of approaching this, but here's the one I just tested.

* Just stick with the standard (non-subdirectory) config for `web`

* Then on your reverse proxy[1]:
  
  * add a standard proxy pass config for `location /nextcloud/`
  * have the proxy strip `/nextcloud/` from the URI

* Set `OVERWRITEWEBROOT=/nextcloud` on the `app` service container so that URLs generated by Nextcloud are correct externally

* Set `TRUSTED_PROXIES=172.28.0.0/12` or whatever you prefer for your environment

In the examples below, the Caddy work definitely works (I just tested it). The Nginx should work / should be equivalent:

Hi @joshtrichards , can you please share which docker image flavour and version you have used? Was it apache/fpm/nginx/alpine/... ?

Best, Robert

[joshtrichards]

The above was with:

• fpm (app container)
• nginx (web container)
• caddy or nginx (reverse proxy)

The app and web container combination shouldn't make much difference (should work equally well with the apache one). All the heavy lifting to support this is being done by:

• the reverse proxy (the example configs I posted above)
• configuring Nextcloud appropriately (the config parameters I posted above)

[rriemann]

Caddy and the nextcloud:fpm image is a non-obvious combination. After debugging until 3am, I found out that Caddy is not stripping the path from the CGI environment variable REQUEST_URI, but only from PATH_INFO. The maker of Caddy insists that is how the spec works and other software would need to be fixed (here php-fpm or nextcloud).

More info here: https://help.nextcloud.com/t/nextcloud-docker-compose-setup-with-caddy-2024/204846/10?u=rriemann

[joshtrichards]

Caddy and the nextcloud:fpm image is a non-obvious combination.

Note I am referring to Caddy (or Nginx) at the reverse proxy layer, not as the web server.

In my test case, a standard[^caddy] nginx server (i.e. running a typical Nextcloud nginx config) remained at the web server layer (itself connected to fpm).

In theory the reverse proxy and web layers could be merged, as in any Nextcloud deployment, but I did not test that.

Also, it makes it universally useful with either edition of our image.

---
title: FPM image (web+fpm)
---
graph TB
  reverse_proxy --> web
  web --> fpm

---
title: Apache image (web+mod_php)
---
graph TB
  reverse_proxy --> web+mod_php

[^caddy]: Currently there being no published "official" Caddy web server config for use with Nextcloud, though it seems one is progressing (see nextcloud/documentation#9199).