[Support] Linuxserver.io - Nextcloud

[Kilrah]

Could also be a lack of memory. Don't know about this one but the official Nextcloud image allows adding 

-e PHP_MEMORY_LIMIT=XX

 

in Extra parameters to give it more, I believe the default is just 128M. I use 1G.

If that's possible and it doesn't crash anymore with more mem but some previews fail to build you can maybe increase 

preview_max_memory

in config.php

[Mattaton]

Bumping this since it got buried pretty quick...

 

I've had Nextcloud working fine for well over a year, but now my devices say the server is unavailable. Checking the server, NC is stuck in maintenance mode. If I manually turn maintenance mode off, the web ui then says there's an update to the mail app. When I try to update it, it says an error occurred and it goes back into maintenance mode.

 

The "detailed logs" after the failed update says:

Quote

 

Preparing update

Set log level to debug

Turned on maintenance mode

Repair step: Repair MySQL collation

Repair info: All tables already have the correct collation -> nothing to do

Repair step: Repair SQLite autoincrement

Repair step: Copy data from accounts table when migrating from ownCloud

Repair step: Drop account terms table when migrating from ownCloud

Updating database schema

Updated database

An error occurred.

 

 

So I'm stuck with either a mail update screen or a maintenance mode screen. Both result in a server that is unavailable/offline.

 

I just updated to the latest nextcloud version, hoping that would knock out the issue, but no luck.

 

I don't use the mail app, so I'm also fine if that could just be disabled to get around this.

 

I still consider myself an unRAID/docker novice, but I can follow instructions. 😄 

 

Thanks for any help!

[andreidelait]

1 hour ago, Mattaton said:

Bumping this since it got buried pretty quick...

 

I've had Nextcloud working fine for well over a year, but now my devices say the server is unavailable. Checking the server, NC is stuck in maintenance mode. If I manually turn maintenance mode off, the web ui then says there's an update to the mail app. When I try to update it, it says an error occurred and it goes back into maintenance mode.

 

The "detailed logs" after the failed update says:

 

So I'm stuck with either a mail update screen or a maintenance mode screen. Both result in a server that is unavailable/offline.

 

I just updated to the latest nextcloud version, hoping that would knock out the issue, but no luck.

 

I don't use the mail app, so I'm also fine if that could just be disabled to get around this.

 

I still consider myself an unRAID/docker novice, but I can follow instructions. 😄 

 

Thanks for any help!

 

First of all I'm sorry because I hijacked this section of the forum last few days.
You can disable or remove an app from terminal. If you can SSH into your server (if not you can use the terminal from Unraid WebUI) you can run these commands:

docker exec -it nextcloud occ app:disable mail

or 

docker exec -it nextcloud occ app:remove mail

If your container is not called nextcloud then replace it with your container name.

Not sure if you can remove any app or if the app is really called mail (I deleted my nextcloud so I can't try )

If the app name is not exactly mail you can run the next command to see all the apps:

docker exec -it nextcloud occ app:list

 

To learn more about these commands you can visit

https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/occ_command.html

[Mattaton]

18 minutes ago, andreidelait said:

docker exec -it nextcloud occ app:disable mail

Thank you so much! That did it! WOO! 🙂

And my phone just started autp-uploading photos like mad! 😄

[juleztb]

8 hours ago, andreidelait said:

I use User Scripts to run the cron from the host as I said a few posts above.
You can also run the same command from Unraid terminal just to test if it works.

docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php

 

The linuxserver container uses abc user and group so you have to include it in the command.

That's very much what I tried in the crontab on the host, I postet in the code block.

Tried your statement (only difference being the -t parameter) and the result was the same:

php not being found feels like my main problem. Any ideas on that?

 

Thanks in advance!

[andreidelait]

On 10/12/2022 at 1:15 AM, juleztb said:

That's very much what I tried in the crontab on the host, I postet in the code block.

Tried your statement (only difference being the -t parameter) and the result was the same:

php not being found feels like my main problem. Any ideas on that?

 

Thanks in advance!

 

I don't really know what to say. On my server it works just fine.

Linux 5.19.14-Unraid.
root@Tower:~# docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php
root@Tower:~# docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php -vv
PHP 7.4.26 (cli) (built: Nov 18 2021 21:39:13) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.26, Copyright (c), by Zend Technologies
root@Tower:~#

 

 

 

 

On 10/11/2022 at 7:25 PM, Kilrah said:

Could also be a lack of memory. Don't know about this one but the official Nextcloud image allows adding 

-e PHP_MEMORY_LIMIT=XX

 

in Extra parameters to give it more, I believe the default is just 128M. I use 1G.

If that's possible and it doesn't crash anymore with more mem but some previews fail to build you can maybe increase 

preview_max_memory

in config.php

 

Thank you so much for all the hints you gave me. I don't know what's wrong with it. I suspected the previews as well. I generated all of them and run every repair command I found about nextcloud. I just breaks.
I don't think is a hw resource problem either (CPU is at 50 ish % maybe), RAM is the same 50%. I have this NC instance since v16 or 17 and it worked great.
I deleted everything, including docker image. I started fresh with new, nextcloud, new mariadb (not keeping appdata but starting from scratch). At some point it breaks.
Last night it froze in an mp3 folder I had. Just 20 files or so.
I did not track exactly when this started happen. I tought it was after a nextcloud update but it might as well be after the Unraid 6.11 update and it kept doing it on 6.11.1 as well.
At the moment I won't use the WebUI and just let our phones to sync photos because that still works well.

So I guess I'll revisit it every update from now on.

[Kilrah]

8 minutes ago, andreidelait said:

I deleted everything, including docker image. I started fresh with new, nextcloud, new mariadb (not keeping appdata but starting from scratch). At some point it breaks.
Last night it froze in an mp3 folder I had. Just 20 files or so.

Maybe try with the official/ffmpeg containers instead of this one. Don't know if it's because of the LSIO one being older/more used but there seems to be way more problems with it. It's also much slower...

[lazaretto]

any one else getting a "413 Entity too large to PUT" too? (on windows client)

 

I just can't find a way to fix it, it's making the install completely useless since I need to sync files bigger than 100G frequently....

[GGabs]

On 10/11/2022 at 9:15 AM, BVD said:

 

NH3 is just the "app store" of NC 25, which is currently in RC and not quite ready for broad scale deployment. You'll have it as soon as you upgrade.

 

If you're in a rush, switch to the beta branch - dont trust your data to it though, back up and test recovering from that backup prior to upgrading.

Thank you so much for your reply. Also is Nextcloud AIO same as NC 25? or NC AIO is different all together. Sorry for these questions, I am just trying to catch up with all the lingo thats out there regarding NC, as originally I set mine up in 2019. 

 

Also do you know if NC 25 will have native office support? either through collabora office or onlyoffice? after recent updates, my OnlyOffice integration has not been working. I have a separate docker for onlyoffice which was linked to NC it was a hard integration to configure in the first place and few updates back it has stopped working.

 

Thank you for all the help.

[Kilrah]

6 hours ago, GGabs said:

Also is Nextcloud AIO same as NC 25?

AIO is Nextcloud (any version) but with included antivirus, backup engine and a few things listed here: https://github.com/nextcloud/all-in-one

 

6 hours ago, GGabs said:

Also do you know if NC 25 will have native office support?

Collabora has become the "official" since 23, the integration app is now called "Nextcloud Office" and installation proposed during setup. That said while it works fine on a fresh install I can't get it to work on my old one that's a couple of years old.

Edited October 14, 2022 by Kilrah

[AmokK]

So I tried the commands :

docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php
docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php -vv

like @andreidelait advised, and it seems to work fine, no errors, it runs.

I created a script to use it regularly.

In my nextcloud instance, it still reports no cron jobs have been running for 29 days, is it supposed to be aware an external script is running ?

Edited October 14, 2022 by AmokK

[andreidelait]

17 minutes ago, AmokK said:

So I tried the commands :

docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php
docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php -vv

like @andreidelait advised, and it seems to work fine, no errors, it runs.

I created a script to use it regularly.

In my nextcloud instance, it still reports no cron jobs have been running for 29 days, is it supposed to be aware an external script is running ?

 

Somethnig is wrong in that case. The command with -vv returns anything? 

Edited October 14, 2022 by andreidelait

[AmokK]

17 minutes ago, andreidelait said:

 

Somethnig is wrong in that case. The command with -vv returns anything? 

root@Tower:~# docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php
root@Tower:~# docker exec -it nextcloud sudo -u abc php -f /config/www/nextcloud/cron.php -vv
PHP 7.4.26 (cli) (built: Nov 18 2021 21:39:13) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.26, Copyright (c), by Zend Technologies

No error at least !

[andreidelait]

18 minutes ago, AmokK said:

No error at least !

 

It should be fine. you don't have to run both. I gave you the -vv one just to see if PHP works. 
In your script you should run just the first command.
I don't know why nextcloud says it didn't run though.

[AmokK]

2 minutes ago, andreidelait said:

 

It should be fine. you don't have to run both. I gave you the -vv one just to see if PHP works. 
In your script you should run just the first command.
I don't know why nextcloud says it didn't run though.

Thanks, I know, I messed up my code paste, I only use the standard command  

[bigbangus]

Not sure what I changed, but I get this error now when trying to validate ONLYOFFICE on the settings page:

 

 

I just re-copied over the .key and .crt files from swag with no success. The SECRET in NC OO settings is blank and it always has been.

 

Here is my onlyoffice proxy-conf:

## Version 2021/05/18
# Make sure that your dns has a cname set for onlyoffice named "documentserver"
# Make sure that the onlyoffice documentserver container is named "documentserver"

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name onlyoffice.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    #enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    #include /config/nginx/authelia-server.conf;

    location / {
        #enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        #enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app OnlyOfficeDocumentServer;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_max_temp_file_size 2048m;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

 

 

[bigbangus]

20 minutes ago, bigbangus said:

Not sure what I changed, but I get this error now when trying to validate ONLYOFFICE on the settings page:

 

 

 

oh nevermind, I saw in the logs that documentserver has the following message:

JWT is enabled by default. A random secret is generated automatically. Run the command "docker exec 1f8227803387 sudo documentserver-jwt-status.sh" to get information about JWT.

 

So I entered the secret returned by that command to the NC OO settings and it worked!

 

To keep it persistent, you need to add an environment variable to the OODS docker template 'JWT_SECRET' and then set it the same in NC OO settings.

Edited October 14, 2022 by bigbangus

[Snowman]

Ever since I updated to 24.0.6 from 24.0.5.1 I'm getting errors below in my logs and the dahsboard online is messed up. I assume it's have to do with the CSS errors but not sure how to fix it. It's like something got corrupted or something in the update. Any ideas or route to fix this?

 

Error	cssresourceloader	Could not find resource css/css-variables.css to load		2022-10-13T17:56:22-0600
Warning	core	Failed to compile and/or save /config/www/nextcloud/core/css/css-variables.scss		2022-10-13T17:56:22-0600
Error	scss_cacher	SCSSCacher::cache unable to cache: css-variables.scss		2022-10-13T17:56:22-0600
Error	PHP	Error: file_put_contents(/data/appdata_ocbxpymb2asp/css/core/82bd-0564-css-variables.css): failed to open stream: Permission denied at /config/www/nextcloud/lib/private/Files/Storage/Local.php#296		2022-10-13T17:56:22-0600

 

[srepper]

Hey, I got an error if I want to access via domain.

The error is translatet: "The list of external endpoints could not be received: Not Found"

If I log in the domain it doesn't show me the list of files. ( look at the picture )
 

In the local ip adress everyhting works fine.

 

I think it is my nginx/site-confs/default file, what do you say?

 

Components:

Nextcloud version: 24.0.5
Operating system: Unraid 6.11.1
Apache or nginx : nginx/1.20.2
PHP version: 7.4.26

 

config.php:

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'ocrdy75awbjE',
  'passwordsalt' => 'pw',
  'secret' => 'pw',
  'trusted_domains' => 
  array (
    0 => '192.168.1.2:9443',
    1 => 'main.de',
  ),
  'dbtype' => 'mysql',
  'version' => '24.0.5.1',
  'overwrite.cli.url' => 'https://main.de',
  'dbname' => 'user',
  'dbhost' => '192.168.1.2:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'user',
  'dbpassword' => 'pw',
  'installed' => true,
  'auth.webauthn.enabled' => false,
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'mail_smtphost' => 'smtp.domain.de',
  'mail_from_address' => 'info',
  'mail_domain' => 'main.de',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtpport' => '465',
  'mail_smtpname' => '[email protected]',
  'mail_smtppassword' => 'pw',
  'maintenance' => false,

 

 

nginx/site-confs/default:

 

upstream php-handler {
    server 127.0.0.1:9000;
}
server {
    listen 80;
    listen [::]:80;
    server_name _;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name _;
    ssl_certificate /config/keys/cert.crt;
    ssl_certificate_key /config/keys/cert.key;

    # Add headers to serve security related headers
    # Before enabling Strict-Transport-Security headers please read into this
    # topic first.
    #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
    #
    # 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.

    # set max upload size
    client_max_body_size 512M;
    client_body_timeout 300s;
    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/wasm 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;

    # 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                         "none"          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;

    root /config/www/nextcloud/;

    # display real ip in nginx logs when connected through reverse proxy via docker network
    set_real_ip_from 172.0.0.0/8;
    real_ip_header X-Forwarded-For;

    # 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;
    }

    # 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 /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;
    }

    # 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 /etc/nginx/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;

        fastcgi_max_temp_file_size 0;
    }

    location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
        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 ~ \.wasm$ {
            default_type application/wasm;
        }
    }

    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;
    }

}

 

 

 

Domain

 

 

Local

[Arthus Chan]

Hi all,

 

I’m using Unraid 6.11.1 and linuxserver/nextcloud docker container.

 

I have use Unraid with nextcloud start from Yr 2020, everything was fine.

 

But today after I update my Nextcloud, the website down with error: This version of Nextcloud is not compatible with > PHP 7.4. You are currently running 8.0.18.

 

I have no idea how to fix it. Anyone can help?

 

Thank you very much.

Edited October 20, 2022 by Arthus Chan

[blaine07]

6 hours ago, Arthus Chan said:

Hi all,

 

I’m using Unraid 6.11.1 and linuxserver/nextcloud docker container.

 

I have use Unraid with nextcloud start from Yr 2020, everything was fine.

 

But today after I update my Nextcloud, the website down with error: This version of Nextcloud is not compatible with > PHP 7.4. You are currently running 8.0.18.

 

I have no idea how to fix it. Anyone can help?

 

Thank you very much.

What version of Nextcloud are you using? 24.0.6 is latest I think?

[khodot]

7 hours ago, Arthus Chan said:

Hi all,

 

I’m using Unraid 6.11.1 and linuxserver/nextcloud docker container.

 

I have use Unraid with nextcloud start from Yr 2020, everything was fine.

 

But today after I update my Nextcloud, the website down with error: This version of Nextcloud is not compatible with > PHP 7.4. You are currently running 8.0.18.

 

I have no idea how to fix it. Anyone can help?

 

Thank you very much.

I had the same issue. Apparently I'm still using Nextcloud version 20.0.3 (unRAID v6.9.2, Nextcloud docker updated to latest version). Downgraded nextcloud docker to 23.0.4 (tag :23.0.4), run docker exec -it nextcloud updater.phar (as per in the first page) to upgrade Nextcloud until the version that supports PHP 8.x

 

You can also refer here: 

 

[Normand_Nadon]

Hey there, I looked around and could not find an answer to this, so I am asking!

Since I updated my server to Unraid 6.11 (I was on a much older version for some reason) I can't access my Unraid/nextcloud drive through NFS, Nextcloud keeps locking the permission, even if I reset it as root

 

Setup:
Nextcloud docker, updated weekly.
The server has been up for almost 3 years and the shares and folders worked fine.
Drive shared between Nextcloud and users from NFS share:

/mnt/user/nextcloud/

 

When acessing through NFS client, on Linux, the share is locked, then I unlock the permissions via ssh, and they get changed a few seconds later... I remember I did something about squash root a long long time ago, but can't tell if it had something to do with that particular share

Any thoughts?

Edited October 20, 2022 by Normand_Nadon

[Mephistopheles]

On 10/20/2022 at 9:26 AM, Arthus Chan said:

Hi all,

 

I’m using Unraid 6.11.1 and linuxserver/nextcloud docker container.

 

I have use Unraid with nextcloud start from Yr 2020, everything was fine.

 

But today after I update my Nextcloud, the website down with error: This version of Nextcloud is not compatible with > PHP 7.4. You are currently running 8.0.18.

 

I have no idea how to fix it. Anyone can help?

 

Thank you very much.

 

I've got the same error while letting the container auto-update. Do I really have to downgrade manually or is it possible that there will be a fix within the next days, so I just have to wait for the next auto-update? 🤔

[darranwest]

On 6/12/2022 at 1:57 PM, Rayce185 said:

Did anyone find a solution to this? It doesn't seem that anyone has answered/fixed this...

 

I'm using the dockers cloudflare ddns, mariadb, swag, and obviously nextcloud.

 

/etc/php/php.ini setting "memory_limit = 2G" didn't help

/appdata/nextcloud/www/nextcloud/.htaccess setting this didn't help either:

# PHP 7.x
<IfModule mod_php7.c>
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  php_value memory_limit 2G
  php_value upload_max_filesize 16G
  php_value post_max_size 16G
  php_value max_input_time 3600
  php_value max_execution_time 3600
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>

# PHP 8+
<IfModule mod_php.c>
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  php_value memory_limit 2G
  php_value upload_max_filesize 16G
  php_value post_max_size 16G
  php_value max_input_time 3600
  php_value max_execution_time 3600
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>

 

This didn't help either:

/appdata/swag/nginx/proxy-confs/nextcloud.subdomain.conf "proxy_max_temp_file_size 2048m;"

 

I'm going out of ideas to fix this and can't find any other place to  check. Is there something in Cloudflare that I must set up differently?

 

I think I have been having the same issue as you with large files not uploading. In my Nextcloud appdata folder I have a file called php-local.ini located in this directory, /mnt/user/appdata/nextcloud/php.

 

I edited the php-local.ini file and added the following lines.

 

memory_limit = 8G
upload_max_filesize = 16G

 

This would allow the large file I wanted to add to start the upload process, however, it failed with a 413 error. This was due to a web server error. This got me looking through the appdata folder again and I eventually ended up in the Nextcloud nginx, specifically in this folder /mnt/user/appdata/nextcloud/nginx/site-confs. Looking in the file called default.conf I had to edit one line to look like this

 

client_max_body_size 10240M;

 

This increased the max file size the web server would accept to 10GB (10240MB).

 

After another restart of the Nextcloud docker the file started to upload again, but this time there was a timeout error. I went back into  /mnt/user/appdata/nextcloud/php so that I could edit php-local.ini again. I increased the input time to 600s (10 minutes) and the execution time to 3600s (1 hour). The contents of this file now looked as follows

 

date.timezone = Europe/London # this is my timezone, I am not sure if I added this are it was done on during docker creation

memory_limit = 8G

post_max_size = 16G

upload_max_filesize = 16G

max_execution_time = 3600

max_input_time = 600

 

After another restart of the Nextcloud docker the 4GB file I wanted to add to Nextcloud synced without issue.

 

In summary my changes were as follows

 

1) Edit this file, /mnt/user/appdata/nextcloud/php/php-local.ini

2) Edit what was there and add additional lines so that it looked like this

 

date.timezone = Europe/London

memory_limit = 8G

post_max_size = 16G

upload_max_filesize = 16G

max_execution_time = 3600

max_input_time = 600

 

3) Edit this file /mnt/user/appdata/nextcloud/nginx/site-confs/default.conf

4) Find client_max_body_size and edit the value as below

 

client_max_body_size 10240M;

 

Locally on my network I use Network Proxy Manager to handle SSL certificates. In the advanced section for my Nextcloud SSL I added the following lines

 

client_max_body_size 10240m;
proxy_max_temp_file_size 10240m;

 

I am not sure if they were needed but at some point during my testing I added them. This was before I had changed the client_max_body_size in default.conf, so I am not sure if they made any difference. I just thought it best to include this information as it could be another point of failure for the upload.

 

I hope this helps you fix the issue you are having.