Security & setup warnings does not work

The Basics

  • Nextcloud Server version (e.g., 29.x.x):

    • 30.0.4
  • Operating system and version (e.g., Ubuntu 24.04):

    • docker image
  • Web server and version (e.g, Apache 2.4.25):

    • nginx
  • Reverse proxy and version _(e.g. nginx 1.27.2)

    • traefik v3
  • Is this the first time you’ve seen this error? (Yes / No):

    • yes
  • When did this problem seem to first start?

    • don't know. Saw it today the first time
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)

    • docker
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)

    • no

docker compose file:

services:
    database:
        image: mariadb:10.11
        command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
        restart: on-failure
        volumes:
            - "./database:/var/lib/mysql"
        environment:
            - MYSQL_ROOT_PASSWORD=mypw
        env_file:
            - ./build/db.env

    redis:
        image: redis:alpine
        restart: always

    app:
        image: nextcloud:fpm-alpine
        restart: on-failure
        environment:
            MYSQL_HOST: database
            REDIS_HOST: redis
        env_file:
            - ./build/db.env
        volumes:
            - ./data:/var/www/html
        depends_on:
            - database
            - redis
    web:
        build: ./build/web
        restart: on-failure
        volumes:
            - ./data:/var/www/html/:ro
        labels:
            - "traefik.enable=true"
            - "traefik.http.routers.nextcloud.rule=Host(`nextcloud.mydomain.de`)"
            - "traefik.http.routers.nextcloud.tls.certresolver=myresolver"
            - "traefik.http.routers.nextcloud.entrypoints=websecure"
            - "traefik.http.routers.nextcloud.middlewares=nc-header,nc-rep"
            - "traefik.http.middlewares.nc-rep.redirectregex.regex=https://(.*)/.well-known/(card|cal)dav"
            - "traefik.http.middlewares.nc-rep.redirectregex.replacement=https://$$1/remote.php/dav/"
            - "traefik.http.middlewares.nc-rep.redirectregex.permanent=true"
            - "traefik.http.middlewares.nc-header.headers.customFrameOptionsValue=SAMEORIGIN"
            - "traefik.http.middlewares.nc-header.headers.customResponseHeaders.Strict-Transport-Security=15552000"
            - "traefik.http.services.nextcloud.loadbalancer.passHostHeader=true"
        depends_on:
            - app
        networks:
            - proxy-tier
            - default
    cron:
        image: nextcloud:fpm-alpine
        restart: on-failure
        volumes:
            - ./data:/var/www/html
        entrypoint: /cron.sh
        depends_on:
            - database
            - redis
    nextcloud-nc-backup:
        image: waja/calcardbackup
        links:
            - database:nextcloud-db
            - app:nextcloud
        environment:
            - CRON_TIME=0 0 * * *
            - INIT_BACKUP=yes
            - CALCARD_OPTS=-i -r 20
            - NC_DIR=/nextcloud
            - NC_HOST=web
            - NC_PORT=80
            - DB_HOST=database
        depends_on:
            - database
            - app
        restart: unless-stopped
        volumes:
            - ./calcardbackup:/backup
            - ./data:/nextcloud
            - /etc/localtime:/etc/localtime:ro
            - /etc/timezone:/etc/timezone:ro
        networks:
            - proxy-tier
            - default
networks:
    proxy-tier:
        name: proxy-tier
        external: true

Summary of the issue you are facing:

If I visit the settings → management → overview, the process "Security & setup warnings does not work " fails with error:
“There are some errors with your system configuration.
Error when checking the server setup”

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

{"reqId":"VYVhDbkrMNhtyu22J9T3","level":3,"time":"2025-01-16T12:02:51+00:00","remoteAddr":"172.18.0.2","user":"--","app":"core","method":"GET","url":"/apps/logreader/api/poll?lastReqId=4vWYyR3UqzDi39ELi8CT","message":"Exception thrown: Doctrine\\DBAL\\Exception","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:134.0) Gecko/20100101 Firefox/134.0","version":"30.0.4.1","exception":{"Exception":"Doctrine\\DBAL\\Exception","Message":"Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2002] Connection refused","Code":2002,"Trace":[{"file":"/var/www/html/3rdparty/doctrine/dbal/src/Connection.php","line":453,"function":"connect","class":"OC\\DB\\Connection","type":"->","args":[]},{"file":"/var/www/html/3rdparty/doctrine/dbal/src/Connection.php","line":411,"function":"getDatabasePlatformVersion","class":"Doctrine\\DBAL\\Connection","type":"->","args":[]},{"file":"/var/www/html/3rdparty/doctrine/dbal/src/Connection.php","line":318,"function":"detectDatabasePlatform","class":"Doctrine\\DBAL\\Connection","type":"->","args":[]},{"file":"/var/www/html/lib/private/DB/Connection.php","line":899,"function":"getDatabasePlatform","class":"Doctrine\\DBAL\\Connection","type":"->","args":[]},{"file":"/var/www/html/lib/private/DB/ConnectionAdapter.php","line":235,"function":"getDatabaseProvider","class":"OC\\DB\\Connection","type":"->","args":[]},{"file":"/var/www/html/lib/private/DB/QueryBuilder/QueryBuilder.php","line":96,"function":"getDatabaseProvider","class":"OC\\DB\\ConnectionAdapter","type":"->","args":[]},{"file":"/var/www/html/lib/private/AppConfig.php","line":1211,"function":"expr","class":"OC\\DB\\QueryBuilder\\QueryBuilder","type":"->","args":[]},{"file":"/var/www/html/lib/private/AppConfig.php","line":237,"function":"loadConfig","class":"OC\\AppConfig","type":"->","args":[false]},{"file":"/var/www/html/lib/private/legacy/OC_App.php","line":695,"function":"searchValues","class":"OC\\AppConfig","type":"->","args":["installed_version"]},{"file":"/var/www/html/lib/private/TemplateLayout.php","line":198,"function":"getAppVersions","class":"OC_App","type":"::","args":[]},{"file":"/var/www/html/lib/private/legacy/OC_Template.php","line":119,"function":"__construct","class":"OC\\TemplateLayout","type":"->","args":["error",""]},{"file":"/var/www/html/lib/private/Template/Base.php","line":113,"function":"fetchPage","class":"OC_Template","type":"->","args":[]},{"file":"/var/www/html/lib/private/legacy/OC_Template.php","line":296,"function":"printPage","class":"OC\\Template\\Base","type":"->","args":[]},{"file":"/var/www/html/index.php","line":89,"function":"printExceptionErrorPage","class":"OC_Template","type":"::","args":[{"__class__":"Doctrine\\DBAL\\Exception"},500]}],"File":"/var/www/html/lib/private/DB/Connection.php","Line":233,"CustomMessage":"Exception thrown: Doctrine\\DBAL\\Exception"},"id":"67897804723c0"}

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

<?php
$CONFIG = array (
  '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,
    ),
  ),
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => 'redis',
    'password' => '',
    'port' => 6379,
  ),
  'instanceid' => 'id',
  'passwordsalt' => 'salt',
  'secret' => 'secret',
  'trusted_domains' =>
  array (
    0 => 'nextcloud.domain.de',
  ),
  'trusted_proxies' =>
  array (
    0 => '172.30.0.2',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '30.0.4.1',
  'overwrite.cli.url' => 'https://nextcloud.domain.de',
  'dbname' => 'nextcloud',
  'dbhost' => 'database',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'pw',
  'installed' => true,
  'overwriteprotocol' => 'https',
  'default_phone_region' => 'DE',
  'app_install_overwrite' =>
  array (
    0 => 'ldapcontacts',
  ),
  'loglevel' => 2,
  'maintenance' => false,
  'theme' => '',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_smtpport' => '587',
  'mail_smtphost' => 'smtp-mail.outlook.com',
  'mail_smtpauth' => 1,
  'mail_from_address' => 'mail',
  'mail_domain' => 'live.de',
  'mail_smtpname' => 'mail@live.de',
  'mail_smtppassword' => 'pw',
  'trashbin_retention_obligation' => 'auto',
  'maintenance_window_start' => 1,
);

Apps

The output of occ app:list (if possible).

Enabled:
  - activity: 3.0.0
  - app_api: 4.0.3
  - calendar: 5.0.8
  - circles: 30.0.0
  - cloud_federation_api: 1.13.0
  - comments: 1.20.1
  - contacts: 6.1.3
  - contactsinteraction: 1.11.0
  - dashboard: 7.10.0
  - dav: 1.31.1
  - deck: 1.14.2
  - federatedfilesharing: 1.20.0
  - federation: 1.20.0
  - files: 2.2.0
  - files_downloadlimit: 3.0.0
  - files_pdfviewer: 3.0.0
  - files_reminders: 1.3.0
  - files_sharing: 1.22.0
  - files_trashbin: 1.20.1
  - files_versions: 1.23.0
  - firstrunwizard: 3.0.0
  - integration_openai: 3.3.0
  - logreader: 3.0.0
  - lookup_server_connector: 1.18.0
  - nextcloud_announcements: 2.0.0
  - notes: 4.11.0
  - notifications: 3.0.0
  - oauth2: 1.18.1
  - password_policy: 2.0.0
  - photos: 3.0.2
  - privacy: 2.0.0
  - provisioning_api: 1.20.0
  - recommendations: 3.0.0
  - related_resources: 1.5.0
  - richdocuments: 8.5.3
  - serverinfo: 2.0.0
  - settings: 1.13.0
  - sharebymail: 1.20.0
  - support: 2.0.0
  - survey_client: 2.0.0
  - systemtags: 1.20.0
  - text: 4.1.0
  - theming: 2.5.0
  - twofactor_backupcodes: 1.19.0
  - updatenotification: 1.20.0
  - user_status: 1.10.0
  - viewer: 3.0.0
  - weather_status: 1.10.0
  - webhook_listeners: 1.1.0-dev
  - whiteboard: 1.0.4
  - workflowengine: 2.12.0
Disabled:
  - admin_audit: 1.20.0
  - bruteforcesettings: 3.0.0 (installed 2.3.0)
  - encryption: 2.18.0
  - files_external: 1.22.0
  - suspicious_login: 8.0.0
  - twofactor_nextcloud_notification: 4.0.0
  - twofactor_totp: 12.0.0-dev
  - user_ldap: 1.21.0

If something is missing, I will provide the information later.

"Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2002] Connection refused"

Is the single log entry you posted the one that specifically appears when you run the setup checks or was it just a notable entry you saw?

I ask because the above error would usually be a far more fatal one, and the setup checks run through /settings/ajax/checksetup.

Please check your browser inspector under the Network tab while loading the setup checks page to see specifically which HTTP transaction is failing.

I would expect it to be the GET /settings/ajax/checksetup one. And also check the HTTP code. It could be a timeout at the proxy level, for example. Might be helpful to check your web server (error log) and reverse proxy logs.

Do you have a large nextcloud.log or anything like that? How long do your setup checks normally take to run if you had to guess?

P.S. When checking your Nextcloud config, use occ config:list system rather than the config/config.php file. This is important, particularly when using images, since they take advantage of Nextcloud’s support for multiple/merged config files to bring in the environment variables injected via Docker Compose.

Okay. I will provide some information now and some later (because I’m not on the computer where I have access to everything, but to the most information:

The GET request fails with an 504 Gateway Time-out which contains an nginx version number.
Nextclouds nginx contains following log:

web-1  | 2025/01/19 12:36:11 [error] 29#29: *687 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.18.0.2, server: , request: "GET /settings/ajax/checksetup HTTP/1.1", upstream: "fastcgi://172.22.0.5:9000", host: "nextcloud.mydomain.de

Here is the output of the occ command:

homemedia:~/servers/nextcloud$ docker-compose exec --user www-data app php occ config:list system
{
    "system": {
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "nextcloud.mydomain.de"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "30.0.5.1",
        "overwrite.cli.url": "https:\/\/nextcloud.mydomain.de",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "overwriteprotocol": "https",
        "default_phone_region": "DE",
        "app_install_overwrite": [
            "ldapcontacts"
        ],
        "loglevel": 2,
        "maintenance": false,
        "theme": "",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_smtpport": "587",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "trashbin_retention_obligation": "auto",
        "maintenance_window_start": 1
    }
}

Is maybe already enough information to find the problems cause?

You can use run the setup checks from the command-line with debug logging on for just the occ setupchecks command itself. It’ll log each individual check so you can see how long they took based on the timestamps. This will give you a clue as to which check is taking so long:

NC_loglevel=0 ./occ setupchecks

The length of time the setup checks take is going to be impacted:

  • your log size (i.e. configure log rotation at a smaller increment like 10 MiB instead of 100 MiB)
  • your environment’s resources (disk/CPU/network)
  • the combination of apps you have installed (each apps provide setup checks in addition to the core ones provided in Server directly)

How long do the does occ setupchecks take?

The GET request fails with an 504 Gateway Time-out which contains an nginx version number.

This timeout would need to be adjusted in your Nginx server. It’s probably fastcgi_read_timeout (same as what’s suggested here in the Admin Manual since it impacts uploading larger - both chunked and non-chunked - files too).

Thank you.
The command needs 2:54 seconds.

Here is the output. Maybe the failing checks needs to much time ?:

user@homemedia:~/servers/nextcloud$ docker-compose exec --user www-data -e NC_loglevel=0 app php occ setupchecks
	dav:
		✓ DAV system address book: No outstanding DAV system address book sync.
	network:
		✓ WebDAV endpoint: Your web server is properly set up to allow file synchronization over WebDAV.
		⚠ Data directory protected: Could not check that the data directory is protected. Please check manually that your server does not allow access to the data directory.
To allow this check to run you have to make sure that your Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its `trusted_domains` or the `overwrite.cli.url`. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
		✓ Internet connectivity
		⚠ JavaScript source map support: Your webserver is not set up to serve `.js.map` files. Without these files, JavaScript Source Maps won't function properly, making it more challenging to troubleshoot and debug any issues that may arise.
		⚠ JavaScript modules support: Unable to run check for JavaScript support. Please remedy or confirm manually if your webserver serves `.mjs` files using the JavaScript MIME type.
To allow this check to run you have to make sure that your Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its `trusted_domains` or the `overwrite.cli.url`. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
		⚠ OCS provider resolving: Could not check if your web server properly resolves the OCM and OCS provider URLs.
To allow this check to run you have to make sure that your Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its `trusted_domains` or the `overwrite.cli.url`. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
		ℹ .well-known URLs: Could not check that your web server serves `.well-known` correctly. Please check manually.
To allow this check to run you have to make sure that your Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its `trusted_domains` or the `overwrite.cli.url`. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
		ℹ Font file loading: Could not check for woff2 loading support. Please check manually if your webserver serves `.woff2` files.
To allow this check to run you have to make sure that your Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its `trusted_domains` or the `overwrite.cli.url`. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
	system:
		⚠ Errors in the log: 29 errors in the logs since January 12, 2025, 3:19:46 PM
		✓ Allowed admin IP ranges: Admin IP filtering isn’t applied.
		ℹ Brute-force Throttle: Your remote address could not be determined.
		✓ Cron errors: The last cron job ran without errors.
		✓ Cron last run: Last background job execution ran 4 minutes ago.
		✓ Debug mode: Debug mode is disabled.
		✓ File locking
		✓ Maintenance window start: Maintenance window to execute heavy background jobs is between 1:00 UTC and 7:00 UTC
		✓ Memcache: Configured
		✓ Mimetype migrations available: None
		✓ Architecture: 64-bit
		✓ Temporary space available: Temporary directory is correctly configured:
- 126.5 GiB available in /tmp (PHP temporary directory)
		✓ Push service: Free push service
	notifications:
		✓ Push notifications - Fair use policy
	security:
		✓ App directories owner: App directories have the correct owner "www-data"
		✓ Old administration imported certificates
		✓ Code integrity: No altered files
		ℹ Forwarded for headers: Your remote address could not be determined.
		✓ HTTPS access and URLs: You are accessing your instance over a secure connection, and your instance is generating secure URLs.
		✓ Old server-side-encryption: Disabled
		✓ PHP version: You are currently running PHP 8.2.27.
		✓ Random generator: Secure
		ℹ HTTP headers: Could not check that your web server serves security headers correctly. Please check manually.
	database:
		✓ Database missing columns: None
		✓ Database missing indices: None
		✓ Database missing primary keys: None
		✓ Database pending bigint migrations: None
		✓ MySQL Unicode support: MySQL is used as database and does support 4-byte characters
		✓ Scheduling objects table size: Scheduling objects table size is within acceptable range.
		✓ Database version: 10.11.10-MariaDB-ubu2204
		✓ Database transaction isolation level: Read committed
	config:
		✓ Default phone region: DE
		✓ Email test: Email test was successfully sent
		✓ Overwrite CLI URL: The "overwrite.cli.url" option in your config.php is set to "https://nextcloud.mydomain.de" which is a correct URL. Suggested URL is "https://localhost".
		✓ Configuration file access rights: Nextcloud configuration file is writable
	php:
		✓ PHP default charset: UTF-8
		✓ PHP set_time_limit: The function is available.
		✓ Freetype: Supported
		✓ PHP getenv
		✓ PHP memory limit: 512 MB
		✓ PHP modules
		✓ PHP opcache: Checking from CLI, OPcache checks have been skipped.
		✓ PHP "output_buffering" option: Disabled
		✓ PHP Imagick module

I will try to adjust the configuration you linked to allow big file sizes.
Currently I’m struggeling with

- If you can access the frontend’s configuration, disable proxy_buffering or increase proxy_max_temp_file_size from the default 1GB.
- If you do not have access to the frontend, set the X-Accel-Buffering header to add_header X-Accel-Buffering no; on your backend server.

What is “fronend” and what is “backend” here? Both looks like nginx configurations which I currently would apply to the docker web containers nginx.conf.

Further I have no guess where to add the php.ini changes which are mentioned there. There is a link to General troubleshooting — Nextcloud latest Administration Manual latest documentation with the hint to check the section “Loaded Configuration File” but it does not exist there.

Yeah most of those failures appear to be because your instance can’t connect to itself.

Try:

curl https://nextcloud.mydomain.de

I assume it’ll fail. So you need to figure that one out since it’s related to your network topology.

What is “fronend” and what is “backend” here? Both looks like nginx configurations which I currently would apply to the docker web containers nginx.conf.

Frontend would be your reverse proxy.
Backend would be your web server.

This part is very bad documented or I am very bad in finding information about it.
After some checking the nextcloud:fpm images file system, I found that there is a nextcloud.ini file in /usr/local/etc/php/conf.d which sets :

memory_limit=${PHP_MEMORY_LIMIT}
upload_max_filesize=${PHP_UPLOAD_LIMIT}
post_max_size=${PHP_UPLOAD_LIMIT}

So I can set in my docker compose file the environment variable to 64G. I hope this is correct :wink:

You mean from inside of the instance? I will check it.
Should I test it inside the nginx web container or inside the nextcloud:fpm container? The host system returns no error on the curl command.

PHP configuration path will vary depending what OS/distribution/packager/image you’re using. The image you’re using has its own documentation.

with the hint to check the section “Loaded Configuration File” but it does not exist there.

Fair, the relevant fields in some environments will be any of the couple surrounding ones that list all your config file folders/paths.

e.g. this is what appears for me from the nextcloud image under phpinfo:

Configuration File (php.ini) Path 	/usr/local/etc/php
Loaded Configuration File 	(none)
Scan this dir for additional .ini files 	/usr/local/etc/php/conf.d
Additional .ini files parsed 	/usr/local/etc/php/conf.d/docker-php-ext-apcu.ini, /usr/local/etc/php/conf.d/docker-php-ext-bcmath.ini, /usr/local/etc/php/conf.d/docker-php-ext-exif.ini, /usr/local/etc/php/conf.d/docker-php-ext-ftp.ini, /usr/local/etc/php/conf.d/docker-php-ext-gd.ini, /usr/local/etc/php/conf.d/docker-php-ext-gmp.ini, /usr/local/etc/php/conf.d/docker-php-ext-imagick.ini, /usr/local/etc/php/conf.d/docker-php-ext-intl.ini, /usr/local/etc/php/conf.d/docker-php-ext-ldap.ini, /usr/local/etc/php/conf.d/docker-php-ext-memcached.ini, /usr/local/etc/php/conf.d/docker-php-ext-opcache.ini, /usr/local/etc/php/conf.d/docker-php-ext-pcntl.ini, /usr/local/etc/php/conf.d/docker-php-ext-pdo_mysql.ini, /usr/local/etc/php/conf.d/docker-php-ext-pdo_pgsql.ini, /usr/local/etc/php/conf.d/docker-php-ext-redis.ini, /usr/local/etc/php/conf.d/docker-php-ext-sodium.ini, /usr/local/etc/php/conf.d/docker-php-ext-sysvsem.ini, /usr/local/etc/php/conf.d/docker-php-ext-zip.ini, /usr/local/etc/php/conf.d/nextcloud.ini, /usr/local/etc/php/conf.d/opcache-recommended.ini, /usr/local/etc/php/conf.d/redis-session.ini 

Hm, I will inspect my docker networks.
Currently I observe that a “curl nextcloud.mydomain.de” sometimes works and sometimes not:

/ # curl https://nextcloud.mydomain.de
/ # curl https://nextcloud.mydomain.de
curl: (6) Could not resolve host: nextcloud.mydomain.de
/ # curl https://nextcloud.mydomain.de
curl: (6) Could not resolve host: nextcloud.mydomain.de
/ # curl https://nextcloud.mydomain.de
curl: (6) Could not resolve host: nextcloud.mydomain.de
/ # curl https://nextcloud.mydomain.de
curl: (6) Could not resolve host: nextcloud.mydomain.de
/ # curl https://nextcloud.mydomain.de
/ #

But a nslookup always works:

/ # nslookup https://nextcloud.mydomain.de
Server:		127.0.0.11
Address:	127.0.0.11:53

Non-authoritative answer:
https://nextcloud.mydomain.de	canonical name = mydomain.no-ip.org

Non-authoritative answer:
https://nextcloud.mydomain.de	canonical name = mydomain.no-ip.org
Name:	mydomain.no-ip.org
Address: <public ip>

/ # nslookup https://nextcloud.mydomain.de
Server:		127.0.0.11
Address:	127.0.0.11:53

Non-authoritative answer:
https://nextcloud.mydomain.de	canonical name = mydomain.no-ip.org

Non-authoritative answer:
https://nextcloud.mydomain.de	canonical name = mydomain.no-ip.org
Name:	mydomain.no-ip.org
Address: <public ip>

/ # nslookup https://nextcloud.mydomain.de
Server:		127.0.0.11
Address:	127.0.0.11:53

Non-authoritative answer:
https://nextcloud.mydomain.de	canonical name = mydomain.no-ip.org

Non-authoritative answer:
https://nextcloud.mydomain.de	canonical name = mydomain.no-ip.org
Name:	mydomain.no-ip.org
Address: <public ip>

Its strange. Hopefully this is related to the nextcloud problem and I will find the cause.

€dit:
After conducting further tests, I noticed that this issue consistently occurs with Alpine-based images. Even when using a well-known domain like google.de, the problem is reproducible.

When I switched from the nginx:alpine image to nginx:latest (which is based on Debian Bullseye), the curl commands became stable, and the issue disappeared.

Unfortunately, I’ve encountered the same problem with the nextcloud:fpm-alpine image, so it seems to be a broader issue affecting Alpine-based images.

I’ll try to update my host system to debian 12.

Alpine (well, musl libc really) has traditionally been more sensitive about DNS resolver problems. In some cases there are/were differences in behavior or support.

See musl libc - Functional differences from glibc

Okay, even after my upgrade to Debian 12 I had the same problem.
After changing the alpine based images to the default ones (I think they are debian based), everything worked fine.

Maybe somebody should replace the exampes here https://github.com/nextcloud/docker/tree/master/.examples/docker-compose

Or at least there should be a hint, that the alpine image could cause problems.

If there are problems, it’s either a subtle bug in your DNS infrastructure (brought out by the different DNS resolution path in Alpine versus Debian - which is considerable) or an upstream bug (or a bit of both).

Without more details it’s hard to say. (For what it’s worth, I’m unable to reproduce this behavior in my test environment).

You might try reproducing the problem using the alpine:3.20 Docker image itself (that is the Alpine base the NC v30.0.4 Alpine image uses).

https://hub.docker.com/_/alpine

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.