[Support] Linuxserver.io - Nextcloud

[Selmak]

On 12/8/2022 at 8:06 AM, DrBobke said:

KING!!!!  

Also in Nextcloud all checks are fine, thanks a lot for providing the definitive answer, it really helped me!

 

Glad I could help.

[tazire]

Currently trying to upgrade from 25.0.1 to 25.0.2 via CLI and got the following error

 

docker exec -it nextcloud occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Cannot write into "config" directory.
This can usually be fixed by giving the web server write access to the config directory. See https://docs.nextcloud.com/server/25/go.php?to=admin-dir_permissions. Or, if you prefer to keep config.php file read only, set the option "config_is_read_only" to true in it. See https://docs.nextcloud.com/server/25/go.php?to=admin-config

Cannot write into "apps" directory.
This can usually be fixed by giving the web server write access to the apps directory or disabling the App Store in the config file.

An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /config/www/nextcloud/lib/private/Console/Application.php:166
Stack trace:
#0 /config/www/nextcloud/console.php(99): OC\Console\Application->loadCommands()
#1 /config/www/nextcloud/occ(11): require_once('...')

 

I'm guessing I need to change permissions on the config and apps files as stated? or should I set it to read only? 

[itskamel]

13 hours ago, tazire said:

Currently trying to upgrade from 25.0.1 to 25.0.2 via CLI and got the following error

 

docker exec -it nextcloud occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Cannot write into "config" directory.
This can usually be fixed by giving the web server write access to the config directory. See https://docs.nextcloud.com/server/25/go.php?to=admin-dir_permissions. Or, if you prefer to keep config.php file read only, set the option "config_is_read_only" to true in it. See https://docs.nextcloud.com/server/25/go.php?to=admin-config

Cannot write into "apps" directory.
This can usually be fixed by giving the web server write access to the apps directory or disabling the App Store in the config file.

An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /config/www/nextcloud/lib/private/Console/Application.php:166
Stack trace:
#0 /config/www/nextcloud/console.php(99): OC\Console\Application->loadCommands()
#1 /config/www/nextcloud/occ(11): require_once('...')

 

I'm guessing I need to change permissions on the config and apps files as stated? or should I set it to read only? 

having the same issue, now i just have a error page on nextcloud.

[blaine07]

10 minutes ago, itskamel said:

having the same issue, now i just have a error page on nextcloud.

In Unraid file manager who does it show has ownership of Nextcloud app data? What is its read write rules?

 

 

[tazire]

7 hours ago, blaine07 said:

In Unraid file manager who does it show has ownership of Nextcloud app data? What is its read write rules?

 

 

Mine show exactly the same as you posted here.

 

R/W on all permissions. And the owner option doesnt actually show who the owner is but its the same as yours and gives nobody as the default option? should I try make it the new owner?

 

EDIT

Just to add to this... I am also unable to come out of maintenance mode. It spits out the same errors when i try to turn it off. So at present my nextcloud is unusable. 

 

EDIT2

Ok I just ran both the change the permissions and change owner options you mentioned to have everything r/w and the owner be nobody... not sure if this is the best idea from a security perspective but it worked for me to at least get the update done and be able to use nextcloud again. I now just get the error..

Last background job execution ran 21 hours ago. Something seems wrong.

Edited December 10, 2022 by tazire

[blaine07]

Nextcloud 25.0.2 corresponding container was released by Linuxserver.io sometime yesterday. You both, above, have newest version of container?

 

I wanted to go 25.0.2 but I guess so far good thing I held out...

[Martintheshred]

Hi Guys I tried to do an update to the latest update using the Gui updater and it is stuck on update in progress when I oped the logs it says "Could not open input file: /config/www/nextcloud/cron.php" 

 

do you have any suggestions 

 

I have also tried this command in terminal "docker exec -it nextcloud updater.phar"

 

and get "Step 6 is currently in process please try later"

I am running the latest Unraid version 6.11.5 on a Dell Poweredge T320 Server and have had no problems in the past updating Nextcloud using the GUI  

Edited December 10, 2022 by Martintheshred
more info

[Tolete]

On 12/8/2022 at 6:16 PM, blaine07 said:

Anyone gone 25.0.2 successfully yet?

 yes, no issues updating here.

Edited December 10, 2022 by Tolete

[blaine07]

1 hour ago, Tolete said:

 yes, no issues updating here.

CLI or update.phar thing?

 

Anyrhing noteworthy on 25.0.2 for you?(yes I read change log but…)

[m26872]

Updated from 25.0.1 to 25.0.2 with update.phar from console without issues. I have had issues since a couple of versions back, with GUI update timing out at different steps. Probably due growing size of the installation.

[avinyc]

14 hours ago, m26872 said:

Updated from 25.0.1 to 25.0.2 with update.phar from console without issues. I have had issues since a couple of versions back, with GUI update timing out at different steps. Probably due growing size of the installation.

Yea I always update through terminal (really think it should be the first recommended option instead of second).  Ran into problems with webui in the early days (timeouts and such).  Never an issue updating in terminal, just did 25.0.1 to 25.0.2 and all checks passed this round.

[blaine07]

On 12/10/2022 at 5:03 AM, tazire said:

Mine show exactly the same as you posted here.

 

R/W on all permissions. And the owner option doesnt actually show who the owner is but its the same as yours and gives nobody as the default option? should I try make it the new owner?

 

EDIT

Just to add to this... I am also unable to come out of maintenance mode. It spits out the same errors when i try to turn it off. So at present my nextcloud is unusable. 

 

EDIT2

Ok I just ran both the change the permissions and change owner options you mentioned to have everything r/w and the owner be nobody... not sure if this is the best idea from a security perspective but it worked for me to at least get the update done and be able to use nextcloud again. I now just get the error..

Last background job execution ran 21 hours ago. Something seems wrong.

I had to change Owner of folder to "nobody" as well to get it to install. Issue now is the same--

 

Not sure what to do now... sigh:

 

EDIT: anyways, I did have to change permissions on the nextcloud* appdata folder..and once I restarted container again it seems the cron thing sorted itself out..It's updating in similar time frames and other NC instance I have and not red anymore?

 

Edit 2: more I think about it the more I think that folder shouldn’t be having ownership problems. Not sure at what point ownership should get changed to “nobody” but it appears that failing to happen, for whatever reason, was what the issue was. When at installation is it supposed to handle that itself? Change ownership of install folder. Is that a Nextcloud or Unraid issue?

Edited December 12, 2022 by blaine07

[blaine07]

Updated my Second instance of Nextcloud; same thing. Had to change "UKNOWN" owner to "nobody". Something isn't going right somewhere; just no idea if a Nextcloud thing or Unraid issue. 😞

 

EDIT: I just hope I am not ruining my life later by now changing the permissions to "nobody" despite that appears to be what they always have been/should be?

 

Edited December 12, 2022 by blaine07

[gzibell]

Running Collabora-CODE saw this.  Is this something I should worry about?  Both services are running via cloudflare and NPM. 

 

"You have not configured the allow-list for WOPI requests. Without this setting users may download restricted files via WOPI requests to the Nextcloud server."

[blaine07]

1 hour ago, gzibell said:

Running Collabora-CODE saw this.  Is this something I should worry about?  Both services are running via cloudflare and NPM. 

 

"You have not configured the allow-list for WOPI requests. Without this setting users may download restricted files via WOPI requests to the Nextcloud server."

It probably won’t work saying that will it?

[gzibell]

13 minutes ago, blaine07 said:

It probably won’t work saying that will it?

Oh it totally works. The learn more says, "It is highly recommended to restrict WOPI requests to the IP addresses of the Collabora servers that are expected to request files from the Nextcloud installation. This can be done by setting the Allow list for WOPI requests option from the Office admin settings."

 

So I think it means someone could use WOPI to grab files from my nextcloud instance without permission and I need to only allow ip's that should be allowed to access wopi.  I tried local IP's and that didn't work.  Assuming it would have to be my public or cloudflare proxied ip but haven't tried those yet

 

[adminmat]

I'm running version Nextcloud 25 with Swag and MariaDB and hoping to get rid of some of my warnings. I know this has been asked 1,000 times.... To get rid of:

Your web server is not properly set up to resolve "/.well-known/webfinger". Further information can be found in the documentation ↗.
Your web server is not properly set up to resolve "/.well-known/nodeinfo". Further information can be found in the documentation ↗.

I read you have to delete the default file at: /mnt/user/appdata/nextcloud/nginx/site-confs/  then restart the container per this.
Then you have to replace lines in the default file with what's described here. 

 

Is this still correct? I'm scared I'm going to break something. 

[blaine07]

Can someone tell me what this is about? I don’t understand how I wouldn’t get more Password App updates; I am on NC 25.0.2, latest Unraid with PHP 8. 
 

What does this mean?

 

 

Edited December 16, 2022 by blaine07

[Kilrah]

2 hours ago, blaine07 said:

Can someone tell me what this is about? I don’t understand how I wouldn’t get more Password App updates; I am on NC 25.0.2, latest Unraid with PHP 8. 
 

What does this mean?

I imagine the developer typo'd and meant to say "last update for nextcloud 24".

[Shaun Baker]

Newbie here:

followed spaceinvaders recent tutorial to the letter.

Mariadb runs and no errors in log, same for nextcloud.

My problem is when setting up the admin account and database from the web interface i get an nginx 504 Gateway Time-out.

 

Any help would be appreciated, my command line knowledge is poor so go easy THX

[Shaun Baker]

im a little furter along now using

192.168.1.110:3306 with the following error

 

Error while trying to create admin user: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [1045] Access denied for user 'nextcloud'@'172.17.0.1' (using password: YES)

Create an admin account

[Kilrah]

make sure you created a user "nextcloud" in your DB with the same password you're specifying here.

[DuneJeeper]

I did a series of updates to both nextcloud via the web updater as well as updating the nextcloud docker. I notices on my overview page a series of errors and one in particular suggested I run the command occ db:convert-filecache-bigint

When I ran it inside of the console NC became unreachable. I can't run the web gui or anything. Can anyone help? I run a cloud for my family and if I made their data unreachable it'll be terrible. I was days away from gifting them all hard drives in case my server had a problem. 

Please help!

EDIT: The log shows this nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /config/nginx/site-confs/default.conf:9

EDIT 2 

I came across a forum that a user said they added the lines 

 

ssl_certificate /config/keys/cert.crt;

ssl_certificate_key /config/keys/cert.key;

 

to the nginx/site-confs/default file and everything is fine. I can access it from LAN and WAN.

1: Is this a temporary fix?

2: What happened?

3: There must be a complete default file somewhere with the correct information. Where can I find this? I don't like that I have a self-modified file as it seems like a patch at best. 

EDIT 3 for kicks I deleted the default file and restarted NC and let NC rebuild it and it reverted to being inaccessible so I added the lines back in. 

Edited December 17, 2022 by DuneJeeper

[DuneJeeper]

@saarg Please read my post above as you seem to be a great help to people. Also I will post my default file here. I am getting the errors LAN LOGIN ONLY:

 

The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips ↗.

Your web server is not properly set up to resolve "/.well-known/webfinger". Further information can be found in the documentation ↗.

Your web server is not properly set up to resolve "/.well-known/nodeinfo". Further information can be found in the documentation ↗.

Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the documentation ↗.

Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the documentation ↗.

 

I'm not getting them when I login via WAN. 

Default file as follows THANKS!

 

## Version 2022/08/20 - Changelog: https://github.com/linuxserver/docker-nextcloud/commits/master/root/defaults/nginx/site-confs/default.conf.sample

# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
    "" "";
    default "immutable";
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

    server_name _;

    root /config/www/nextcloud/;
	
	ssl_certificate /config/keys/cert.crt;
	ssl_certificate_key /config/keys/cert.key;

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

    # https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html#nextcloud-in-the-webroot-of-nginx

    # set max upload size and increase upload timeout:
    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;

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

    # The settings allows you to optimize the HTTP2 bandwitdth.
    # See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
    # for tunning hints
    client_body_buffer_size 512k;

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

    # 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 modHeadersAvailable true;         # Avoid sending the security headers twice
        fastcgi_param front_controller_active true;     # Enable pretty urls
        fastcgi_pass 127.0.0.1:9000;

        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;
        add_header Cache-Control "public, max-age=15778463, $asset_immutable";
        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 / {
        # enable for basic auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

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

    # deny access to .htaccess/.htpasswd files
    location ~ /\.ht {
        deny all;
    }
}

 

[Shaun Baker]

On 12/17/2022 at 6:55 PM, Kilrah said:

make sure you created a user "nextcloud" in your DB with the same password you're specifying here.

Ill give it a go thanks.