docker/.examples/docker-compose/with-nginx-proxy/mariadb/fpm/docker-compose.yml

[elmero1]

Hi My Nextcloud Installation is 22.2.0 and I use the following docker-compose example: docker/.examples/docker-compose/with-nginx-proxy/mariadb/fpm/docker-compose.yml

In the admin center i got these warnings: Your web server is not properly configured to resolve "/.well-known/webfinger". Your web server is not properly configured to resolve "/.well-known/nodeinfo". The php-imagick module lacks SVG support. For better compatibility it is recommended to install it.

Not the exact wording of the messages, I have translated the messages into english.

I found some info on the internet for the first two warnings, however it does not work for my setup. Do you have any concrete ideas for my setup (nginx-proxy,fpm,..)?

Thanks in advance.

Patrick

[driscollw]

I have this error in my setup.

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

I have this warning as well and working on trying to figure out what is causing this. When I had this in the past the fix was not with Nextcloud but my reverse proxy.

[yangtudou]

Hi, I had the same problem, my current solution is as follows:

• ⚠️ "/.well-known/webfinger"

Add the following code to the configuration file config.php

'check_for_working_wellknown_setup' => false,

• ⚠️ php-imagick

Enter the nextcloud container

if in alpine

apk --update add imagemagick 

other (eg:apance)

apt install libmagickcore-6.q16-6-extra

[thomasmerz]

Can this also be done with docker-compose.yml? So it would be persistent for all newly recreated and updated nextcloud docker container… 🤔

[schnillerman]

I have a similar problem, but could - for an already composed instance - solve it this way:

In the docker-compose.yml, I added a file link for nginx.conf since Iwant to persist it (otherwise, it would always be copied by the Dockerfile and not be reachable from outside the container for modifications:

- /volume1/docker/nextcloud/nginx/nginx.conf:/etc/nginx/nginx.conf

I commented the copy nginx.conf command in the Dockerfile so it's not executed anymore.

Now, as all containers have successfully started, I get the same error about webfinger, carddav, caldav and nodeinfo.

After editing the nginx.conf and restarting the nginx container (web), I could solve this for e.g. webfinger:

# Make a regex exception for `/.well-known` so that clients can still
    # access it despite the existence of the regex rule
    # `location ~ /(\.|autotest|...)` which would otherwise handle requests
    # for `/.well-known`.
    location ^~ /.well-known {
        # The rules in this block are an adaptation of the rules
        # in `.htaccess` that concern `/.well-known`.

        location = /.well-known/carddav { return 301 https://[my-domain]/remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /remote.php/dav/; }

        location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
        location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

        # Let Nextcloud's API for `/.well-known` URIs handle all other
        # requests by passing them to the front-end controller.
        return 301 /index.php$request_uri;
    }

In the first location entry; I experimentally added the FQDN along with the protocol and now for carddav, the warning is gone. See the bold / marked text in the following line:

location = /.well-known/carddav { return 301 https://[my-domain]/remote.php/dav/; }

In fact, setting a variable in the server directive of nginx.conf and using it in the location directives makes things easier and works, too:

set $external_scheme_http_host https://[my-domain];

However, this doesn't seem to be a solution for docker-compose since the FQDN might change. But how is the FQDN known to nextcloud or nginx anywa y? I had to hardcode some domain-name related variables in NC's config.php, too:

'overwrite.cli.url' => 'https://[my-domain]', #changed by me from 192...
'overwriteprotocol' => 'https', #added by me

So it seems that in case of an FQDN change, you need to touch not only the docker compose, but also NC's config.php and nginx.conf?

Or is there a way to provide the FQDN in a docker compose as a variable for all services to be substituted when composing?

[J0WI]

#1414 a92ea907312ac6d072b36fa76d11b6c9b5a4b8e6