Nextcloud install adds a server-wide .well-known Cal/CardDAV redirect that breaks other vhosts

Troubleshooting
1

Required Information

  • DietPi version: v10.7.2 (master)
  • Distro version: Debian GNU/Linux 13 (trixie)
  • Kernel version: 6.18.45-current-rockchip64, aarch64
  • SBC model: ROCK 4 (aarch64)
  • Webserver: Apache/2.4.68 (Debian)
  • Additional software: Nextcloud 34.0.4

What did I expect

Installing Nextcloud should configure the Cal/CardDAV .well-known redirects for the
Nextcloud site only, and leave other virtual hosts on the same server untouched.

What happened

dietpi-software writes the redirects into a server-wide Apache snippet and enables it
globally (dietpi-software, lines 4786-4789):

# Cal/CardDAV redirects to Nextcloud DAV endpoint
echo '# Redirect Cal/CardDAV requests to Nextcloud endpoint
Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav  /nextcloud/remote.php/dav' > /etc/apache2/conf-available/dietpi-dav_redirect.conf || exit 1
G_EXEC a2enconf dietpi-dav_redirect

Because conf-enabled applies to every virtual host, this has three effects:

  1. It affects unrelated vhosts. On my server a Radicale vhost (carddav.example.org,
    separate ServerName, nothing to do with Nextcloud) had its own .well-known discovery
    redirected into the Nextcloud path. After disabling the snippet, Radicale answers its own
    discovery again.

  2. The target path only fits DietPi’s subdirectory install. Anyone running Nextcloud from
    the document root of an own vhost gets a redirect to a path that does not exist. Nextcloud’s
    own setup check reports it:

    Your web server is not properly set up to resolve `.well-known` URLs, failed on:
`/.well-known/caldav`

    This is how I found it — the admin overview page had been warning about it, and the cause was
    the global snippet, not the Nextcloud configuration.

  3. It is redundant for Nextcloud itself. Nextcloud’s shipped .htaccess already contains
    the equivalent rewrite rules for /.well-known/carddav and /.well-known/caldav.

Suggestion

Move the redirects from the global conf-available snippet into the Nextcloud site
configuration (dietpi-nextcloud.conf), so they apply to the Nextcloud vhost only. The lighttpd
(lines 4806-4812) and nginx (lines 4829-4832) branches use the same global approach, as does the
Baikal installation (lines 8160-8163, 8169-8175, 8182-8184).

Workaround

a2disconf dietpi-dav_redirect
systemctl reload apache2

and put the redirects into the vhost that serves Nextcloud:

Redirect 301 /.well-known/carddav /remote.php/dav
Redirect 301 /.well-known/caldav  /remote.php/dav

A vhost-level Redirect takes precedence over the global one — I verified this by re-enabling
the snippet temporarily — so a later re-install that runs a2enconf again does not undo the fix.