Nginx nextcloud location issue with carddav and caldav

So I have been installing multiple nextcloud installations on subdirectories i.e domain.com/a001, domain.com/a002 and so on.

in nginx configuration file to deal with carddav and caldav warning, I am adding following block per subdirectory as suggested in documentation.

    location = /.well-known/carddav {
      return 301 $scheme://$host:$server_port/a001/remote.php/dav;
    }
    location = /.well-known/caldav {
      return 301 $scheme://$host:$server_port/a001/remote.php/dav;
    }  

this works for a001 but when I use the same for a002 the location block duplication error comes in nginx and it fails which is the correct response from nginx.

Is there any workaround to have it setup for multiple nextcloud installation in subdirectories.

I will really appreciate all the help and thanks a lot for your time in advance.

[/details]

Nextcloud version: 18.0.2
Operating system and version: kubernetes, Docker
Docker image: nextcloud:latest

The issue you are facing:

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. install multiple nextcloud installation in subdirectories i.e domain.com/a001, domain.com/a002
* Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the [documentation](https://docs.nextcloud.com/server/18/go.php?to=admin-setup-well-known-URL).
* Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the [documentation](https://docs.nextcloud.com/server/18/go.php?to=admin-setup-well-known-URL). 

The output of your Nextcloud log in Admin > Logging:

No log related to this.

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'passwordsalt' => 'weeicwufhewoifigerugnv/y5MVFSFJbw',
  'secret' => 'DINH+klfjksdfsdjfsdjfkjsdlkfjksdjklf',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'domain.com',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '18.0.4.2',
  'overwrite.cli.url' => 'http://localhost',
  'dbname' => 'a002_db',
  'dbhost' => 'proxysql:6033',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'exampleu',
  'dbpassword' => 'examplepass#',
  'installed' => true,
  'instanceid' => 'exampleid',
  'overwritewebroot'  => '/a002',
  'trusted_proxies' =>
  array (
    0 => 'localhost',
    1 => 'domain.com',
  ),
);

No, because it is not possible to redirect a URI to several different targets.

You have two options:

  • Decide which subdirectory installation you want to use for service-discovery and ignore the warnings in the admin-panel of all other subdirectory installations of Nextcloud on the same server.

  • Set up different servers for your different Nextcloud installations.

1 Like

It might be better to setup the different instances on own subdomains instead of different paths. Then you have different urls of .well-known based on the subdomains

2nd option is just too costly. I was looking for multi tenancy so that multiple organisations can work with same nextcloud. but this is as closest I get to that with kubernetes.

Solutions should include subdirectories.

is there any way to ignore these warnings with occ. if I can automate that then it will resolve most of the issues.

Not that I know of. The only possibility is to edit the source code which will give integrity-check warnings. But replacing one warning with another warning is probably not what you want.

Be aware that caldav/carddav synchronisation might not work, if those .well-known redirects are not properly configured (which will be the case, if you use several different installations under a single fqdn).