[Support] Linuxserver.io - Nextcloud


Recommended Posts

On 2/20/2017 at 11:51 PM, Marv said:

Yes it's running behind Ngninx. I did some more research and it seems that there is an overall problem with docker only seeing the IP of the docker0 network.

See here for example:

https://github.com/jwilder/nginx-proxy/issues/133

https://github.com/docker/docker/issues/7540#issuecomment-250407556

This means that I can't really use the Bruteforce feature shipped with Nextcloud because it's only able to see one IP (172.17.0.1).

That's why I disabled it for now in my config.php with


'auth.bruteforce.protection.enabled' => false,

How are you dealing with this? Am I the only one seeing this problem here?

I also wanted to start playing around with Fail2ban but I think this wouldn't work aswell in a docker environment right? How would I make Fail2ban see the Nextcloud log which is obviously located in a different container.

 

 

 

This makes accessing the index page so slow and logging in takes even longer.

 

How is nobody else suffering from this problem? The only way NextCloud runs normally is on my local network. Accessing it from outside effectively causes this problem. Why am I not seeing any other posts about this? How is everyone working about this?

 

I am going to try disabling brutforce in the config.php file.

Link to comment
3 hours ago, smaka510 said:

 

This makes accessing the index page so slow and logging in takes even longer.

 

How is nobody else suffering from this problem? The only way NextCloud runs normally is on my local network. Accessing it from outside effectively causes this problem. Why am I not seeing any other posts about this? How is everyone working about this?

 

I am going to try disabling brutforce in the config.php file.

 

this worked, but now bruteforce detection is off... no biggie... i guess..

Link to comment

I have followed the guide on setting up NextCloud and Letsencrypt from linuxserver.io.

 

Everything is working, except I can only connect to NextCloud via https://nextcloud.mydomain.com. I am unable to access it from:

In every scenario, the server is not found. Is there something wrong in my configs? or could this potentially be an issue with the DNS routing of my subdomain?

 

My default nginx config looks like:

server {
        listen 80;
        server_name *.mydomain.com;
        return 301 https://$host$request_uri;
}

# main server block
server {
        listen 443 ssl default_server;

        root /config/www;
        index index.html index.htm index.php;

        server_name _;

        ssl_certificate /config/keys/letsencrypt/fullchain.pem;
        ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
        ssl_dhparam /config/nginx/dhparams.pem;
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM$
        ssl_prefer_server_ciphers on;

        client_max_body_size 0;

        location / {
                try_files $uri $uri/ /index.html /index.php?$args =404;
        }

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                # With php7-cgi alone:
                fastcgi_pass 127.0.0.1:9000;
                # With php7-fpm:
                #fastcgi_pass unix:/var/run/php7-fpm.sock;
                fastcgi_index index.php;
                include /etc/nginx/fastcgi_params;
        }

My NextCloud nginx config looks like:

server {
    listen 443 ssl;
    server_name nextcloud.mydomain.com;

    root /config/www;
    index index.html index.htm index.php;

    ###SSL Certificates
    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem;

    ###Diffie–Hellman key exchange ###
    ssl_dhparam /config/nginx/dhparams.pem;

    ###SSL Ciphers
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA$

    ###Extra Settings###
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

        ### Add HTTP Strict Transport Security ###
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header Front-End-Https on;

    client_max_body_size 0;

    location / {
        proxy_pass https://my.unraid.server.ip:444/;
        proxy_max_temp_file_size 2048m;
        include /config/nginx/proxy.conf;
    }
}

My NextCloud config.php looks like:

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => '***',
  'passwordsalt' => '***',
  'secret' => '***',
  'trusted_domains' =>
  array (
    0 => 'my.unraid.server.ip:444',
    1 => 'nextcloud.mydomain.com',
  ),
  'overwrite.cli.url' => 'https://nextcloud.mydomain.com',
  'overwritehost' => 'nextcloud.mydomain.com',
  'overwriteprotocol' => 'https',
  'dbtype' => 'mysql',
  'version' => '12.0.4.3',
  'dbname' => 'nextcloud',
  'dbhost' => 'my.unraid.server.ip:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'user',
  'dbpassword' => 'password',
  'installed' => true,
);

 

Link to comment
6 minutes ago, jonathanm said:

Maybe stating the obvious here, but have you checked that all those domains ping back to the correct IP?

 

Hmm,  the only domain that actually responds is: nextcloud.mydomain.com, but it does give me the correct IP.

Edited by areohbe
Link to comment
9 hours ago, areohbe said:

 

Hmm,  the only domain that actually responds is: nextcloud.mydomain.com, but it does give me the correct IP.

That's your issue. If you want a domain name to answer with an IP, the domain name must be registered with a root Domain Name Server.

 

Nothing to do with your nextcloud or nginx config.

Link to comment
22 hours ago, smaka510 said:

 

This makes accessing the index page so slow and logging in takes even longer.

 

How is nobody else suffering from this problem? The only way NextCloud runs normally is on my local network. Accessing it from outside effectively causes this problem. Why am I not seeing any other posts about this? How is everyone working about this?

 

I am going to try disabling brutforce in the config.php file.

 

I solved this issue by adding the following lines to my nextcloud nginx cfg under appdata/nextcloud/nginx/site-confs/default

 

  # Fetch forwarded remote IP address instead of IP address of docker0 bridge interface
  real_ip_header X-Forwarded-For;
  set_real_ip_from 172.17.0.0/16;
  real_ip_recursive on;

 

this way you can leave brutforce enabled if you're not using fail2ban, which works for me aswell now

Link to comment

First, I would like to thank CHBMB for posting his guide, very well written and informative.

 

My only problem seems to be the nextcloud container logs show this error:

nginx: [emerg] open() "/config/nginx/proxy.conf" failed (2: No such file or directory) in /config/nginx/site-confs/nextcloud:31

Sure enough, I go into the appdata folder for nextcloud and the proxy.conf file is not there.  (Instructions didn't say I should put it there....)

 

My appdata config path for nextcloud points to /mnt/user/appdata/nextcloud

 

I'm wondering if it should instead point to /mnt/user/appdata/letsencrypt?

 

When I put a copy of the proxy.conf file from the letsencrypt container into the nextcloud container, I got 

nginx: [emerg] BIO_new_file("/config/keys/letsencrypt/fullchain.pem") failed (SSL: error:02FFF002:system library:func(4095):No such file or directory:fopen('/config/keys/letsencrypt/fullchain.pem', 'r') error:20FFF080:BIO routines:CRYPTO_internal:no such file)

Should I do this?  Or have I missed a step in my letsencrypt configuration?

LetsEncrypt Unraid Config.PNG

NextCloud Unraid Config.PNG

Link to comment
  • 2 weeks later...

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134880 bytes) in /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on lin

 

 

It prevents a certain user from logging in.  Other users are fine.

The user in question has around 85gb files stored.

 

I've read increasing buffer size from 128 to 256 will fix it but no idea where the config file is in the docker.

 

Link to comment

After 6.4 update, unable to reach nextcloud gui. I get redirected to unraids gui. I figured this was because I was using 443 on the host side of the container before the update. So I changed my host port to 8443 and left the container port as 443, since that is where the service is running. This still redirects me to the unraid gui instead of nextcloud. Tried a different browser in case it was cached. 
 

Link to comment
After 6.4 update, unable to reach nextcloud gui. I get redirected to unraids gui. I figured this was because I was using 443 on the host side of the container before the update. So I changed my host port to 8443 and left the container port as 443, since that is where the service is running. This still redirects me to the unraid gui instead of nextcloud. Tried a different browser in case it was cached. 
 
Either reboot unRAID or try typing the address into the browser manually.

Sent from my LG-H815 using Tapatalk

Link to comment
6 minutes ago, CHBMB said:

Either reboot unRAID or try typing the address into the browser manually.

Sent from my LG-H815 using Tapatalk
 

I did that as well as I thought it was my internal DNS. https://<unraid-ip>:8443
This still redirects me to the unraid gui. 
Can you elaborate as to why rebooting would help the situation since I would think that restarting the container would be enough.

Edit: I also changed the WebUI in the template to accommodate my changes as well, still no joy. https://[IP]:[PORT:8443]/

Edited by manofcolombia
Link to comment
50 minutes ago, CHBMB said:

Arwe you using Nextcloud behind a reverse proxy as per my guide?

Behind nginx in a separate VM. This nginx instance provides all my reverse proxy needs and certs to all my other services, but going directly to the ip:port should still yield the webgui for the container unless unraid is also using 8443, correct? 

Based on my nmap, with my container on and off, it looks like unraid is not using 8443 unless my container is on. So I don't get why I'm still hitting the unraid gui instead of the container on that port.

EDIT: I fixed it. Even though I was going to the ip:port where the container was, I believe reverse dns lookup was kicking in. When it kicked it, my internal dns would direct me to my nginx instance which still had my proxy pass set to 443. So I was getting pushed back to the unraid gui on 443. 
Sorry for the trouble. It was just DNS trying to be helpful...

Edited by manofcolombia
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.