cURL timeout error fetching Collabora capabilities

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face: is for home/non-enterprise users. If you’re running a business, paid support can be accessed via 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:


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


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):
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04.6 LTS
Apache or nginx version (eg, Apache 2.4.25): 2.4 (not sure)
PHP version (eg, 7.4): 8.2.9

The issue you are facing:
I’m not able to access the webinterface, which times out. Loading files from the Windows client or IOS app works.

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

Steps to replicate it:
Not sure, but it started happening when I got a new router. Although it worked for the first 24 hours

The output of your Nextcloud log in Admin > Logging:

Can’t access it since the webinterface doesn’t work. But here’s a pastebin of /data/nextcloud/nextcloud.log. I had to shorten it down because pastebin wouldn’t allow me to post the full log, but I think this is the most relevant part: nextcloud.log -

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

$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'default_phone_region' => 'CH',
  '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' => '',
  'passwordsalt' => '',
  'secret' => '',
  'trusted_domains' =>
  array (
    0 => '',
    1 => '',
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => '',
  'dbname' => 'nextcloud',
  'dbhost' => 'db',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => '',
  'installed' => true,
  'loglevel' => 2,
  'maintenance' => false,
  'overwriteprotocol' => 'https',
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'tls',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'noreply',
  'mail_domain' => '',
  'mail_smtpauth' => 1,
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtphost' => '',
  'mail_smtpport' => '',
  'mail_smtpname' => '',
  'mail_smtppassword' => '',

The output of your Apache/nginx/system log in /var/log/____:
Can’t access any of those file in the docker container. It says apache2/error.log is a device file

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

I think this is the same as I posted above: nextcloud.log -

Here’s my docker-compose file

version: '3'

    image: mariadb:10.5
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
      - db:/var/lib/mysql
      - db.env

    image: redis:alpine
    restart: always

    image: nextcloud:27-apache
    restart: always
      - 80:80
      - nextcloud:/var/www/html
      - ./config:/var/www/html/config
      - /data/nextcloud:/var/www/html/data
#      - VIRTUAL_HOST=
      - MYSQL_HOST=db
      - REDIS_HOST=redis
      - db.env
      - db
      - redis
#      - proxy-tier
      - default

    image: nextcloud:27-apache
    restart: always
      - nextcloud:/var/www/html
      - ./config:/var/www/html/config
      - /data/nextcloud:/var/www/html/data
    entrypoint: /
      - db
      - redis

#  proxy:
#    build: ./proxy
#    restart: always
#    ports:
#      - 80:80
#      - 443:443
#    labels:
#      com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: "true"
#    volumes:
#      - certs:/etc/nginx/certs:ro
#      - vhost.d:/etc/nginx/vhost.d
#      - html:/usr/share/nginx/html
#      - /var/run/docker.sock:/tmp/docker.sock:ro
#    networks:
#      - proxy-tier
#  letsencrypt-companion:
#    image: nginxproxy/acme-companion
#    restart: always
#    volumes:
#      - certs:/etc/nginx/certs
#      - acme:/etc/
#      - vhost.d:/etc/nginx/vhost.d
#      - html:/usr/share/nginx/html
#      - /var/run/docker.sock:/var/run/docker.sock:ro
#    networks:
#      - proxy-tier
#    depends_on:
#      - proxy

#  certs:
#  acme:
#  vhost.d:
#  html:

#  proxy-tier:

I have Nextcloud running behing haproxy, which also manages the SSL certificates. That’s why it’s all commented out in the docker-compose file. As said this setup worked fine until I switched routers. But after the switch the web-ui still worked for about 24 hours. I don’t know exactly when it stopped working. I already tried disabling the firewall of the router and the port-forwarding rules are setup for ports 80 and 443 (TCP/UDP also tried only TCP).

If you need more information about my setup or system feel free to ask.

Thanks for your help in advance!

If you can’t access the NC web interface at all, can you provide the log entry that gets generated when you try to visit the login page?

EDIT: Oh wait I see you’re getting a timeout so likely no log entry. Okay. So can elaborate a bit on your physical network path from your test workstation → Nextcloud? Are you on the same local network and then trying to connect via the external haproxy URL or are you connecting via an internal URL that doesn’t go outside? And have you tried in the other way to confirm the same behavior?

1 Like

I have Nextcloud running in a docker container using docker-compose. Said docker container is located in a VM inside Proxmox OS. Haproxy is running on another VM on the same node. They both communicate over a virtual network in Proxmox. That works and all my other services can use that network.

I tried connecting from the external URL ( and from the local IP of the VM that runs Nextcloud. My domain points at the IP address of my router and I’ve checked that it’s correct. On the router I port forward 80 and 443 towards Haproxy. If the connection doesn’t use SSL, Haproxy redirects it to https. Then if the domain is Haproxy forwards the traffic to the Nextcloud VM.

When I try accessing Nextcloud from the public domain Haproxy renders a 504 error. Meaning the server took too long to respond.
When I try accessing Nextcloud from the local IP of the VM it takes approximately 60 seconds before saying that I can’t access Nextcloud from that domain since it’s not in the trusted domains list. Even after it rendered the error Chrome still shows the spinning icon on the Website for 3-5 Minutes.

So I added the local IP to the trusted domains and disabled the automatic https overwrite. I loaded for a long time again but then showed the login page. I logged into the admin account and then every navigation happened quite quickly with some exceptions, apparently without rime or reason.
In the overview section, where it shows problems, there was nothing besides a critical error about me using http and some warnings about missing indices.
The logs were just cluttered with cURL error 28, which is the timeout error I already saw. I still downloaded the full logs and uploaded them here: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

Both VM (Haproxy and Nextcloud) have a working internet connection. Meaning I am able to ping successfully.

Thanks for your reply

I would recommend you to check the logs of the components in the physical path as @jtr recommended already. In my eyes the HAproxy is a good starting point. if you look into access logs you will see which request comes in and where this request is forwarded to… in case of redirection like it happens for http->https it worth to take a look at browser dev tools (F12). Please take into account you can’t just throw your NC behind a reverse proxy - additional config is required to make NC understand it runs behind reverse proxy - you must make the system aware of the reverse proxy and depending on the config provide overwrite* settings as well.