Error occurred while checking server setup, but there are not

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 26.0.1
Operating system and version (eg, Ubuntu 20.04): docker-fpm @ Raspberry Pi OS 11
Apache or nginx version (eg, Apache 2.4.25): nginx 1.23.4
PHP version (eg, 7.4): 8.1.18

The issue you are facing: On Settings → Overview, I get “Error occurred while checking server setup” but there are no errors - I checked the following:

Is this the first time you’ve seen this error? (Y/N): Y
I start getting this error from the version 26.0.0

Steps to replicate it:

  1. Go to Settings
  2. Go to Administration
  3. Go to Overview

Client side I have the following errors:

GET https://mynas.synology.me/index.php/.well-known/webfinger 404
GET https://mynas.synology.me/index.php/.well-known/nodeinfo 404
GET https://mynas.synology.me/settings/ajax/checksetup 504

The output of your Nextcloud log in Admin > Logging:

No errors

The output of your config.php file in /path/to/nextcloud (make sure you 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,
    ),
  ),
  'overwritehost' => 'mynas.synology.me',
  'overwriteprotocol' => 'https',
  'trusted_proxies' => 
  array (
    0 => 'mynas.synology.me',
    1 => '192.168.2.100',
  ),
  'instanceid' => 'ocxoalcueoiu',
  'passwordsalt' => 'dgdfsadg/toP',
  'secret' => 'B7Asafsadfdsfsadf9ng/h',
  'trusted_domains' => 
  array (
    0 => 'mynas.synology.me',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '26.0.1.1',
  'overwrite.cli.url' => 'https://mynas.synology.me',
  'dbname' => 'nextcloud',
  'dbhost' => '192.168.2.10:3307',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud_usr',
  'dbpassword' => 'JtsadfasdfadsafqwNI',
  'installed' => true,
  'theme' => '',
  'loglevel' => 2,
  'maintenance' => false,
  'mail_smtpmode' => 'smtp',
  'mail_smtphost' => 'smtp.gmail.com',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'mymail',
  'mail_smtpport' => '465',
  'mail_domain' => 'gmail.com',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'mymail@gmail.com',
  'mail_smtppassword' => 'asdfsadfsadf',
  'mail_smtpsecure' => 'ssl',
);

The output of your Apache/nginx/system log in /var/log/____:

no errors

Here my nginx.conf file:
Please note I also tried with same results the standard one provided online.

worker_processes auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    # Prevent nginx HTTP Server Detection
    server_tokens   off;

    keepalive_timeout  65;

    #gzip  on;

    upstream php-handler {
        server app:9000;
    }

    server {
        server_name mynas.synology.me;
        listen 80;

        # HSTS settings
        # WARNING: Only add the preload option once you read about
        # the consequences in https://hstspreload.org/. This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;

        # set max upload size
        client_max_body_size 512M;
        fastcgi_buffers 64 4K;

        # Enable gzip but do not remove ETag headers
        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

        # Pagespeed is not supported by Nextcloud, so if your server is built
        # with the `ngx_pagespeed` module, uncomment this line to disable it.
        #pagespeed off;

        # HTTP response headers borrowed from Nextcloud `.htaccess`
        add_header Referrer-Policy                      "no-referrer"   always;
        add_header X-Content-Type-Options               "nosniff"       always;
        add_header X-Download-Options                   "noopen"        always;
        add_header X-Frame-Options                      "SAMEORIGIN"    always;
        add_header X-Permitted-Cross-Domain-Policies    "none"          always;
        add_header X-Robots-Tag                         "noindex, nofollow"          always;
        add_header X-XSS-Protection                     "1; mode=block" always;

        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;

        # Path to the root of your installation
        root /var/www/html;

        # Specify how to handle directories -- specifying `/index.php$request_uri`
        # here as the fallback means that Nginx always exhibits the desired behaviour
        # when a client requests a path that corresponds to a directory that exists
        # on the server. In particular, if that directory contains an index.php file,
        # that file is correctly served; if it doesn't, then the request is passed to
        # the front-end controller. This consistent behaviour means that we don't need
        # to specify custom rules for certain paths (e.g. images and other assets,
        # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
        # `try_files $uri $uri/ /index.php$request_uri`
        # always provides the desired behaviour.
        index index.php index.html /index.php$request_uri;

        # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
        location = / {
            if ( $http_user_agent ~ ^DavClnt ) {
                return 302 /remote.php/webdav/$is_args$args;
            }
        }

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        #rewrite ^/.well-known/webfinger /public.php?service=webfinger last;

        # 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://$host/remote.php/dav/; }
            location = /.well-known/caldav  { return 301 https://$host/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 https://$host/index.php$request_uri;
        }

        # Rules borrowed from `.htaccess` to hide certain paths from clients
        location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
        location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

        # Ensure this block, which passes PHP files to the PHP process, is above the blocks
        # which handle static assets (as seen below). If this block is not declared first,
        # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
        # to the URI, resulting in a HTTP 500 error response.
        location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

        location ~ \.(?:css|js|svg|gif)$ {
            try_files $uri /index.php$request_uri;
            expires 6M;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets
        }

        location ~ \.woff2?$ {
            try_files $uri /index.php$request_uri;
            expires 7d;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets
        }

        # Rule borrowed from `.htaccess`
        location /remote {
            return 301 /remote.php$request_uri;
        }

        location / {
            try_files $uri $uri/ /index.php$request_uri;
        }
    }
}

Solution

Simply increase the timeout; in my case I had to add the following lines to nginx.conf file:

fastcgi_send_timeout 120s;
fastcgi_read_timeout 120s;

In my specific case, though, I am behind a reverse proxy. In other scenario, you may need to increase also the following (always assuming nginx):

proxy_connect_timeout 120s;
proxy_send_timeout 120s;
proxy_read_timeout 120s;

Dear community

I seem to have a similar issue - The nextcloud administration interface shows the warning “Error occurred while checking server setup” 2 - 3 times without any other warnings.

I have Nextcloud 28.0.1 installed via AIO docker and Traefik Proxy as reverse proxy for handling the SSL certificate.

This is the only discussion about this error message I found, and it has an accepted sollution - but I don’t understand how this could apply in my case.

First, first part fastcgi_.._timeout is applied to nginx - I assume the nextcloud web server?
But Nextcloud AIO uses Apache web server as far as I know - is there a similar setting for Apache?

And the second part is for the reverse proxy - traefik proxy in my case.
If I understand it correctly, there is per default no read & write timeout, and the connection timeout is 180s:
https://doc.traefik.io/traefik/routing/entrypoints/#transport
So this should not be an issue in my setup.

Check your browser Console and Network tab. Many of the checks run from your browser.

Also, check your Nextcloud server logs.

There are many potential causes.

1 Like

That was a good hint - I get a lot of errors in the browser console:

(Almost) all of them: Status 429 Too Many Requests

I also have a lot of errors (~ 200) in the Nextcloud Admin Interface “Logging” Tab:
Level: error
Application: webdav
Message: Exception Unknown error while seeking content

with the following Exception:

{"reqId":"gjFdWu9qgNsr71e4pg00","level":3,"time":"2023-12-29T20:07:59+00:00","remoteAddr":"172.20.0.1","user":"luisa-marie","app":"webdav","method":"POST","url":"/remote.php/dav/bulk","message":"Unknown error while seeking content","userAgent":"Mozilla/5.0 (Windows) mirall/3.4.0stable-Win64 (build 20211129) (Nextcloud, windows-10.0.22621 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"28.0.1.1","exception":{"Exception":"Sabre\\DAV\\Exception","Message":"Unknown error while seeking content","Code":500,"Trace":[{"file":"/var/www/html/apps/dav/lib/BulkUpload/MultipartRequestParser.php","line":133,"function":"isAt","class":"OCA\\DAV\\BulkUpload\\MultipartRequestParser","type":"->","args":["--boundary_.oOo._YJ3BS6xDWMcW9HUh3YKAk+sjbvJmbPnO--\r\n"]},{"file":"/var/www/html/apps/dav/lib/BulkUpload/BulkUploadPlugin.php","line":71,"function":"isAtLastBoundary","class":"OCA\\DAV\\BulkUpload\\MultipartRequestParser","type":"->","args":[]},{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpPost","class":"OCA\\DAV\\BulkUpload\\BulkUploadPlugin","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":472,"function":"emit","class":"Sabre\\DAV\\Server","type":"->","args":["method:POST",[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/lib/Server.php","line":370,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":35,"function":"exec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/remote.php","line":172,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/html/apps/dav/lib/BulkUpload/MultipartRequestParser.php","Line":115,"message":"Unknown error while seeking content","exception":[],"CustomMessage":"Unknown error while seeking content"},"id":"658f38b49eb21"}

Regarding these webdav errors I already found this open github issue and thought it is a “well-known” bug …

I remember that while setting everything up, I at some point I could not log in because I get a message at the log-in page saying that there where too many requests … :grimacing:

Can you share some more details about your environment?

If you’re using AIO things should be fairly reasonably optimized out of the box.

What non-default apps have you installed?

Any other custom things you’ve done that you can think of?

What sort of underlying platform are you running this on in terms of memory/etc?

1 Like

Sure,
I am also a bit confused - beside using traefik proxy as reverse proxy I pretty much followed all the examples.

In AIO I have additionally activated “ClamAV”, “Fulltextsearch” & “Docker Socket Proxy”
and I have disabled “Nextcloud Talk”

Additional Apps:

  • Bookmarks
  • Collectives
  • Recognize
  • Tables
  • TimeManager
  • User Migration

Other custom things:
I run traefik proxy (also in docker) and set it up as reverse proxy for some other services and now for nextcloud too.

Underlying Platform:
Hardware: Intel Xeon E-2314 (4-core), 16 GB of ECC Memory
OS: “Rockstor” (OpenSUSE 15.4) but all docker containers set up “manually” via docker-compose

One more odd thing I have noticed:

When I set up Nextcloud-AIO (2 days ago, other docker containers are up for half a year without troubles) I selected every option expect Talk (ClamAV, Fulltextsearch & Docker Socket).

Then, after copying most data of my old, externally hosted nextcloud instance to my self-hosted one, I noticed that the server was using about 1 GB of swap.

I then turned of “ClamAV” (because it is supposed to use about 1GB of RAM) and afterwards the web page showed almost only plain text …

The thing I did to resolve this was to enable “ClamAV” again … :face_with_peeking_eye:

Okay now we’re getting somewhere. Can you reproduce this issue without “Docker Socket Proxy”? That’s definitely not a supported or typical deployment.

How about without Fulltextsearch or ClamAV?

OS: “Rockstor” (OpenSUSE 15.4) but all docker containers set up “manually” via docker-compose

So you’re not running AIO in a typical deployment. You’re using the manual installation method?

1 Like

Sorry for the confusion - I DO use the typical Nextcloud-AIO deployment.

The OS “Rockstor” has their own docker deployment tool called Rock-ons, and that's what I am not using.

I did'nt actually know exactly what Docker Socket Proxy was doing - it just sounded eventually usefull :see_no_evil:

Jes, at least kind of (“Docker Socket Proxy” disabled in AIO, “ClamAV” & Fulltextsearch" enabled)

I do get far less errors in the console, but I do get the 429 error again.

Update:

Even with all three disabled (in AIO only “Collabora” & “Imaginary” are enabled) I still get the same errors as with “ClamAV” & “Fulltextsearch” enabled)

Update:

I have investigated this a bit further and did a proper reset of my Nextcloud-AIO instance and created a new one - in one case with all standard settings and in the second case with “ClamAV”, “Fulltextsearch” and “Docker Socket Proxy” enabled.
In both cases the Administration web-UI showed did not show setup errors - only errors in the log …

Nextcloud-AIO standard


Nextcloud-AIO with “ClamAV”, “Fulltextsearch” and “Docker Socket Proxy”



I have now installed Nextcloud-AIO with standard settings again and restored the backup (using BorgBackup Solution integrated into AIO) and this time I do get the setup errors in the Administration web-UI again … :grimacing: (and a lot of HTTP 429 - too many requests - errors)


Update:
I just found a very similar issue that is apparently a bug of the new NC Version 28.0.1 that I use:

I will wait patiently how this issue will get solved :innocent:


2024-01-29 (sorry, I am not allowed to make a new post by the forum :roll_eyes:):
I finally figured out the issue of my installation … and it of course is self-inflicted due to my setup :face_with_peeking_eye: :

I had set a rate limit on my reverse proxy of 10 request/s & 10 requests burst.

At the time I configured the reverse proxy I thought about “user”-request, which 10 of them per second would be plenty for my home environment.
Of course loading a web page implies multiple request, and after 10 requests the reverse proxy replied with the Error 429 - too many requests

Rate limiting a public facing connection is good practice, but this time it made me big headaches where my issue is comming from :see_no_evil:

Final note: only raising the “burst” limit is enough, the average rate could be left fairly low. I have now an average rate of 20 request / s and a burst of 200.

Cheers, Simon

1 Like

I faced this issue after migrating my nextcloud installation to another server. All the settings are identical. I finally found that my /etc/resolv.conf got changed by dhcpcd. I understand similar situation can occur with other network manager software. So I changed the nameserver to the usual 8.8.8.8 and the error is gone and nextcloud is getting faster.
If this may help.
Witit