Your web server is not properly set up to resolve "/.well-known/caldav" or "/.well-known/carddav"

jfly commented 2 months ago

Describe your Issue

After installing the helm chart, I see warnings like this on /settings/admin/overview:

Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the documentation ↗.
Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the documentation ↗.

Logs and Errors

In my browser console, I see the following errors:

Refused to connect to 'http://[redacted]/remote.php/dav/' because it violates the following Content Security Policy directive: "connect-src 'self'".
Refused to connect to 'http://[redacted]/remote.php/dav/' because it violates the following Content Security Policy directive: "connect-src 'self'".
GET https://[redacted]/.well-known/nodeinfo 404 (Not Found)
GET https://[redacted]/data/.ocdata?t=1713053623792 404 (Not Found)
GET https://[redacted]/.well-known/webfinger 404 (Not Found)

Describe your Environment

Kubernetes distribution: k3s
Helm Version (or App that manages helm): Pulumi 3.108.1
Helm Chart Version: 4.6.6
values.yaml:

- cronjob:
    enabled: true
  externalDatabase:
    database: '[redacted]'
    enabled: true
    host: '[redacted]'
    password: '[redacted]'
    type: postgresql
    user: '[redacted]'
  ingress:
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-prod
      traefik.ingress.kubernetes.io/router.entrypoints: websecure
      traefik.ingress.kubernetes.io/router.middlewares: default-strict-https@kubernetescrd
    enabled: true
    tls:
    - hosts:
      - '[redacted]'
      secretName: nextcloud-tls
  internalDatabase:
    enabled: false
  metrics:
    token: '[redacted]'
  nextcloud:
    configs:
      custom.config.php: "<?php\n$CONFIG = array (\n  // Traefik is the entrypoint\
        \ into our cluster. Trust its\n  // X-Forwarded-* headers.\n  'trusted_proxies'\
        \ => array(\n    0 => '127.0.0.1',\n    1 => '10.0.0.0/8',\n  ),\n  'forwarded_for_headers'\
        \ => array('HTTP_X_FORWARDED_FOR'),\n  // https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#default-phone-region\n\
        \  'default_phone_region' => 'US',\n  'maintenance_window_start' => 11,  //\
        \ 11am UTC = 3 or 4 am Pacific\n);\n"
    host: '[redacted]'
    password: '[redacted]'
    username: '[redacted]'
  persistence:
    enabled: true
    nextcloudData:
      enabled: true
      storageClass: manual
    storageClass: manual
  phpClientHttpsFix:
    enabled: true
  redis:
    auth:
      password: '[redacted]'
    enabled: true

Additional context, if any

The issue here is that my ingress (traefik) terminates https, and then initiates a http connection to my nextcloud service. This results in apache/nginx giving me redirects back to a http url, which my webbrowser refuses to follow thanks to the Content Security Policy (see above logs from my browser console). For example note how this https request gets a redirect to a http url:

$ curl -is https://[redacted]/.well-known/carddav | grep -i '^location:'
location: http://[redacted]/remote.php/dav/

This happens to me with both the apache and nginx flavors. Ideally, nextcloud could be configured to trust the X-Forwarded-Proto header. For example, in nginx, the fix would be to change this redirect to use the $http_x_forwarded_proto variable:

        location = /.well-known/carddav     { return 301 $http_x_forwarded_proto://$host/remote.php/dav/; }

provokateurin commented 2 months ago

i promise this is not relevant

No, please include this. Without the values it is way harder to debug and the issue might be in your values.

jfly commented 2 months ago

Sure thing, I've added a redacted version of my values.yaml. But just to emphasize my earlier point: I have described the root cause in "Additional context, if any" section. Unless I'm completely misunderstanding things, hopefully that proves my values.yaml is not relevant.

provokateurin commented 2 months ago

The problem is very likely that you didn't specify overwrite.cli.url which is necessary so that Nextcloud can generate the correct URLs to redirect. Clearly you don't have it specified in your values.yaml, so those are relevant to the problem.

jfly commented 2 months ago

Sorry, I'm confused. That setting affects urls generated by the nextcloud php application, right? What I'm talking about here are redirects generated by apache or nginx. IIUC, there's no php code involved in this at all.

provokateurin commented 2 months ago

This results in nextcloud giving me redirects back to a http url

This sounds like it's Nextcloud and not the webserver? Please check where the redirect originates from.

jfly commented 2 months ago

This sounds like it's Nextcloud and not the webserver

Sorry, that was confusing. I've edited it to say "This results in apache/nginx giving me redirects back to"

Please check where the redirect originates from.

For the nginx flavor, this redirect comes from the location ^~ /.well-known block here: https://github.com/nextcloud/helm/blob/nextcloud-4.6.6/charts/nextcloud/templates/nginx-config.yaml#L89. For the apache flavor, the redirect comes from the .htaccess file here: https://github.com/nextcloud/server/blob/v28.0.4/.htaccess#L88-L89

nextcloud / helm