Hi @brunozh,
welcome, and thanks for the clear description of what you want.
One thing first: the support template is missing from your post. It is not there to make life harder, it carries the details that decide the answer here — Nextcloud version, web server, whether you run bare metal, Docker or AIO. Please edit your post and add it, it saves everyone a round of guessing.
What I would do instead
You already have a subdomain layout, so use it. Put the public landing page on xxx.ch (or www.xxx.ch) and redirect that to your IntraVox share:
server {
listen 443 ssl;
server_name xxx.ch www.xxx.ch;
ssl_certificate /etc/letsencrypt/live/xxx.ch/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/xxx.ch/privkey.pem;
# your public IntraVox URL, exactly as it appears in your browser
return 301 https://cloud.xxx.ch/lapps/intravox/s/<token>?page=<page-id>;
}
Watch the certificate: a wildcard for *.xxx.ch covers www.xxx.ch and cloud.xxx.ch but not the apex xxx.ch, that one needs its own SAN entry.
cloud.xxx.ch then stays exactly what it is: your Nextcloud, with its normal login page, working desktop and mobile clients, and nothing to explain to anyone later. Visitors who type the plain company domain land on the intranet page, and the button you mentioned links to https://cloud.xxx.ch/login from there.
That is what separate subdomains are for. Bending the root of the Nextcloud subdomain is the more expensive way to get the same result.
Redirecting / on the Nextcloud domain
I would not go down that road, and not because it is hard to write. The root of a Nextcloud is not a free slot. The example configuration in the admin manual already has a rule sitting there:
location = / {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
}
Your own location = / replaces that block, and the WebDAV client built into Windows Explorer loses the entry point it depends on.
Everything immediately below the root is configured territory as well: /.well-known/caldav and /.well-known/carddav for calendar and contacts discovery, /remote, /index.php. An exact match leaves those alone, but the difference between location = / and location / is one character, and getting it wrong takes the whole instance with it.
The part nobody plans for is what happens afterwards. When a client fails against a server that answers the root with a redirect, it does not report “your homepage redirect broke me”. You get a vague error, months later, from a colleague, and nothing in Nextcloud points at the web server config. Meanwhile the share token is hardcoded in that config, so recreating the share silently kills the homepage too.
A second server block costs you six lines and none of this.
And to answer the part you already tried: config.php has no setting for this either. defaultapp only applies after login, it has no effect on an anonymous visitor hitting /.
One question about your URL
You wrote https://cloud.xxx.ch/lapps/intravox/s/.... I don’t run IntraVox myself, so I may well be missing something, but /lapps/ is not a prefix I recognise. Could you check it against what your browser actually shows? If there is a rewrite somewhere in your setup, please say so, because it changes what a redirect on top of it would do.
h.t.h.
ernolf