Dreaded 'Download failed' error with Nextcloud 27 filelocking/memcache enabled

🍱 Features & apps onlyoffice
1

I updated my Onlyoffice to 7.4, and the nextcloud instance to 27.0.1. I noticed some intermittent “Download failed” error dialog on random files every now and then. So I disabled file locking using the redis server by removing the lines below as a workaround:

These values:

  'filelocking.enabled' => 'true',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => '6379',
    'timeout' => '0.0',
    'password' => 'xxxxxxxx',

When I disable file locking and memcache, the files open fine with no errors.
Is there anything special we need to configure connecting to onlyoffice with filelocking enabled? The Security and setup warnings suggested it be enabled, but it seems to trigger intermittent file access issues. I have yet to comb the logs, I will reproduce the problem and capture some logs, but thought I should ask. Not sure if I ran into a bug, or if I need to set something in the local.json file. The redis server is running in the nextcloud instance, while docs server runs in a separate (lxd) container on Ubuntu 20.04.
Thank you

2

Not that I’m aware of.

I’m curious what the logs end up showing, both in NC and OO.

OO ones typically in /var/log/onlyoffice/documentserver/docservice/ or similar.

filelocking.debug might also be informative if you’re careful about it:

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#filelocking-debug

1 Like
3

Update:

It turned out to be a few issues, I had missed some opcache settings in the php8.1-fpn/php.ini, and the Redis server was set to a port (6379) while NC was set to the socket. So once I set it to use port 0, and pointed it to the correct socket name redis.sock vs redis-server.sock I had success. What happens when you get distracted by six other projects lol

Here is where my system config stuff landed once everything was working:

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.example.com"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "27.0.1.2",
        "overwrite.cli.url": "http:\/\/192.168.50.25",
        "overwriteprotocol": "https",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "maintenance": false,
        "theme": "",
        "default_language": "en",
        "default_locale": "en_US",
        "default_phone_region": "US",
        "loglevel": 2,
        "onlyoffice": {
            "jwt_header": "AuthorizationJwt"
        },
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpsecure": "tls",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "filelocking.enabled": "true",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": "0",
            "dbindex": "0",
            "timeout": "1.5"
        },
        "htaccess.RewriteBase": "\/",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***"
    }
}

The only thing dogging me now is the "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy. If not, this is a security issue and can allow an attacker to spoof their IP address … " joy. Will hit that when I can make time.

4

Oh, yeah that would do it. Glad you got Redis sorted out.

Likely just an incorrect IP address listed in trusted_proxies or a proxy that isn’t sending along the client IP address in X-Forwarded-Hosted for some reason. Best of luck!

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html?highlight=spoof#trusted-proxies

5

Yeah I double checked that proxy IP and it is set correct. The part about “or you are accessing Nextcloud from a trusted proxy.” makes me think it’s normal - since it is behind an Nginx proxy, with forwarding configured:

proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;

I will check my backups - maybe I inadvertently changed on of the lines of the proxy config. The only thing I meant to change was I added the rewrite directive for the CalDAV/CardDAV redirect stuff.

   rewrite ^/\.well-known/carddav https://$server_name/remote.php/dav/ redirect;
                rewrite ^/\.well-known/caldav https://$server_name/remote.php/dav/ redirect;

Thanks for the sanity check Josh! Much appreciated.

6

Forgot to add, for grins I added in the overwritehost directive:

sudo -u www-data php /var/www/html/nextcloud/occ config:system:set overwritehost --value=cloud.example.com

With no love, gonna scratch my head on this a bit more.

7

Well after trying a few different “proxy_set_header” directives in nginx, I was about to give up and just ignore it - then tried something out of the ordinary.

I removed the trusted_proxies directive in config.php and now the alert is gone, and I get the green checkmark once again.

#  'trusted_proxies' => '192.168.x.x',

First time for everything I guess? lol