[Support] Linuxserver.io - Nextcloud

[live4soccer7]

In my opinion it seems that the subdomain.conf isn't even getting read yet by letsencrypt. It it were and the subdomain.conf wasn't setup properly then I would think there simply would be a gateway error and not the default letsencyrpt index.html page.

 

It simply seems that letsencrypt is not being told to read the subdomain.conf and therefore not pointing to the container location where that container's file would then be served from by the webserver.

 

 

Edited April 29, 2020 by live4soccer7

[Tucubanito07]

2 minutes ago, live4soccer7 said:

In my opinion it seems that the subdomain.conf isn't even getting read yet by letsencrypt. It it were and the subdomain.conf wasn't setup properly then I would think there simply would be a gateway error and not the default letsencyrpt index.html page.

 

It simply seems that letsencrypt is not being told to read the subdomain.conf and therefore not pointing to the container location where that container's file would then be served from by the webserver.

 

 

It could be. If they are both setup correctly. Check your dns up address. Make sure it updates. I had that same issue and once my dns récord up address updated it started to work. 

[live4soccer7]

5 minutes ago, Tucubanito07 said:

It could be. If they are both setup correctly. Check your dns up address. Make sure it updates. I had that same issue and once my dns récord up address updated it started to work. 

Are you referring to the router's WAN IP that would be provided in a DDNS service such as duckdns? If so, that is correct. If it weren't then it wouldn't load back to the server from an external source and load the index.html page that is shown. I'm confident that is setup properly. I'm thinking that it would be something in the default.conf file within let's encrypt. I am attaching it now.

 

## Version 2020/03/05 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default

# redirect all traffic to https
server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

# main server block
server {
	listen 443 ssl http2 default_server;
	listen [::]:443 ssl http2 default_server;

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

	server_name _;

	# enable subfolder method reverse proxy confs
	include /config/nginx/proxy-confs/*.subfolder.conf;

	# enable subdomain method reverse proxy confs
	#include /config/nginx/proxy-confs/*.subdomain.conf;

	# all ssl related config moved to ssl.conf
	include /config/nginx/ssl.conf;

	# enable for ldap auth
	#include /config/nginx/ldap.conf;

	client_max_body_size 0;

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

	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass 127.0.0.1:9000;
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;
	}

# sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp"
# notice this is within the same server block as the base
# don't forget to generate the .htpasswd file as described on docker hub
#	location ^~ /cp {
#		auth_basic "Restricted";
#		auth_basic_user_file /config/nginx/.htpasswd;
#		include /config/nginx/proxy.conf;
#		proxy_pass http://192.168.1.50:5050/cp;
#	}

}

# sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above
# notice this is a new server block, you need a new server block for each subdomain
#server {
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;
#
#	root /config/www;
#	index index.html index.htm index.php;
#
#	server_name cp.*;
#
#	include /config/nginx/ssl.conf;
#
#	client_max_body_size 0;
#
#	location / {
#		auth_basic "Restricted";
#		auth_basic_user_file /config/nginx/.htpasswd;
#		include /config/nginx/proxy.conf;
#		proxy_pass http://192.168.1.50:5050;
#	}
#}

# sample reverse proxy config for "heimdall" via subdomain, with ldap authentication
# ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info
# notice this is a new server block, you need a new server block for each subdomain
#server {
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;
#
#	root /config/www;
#	index index.html index.htm index.php;
#
#	server_name heimdall.*;
#
#	include /config/nginx/ssl.conf;
#
#	include /config/nginx/ldap.conf;
#
#	client_max_body_size 0;
#
#	location / {
#		# the next two lines will enable ldap auth along with the included ldap.conf in the server block
#		auth_request /auth;
#		error_page 401 =200 /login;
#
#		include /config/nginx/proxy.conf;
#		resolver 127.0.0.11 valid=30s;
#		set $upstream_app heimdall;
#		set $upstream_port 443;
#		set $upstream_proto https;
#		proxy_pass $upstream_proto://$upstream_app:$upstream_port;
#	}
#}

# enable subdomain method reverse proxy confs
include /config/nginx/proxy-confs/*.subdomain.conf;
# enable proxy cache for auth
proxy_cache_path cache/ keys_zone=auth_cache:10m;

 

This is the part that is the most interesting and seems like the culprit at this point.

 

# enable subdomain method reverse proxy confs

include /config/nginx/proxy-confs/*.subdomain.conf;

 

as you can see, I have added it in toward the beginning of this file, but it creates a can not connect to server error when I do this (typical message seen within a browser).

Edited April 29, 2020 by live4soccer7

[ssinseeme]

19 hours ago, Curious_George said:

I think I am starting to lose my mind trying to make NextCloud work, just as a local service at this stage, without reverse proxy etc.

 

I have followed both the installation guide at the beginning of this thread, and SpaceInvaderOne's guide to the letter, multiple times now over the last day.

 

MariaDB installs ok, I am able to create the databases required.

When I get to the WebUI setup for NextCloud, I am always brought to a halt by "504 Gateway TimeOut"

 

Checking the NextCloud error log I see "2020/04/29 11:35:41 [error] 358#358: *4 upstream timed out (110: Operation timed out) while reading response header from upstream, client: 192.168.1.101, server: _, request: "POST /index.php HTTP/2.0", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.69:4445"

 

If I try again, I get an error that "user already exists" but I can't seem to be able to get past the installation webui.

 

I see that this question has been asked previously in this thread, but there was no response to it.  I also see a couple of reddit posts specifically asking the same question in relation to unraid and nextcloud, but with no solutions either.

 

Any help or suggestions would be most appreciated please.

 

 

I am not an expert since I have some issue. But. Did you have port forwarding set up right and the config file in letencrypt ok. Do you have anything else running on reverse proxy running ok. It seem to be Letencrypt issues 

[Tucubanito07]

10 minutes ago, live4soccer7 said:

Are you referring to the router's WAN IP that would be provided in a DDNS service such as duckdns? If so, that is correct. If it weren't then it wouldn't load back to the server from an external source and load the index.html page that is shown. I'm confident that is setup properly. I'm thinking that it would be something in the default.conf file within let's encrypt. I am attaching it now.

 

## Version 2020/03/05 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default

# redirect all traffic to https
server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

# main server block
server {
	listen 443 ssl http2 default_server;
	listen [::]:443 ssl http2 default_server;

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

	server_name _;

	# enable subfolder method reverse proxy confs
	include /config/nginx/proxy-confs/*.subfolder.conf;

	# enable subdomain method reverse proxy confs
	#include /config/nginx/proxy-confs/*.subdomain.conf;

	# all ssl related config moved to ssl.conf
	include /config/nginx/ssl.conf;

	# enable for ldap auth
	#include /config/nginx/ldap.conf;

	client_max_body_size 0;

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

	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass 127.0.0.1:9000;
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;
	}

# sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp"
# notice this is within the same server block as the base
# don't forget to generate the .htpasswd file as described on docker hub
#	location ^~ /cp {
#		auth_basic "Restricted";
#		auth_basic_user_file /config/nginx/.htpasswd;
#		include /config/nginx/proxy.conf;
#		proxy_pass http://192.168.1.50:5050/cp;
#	}

}

# sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above
# notice this is a new server block, you need a new server block for each subdomain
#server {
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;
#
#	root /config/www;
#	index index.html index.htm index.php;
#
#	server_name cp.*;
#
#	include /config/nginx/ssl.conf;
#
#	client_max_body_size 0;
#
#	location / {
#		auth_basic "Restricted";
#		auth_basic_user_file /config/nginx/.htpasswd;
#		include /config/nginx/proxy.conf;
#		proxy_pass http://192.168.1.50:5050;
#	}
#}

# sample reverse proxy config for "heimdall" via subdomain, with ldap authentication
# ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info
# notice this is a new server block, you need a new server block for each subdomain
#server {
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;
#
#	root /config/www;
#	index index.html index.htm index.php;
#
#	server_name heimdall.*;
#
#	include /config/nginx/ssl.conf;
#
#	include /config/nginx/ldap.conf;
#
#	client_max_body_size 0;
#
#	location / {
#		# the next two lines will enable ldap auth along with the included ldap.conf in the server block
#		auth_request /auth;
#		error_page 401 =200 /login;
#
#		include /config/nginx/proxy.conf;
#		resolver 127.0.0.11 valid=30s;
#		set $upstream_app heimdall;
#		set $upstream_port 443;
#		set $upstream_proto https;
#		proxy_pass $upstream_proto://$upstream_app:$upstream_port;
#	}
#}

# enable subdomain method reverse proxy confs
include /config/nginx/proxy-confs/*.subdomain.conf;
# enable proxy cache for auth
proxy_cache_path cache/ keys_zone=auth_cache:10m;

 

This is the part that is the most interesting and seems like the culprit at this point.

 

# enable subdomain method reverse proxy confs

include /config/nginx/proxy-confs/*.subdomain.conf;

 

as you can see, I have added it in toward the beginning of this file, but it creates a can not connect to server error when I do this (typical message seen within a browser).

Let me look at my Letsencrypt and config file and get back with you. I am no expert but maybe together we can figure this out. I currently at work. Once I am done I’ll try to send you my config files so you can mimic them n

[live4soccer7]

7 minutes ago, Tucubanito07 said:

Let me look at my Letsencrypt and config file and get back with you. I am no expert but maybe together we can figure this out. I currently at work. Once I am done I’ll try to send you my config files so you can mimic them n

Thank you very much. I have definitely expended many many many hours getting this setup, so it isn't a lack of effort. I am no expert either. I think that something has changed in the latest versions released by LSIO as I'm seeing my stock files included are just a little different than others' files on the thread. Hopefully, with your configs I may be able to piece something together.

[ozone31912]

13 minutes ago, daveo132 said:

So I have started again for the 3rd time.

I'm still unable to get this working.

Issue 1.  When linked MariaDB to Nextcloud I get a 504 timeout error.

Issue 2.  I have followed the guide to a T, lets encrypt in unable to authorise my domain.

Unfortunately, I now seem to have exceeded my limit on domain checks

 

I own my own domain.

I have created the domain nextcloud.[my domain].co.uk ===> duckdns =====> my IP - this IP is correct as I have already trouble shot this using ifconfig.me

 

Hey Daveo132,

 

I had trouble getting letsencrypt to give me a cert. I highly recommend checking out SpaceInvaders video on DNS verification with letsencrypt. I used that instead and was a lot easier.

Edited April 29, 2020 by ozone31912

[saarg]

55 minutes ago, live4soccer7 said:

Are you referring to the router's WAN IP that would be provided in a DDNS service such as duckdns? If so, that is correct. If it weren't then it wouldn't load back to the server from an external source and load the index.html page that is shown. I'm confident that is setup properly. I'm thinking that it would be something in the default.conf file within let's encrypt. I am attaching it now.

 

## Version 2020/03/05 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default

# redirect all traffic to https
server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

# main server block
server {
	listen 443 ssl http2 default_server;
	listen [::]:443 ssl http2 default_server;

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

	server_name _;

	# enable subfolder method reverse proxy confs
	include /config/nginx/proxy-confs/*.subfolder.conf;

	# enable subdomain method reverse proxy confs
	#include /config/nginx/proxy-confs/*.subdomain.conf;

	# all ssl related config moved to ssl.conf
	include /config/nginx/ssl.conf;

	# enable for ldap auth
	#include /config/nginx/ldap.conf;

	client_max_body_size 0;

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

	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass 127.0.0.1:9000;
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;
	}

# sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp"
# notice this is within the same server block as the base
# don't forget to generate the .htpasswd file as described on docker hub
#	location ^~ /cp {
#		auth_basic "Restricted";
#		auth_basic_user_file /config/nginx/.htpasswd;
#		include /config/nginx/proxy.conf;
#		proxy_pass http://192.168.1.50:5050/cp;
#	}

}

# sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above
# notice this is a new server block, you need a new server block for each subdomain
#server {
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;
#
#	root /config/www;
#	index index.html index.htm index.php;
#
#	server_name cp.*;
#
#	include /config/nginx/ssl.conf;
#
#	client_max_body_size 0;
#
#	location / {
#		auth_basic "Restricted";
#		auth_basic_user_file /config/nginx/.htpasswd;
#		include /config/nginx/proxy.conf;
#		proxy_pass http://192.168.1.50:5050;
#	}
#}

# sample reverse proxy config for "heimdall" via subdomain, with ldap authentication
# ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info
# notice this is a new server block, you need a new server block for each subdomain
#server {
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;
#
#	root /config/www;
#	index index.html index.htm index.php;
#
#	server_name heimdall.*;
#
#	include /config/nginx/ssl.conf;
#
#	include /config/nginx/ldap.conf;
#
#	client_max_body_size 0;
#
#	location / {
#		# the next two lines will enable ldap auth along with the included ldap.conf in the server block
#		auth_request /auth;
#		error_page 401 =200 /login;
#
#		include /config/nginx/proxy.conf;
#		resolver 127.0.0.11 valid=30s;
#		set $upstream_app heimdall;
#		set $upstream_port 443;
#		set $upstream_proto https;
#		proxy_pass $upstream_proto://$upstream_app:$upstream_port;
#	}
#}

# enable subdomain method reverse proxy confs
include /config/nginx/proxy-confs/*.subdomain.conf;
# enable proxy cache for auth
proxy_cache_path cache/ keys_zone=auth_cache:10m;

 

This is the part that is the most interesting and seems like the culprit at this point.

 

# enable subdomain method reverse proxy confs

include /config/nginx/proxy-confs/*.subdomain.conf;

 

as you can see, I have added it in toward the beginning of this file, but it creates a can not connect to server error when I do this (typical message seen within a browser).

Remove the one you added. There is no need to edit anything in the default file to get proxy confs working. All you have to do is to remove the .sample part, edit the file if it is mentioned to do so in the top of the file and restart letsencrypt. Did you restart letsencrypt?

[ozone31912]

Sorry to repost, but my question became mixed in the previous page.

 

Hi everyone, quick question about my nextcloud speed.

 

I setup nextcloud with nginxproxymanager(DNS cloudflare) and the external device plugin which connects to one of my shares. Everything is working great, except that when I download the files externally, I get a max download speed of 2mbps. My internet connection is 300mbps and would like help trying to figure out where my bottleneck is. 

 

I have downloaded the speedtest docker, and through the proxy I am getting 16mbps. Locally with the speedtest docker I am breaking 250+mbps.

 

What speeds are other users getting?

 

Thanks,

 

Owen

Edited April 29, 2020 by ozone31912

[live4soccer7]

41 minutes ago, saarg said:

Remove the one you added. There is no need to edit anything in the default file to get proxy confs working. All you have to do is to remove the .sample part, edit the file if it is mentioned to do so in the top of the file and restart letsencrypt. Did you restart letsencrypt?

It is commented out, so essentially no change. You can see where it is commented out. Yes, I restarted everything. Otherwise everything is 100% stock in this file. I commented out my addition, so it has no effect.

[saarg]

1 hour ago, live4soccer7 said:

It is commented out, so essentially no change. You can see where it is commented out. Yes, I restarted everything. Otherwise everything is 100% stock in this file. I commented out my addition, so it has no effect.

Didn't see it was commented out.

You have created a custom network that both nextcloud and letsencrypt use, right? If so you have not followed the instructions at the top of the proxy conf. You have changed the port from 443 to 444. That is something you should not do. Change it back to 443 and restart letsencrypt.

[live4soccer7]

50 minutes ago, saarg said:

Didn't see it was commented out.

You have created a custom network that both nextcloud and letsencrypt use, right? If so you have not followed the instructions at the top of the proxy conf. You have changed the port from 443 to 444. That is something you should not do. Change it back to 443 and restart letsencrypt.

Are you referring to the container port? I have changed the port that the nexcloud container uses to 444 (why my subdomain.conf and config.php reflect this). You're saying to leave it at 443 and then adjust the subdomain.conf and config.php back to 443 for the container port? I still don't think this would be the issue because I tried setup the subdomain for sonarr with lets encrypt as well and my results are the exact same as with nextcloud.

 

Yes, I have created a custom network that nextcloud and letsencrypt are on.

 

I really appreciate everyone's time on this. I have been pulling my hair out over this for the last week and a half.

[live4soccer7]

I just changed the container port to 443, adjusted nextcloud.subdomain.conf to 443 and same with nextcloud's config.php. The result was the same. It is simply loading the letsencrypt index.html, so nexcloud's proxy is not getting passed.

 

In the readme within proxy-confs for letsencrypt, the following lines standout to me. Is there really nothing to do within the default site config?

 

### Configure your default site config

Make sure that your default site config contains the following lines in the appropriate spots as seen in the default version:

1) For subfolder methods: `include /config/nginx/proxy-confs/*.subfolder.conf;`
2) For subdomain methods: `include /config/nginx/proxy-confs/*.subdomain.conf;`

[live4soccer7]

I got it! It just hit me. It seemed like the subdomain.conf was not getting read, so I though well maybe the subfolder inclusion in the letsencrypt default conf was actually over-riding or taking priority/preference over the subdomain.conf inclusion. It came with both uncommented. I commented out the subfolder and voila.

 

# enable subfolder method reverse proxy confs

#include /config/nginx/proxy-confs/*.subfolder.conf;

 

Again, this is in: letsencrypt/nginx/site-confs/default

 

I suppose it is possible that I uncommented this somehow without realizing it, but I'm pretty sure it came with both uncommented.

[live4soccer7]

One thing to note, I did change the ports back to 443. I wanted to change back to 444 or something different, however when I did this by changing it in the nextcloud docker container (444), the nextcloud config.php, and the nextcloud.subdomain.conf, I was presented with a 502 bad gateway. Is there another file that would need adjusted that I'm simply not seeing?

[Coolsaber57]

On 4/25/2020 at 11:55 AM, alturismo said:

i guess not too many, otherwise u would see alot more posts about it

 

did u checked at your server if there are errors etc popping up ?

 

 

Yep, I looked at the container logs - no errors at all.  Trying to dig into Nextcloud's UI to see if there is additional logging that will tell me what's going on.  It's just weird, it only happened recently, so I thought it was an update.

[saarg]

6 hours ago, live4soccer7 said:

One thing to note, I did change the ports back to 443. I wanted to change back to 444 or something different, however when I did this by changing it in the nextcloud docker container (444), the nextcloud config.php, and the nextcloud.subdomain.conf, I was presented with a 502 bad gateway. Is there another file that would need adjusted that I'm simply not seeing?

You are messing around with settings you don't need to change.

There is no mention of changing the port in the proxy conf, so that means don't change the port! It's talking on the internal docker network, so port mapping doesn't apply. 443 is the correct port.

 

Leave the nextcloud config at 444, as that is for accessing locally using IP.

 

As for the default file you keep on insisting to edit, don't! There is nothing you have to comment or uncomment to make either subdomain or subfolder working.

[live4soccer7]

11 minutes ago, saarg said:

You are messing around with settings you don't need to change.

There is no mention of changing the port in the proxy conf, so that means don't change the port! It's talking on the internal docker network, so port mapping doesn't apply. 443 is the correct port.

 

Leave the nextcloud config at 444, as that is for accessing locally using IP.

 

As for the default file you keep on insisting to edit, don't! There is nothing you have to comment or uncomment to make either subdomain or subfolder working.

I'm not sure what to say. I put everything back to the way it downloaded (unchanged) with the exception of commenting out the subfolder aspect in the default conf file within letsencrypt. At that point everything worked as expected and I have also set up to other dockers on subdomains without issues and without having to edit any files other than changing servername to match my subdomain.

[Curious_George]

13 hours ago, ssinseeme said:

I am not an expert since I have some issue. But. Did you have port forwarding set up right and the config file in letencrypt ok. Do you have anything else running on reverse proxy running ok. It seem to be Letencrypt issues 

I don't have letsencrypt, nor port forwarding. This is a simple local install for the time being as I am behind CG-NAT - direct local connection between two machines on the same LAN. 

[nraygun]

On 4/24/2020 at 11:06 AM, nraygun said:

Thanks, I think I see it. Some text was black and hard to read in my browser, but it looks like doing it through the Web UI is OK. Although, the last time didn't go so well, so maybe next time I'll try the manual method.

"For upgrading the Nextcloud version, please see this guide here.  Alternatively, you can update via the Nextcloud webui."

Thinking about this more - if Nextcloud updating is a manual process, what gets updated when the docker gets updated? I just noticed an update to the container (along with DuckDNS and Letsencrypt) but it's still at the same version(18.03) and not the latest(18.04).

[Tucubanito07]

17 minutes ago, nraygun said:

Thinking about this more - if Nextcloud updating is a manual process, what gets updated when the docker gets updated? I just noticed an update to the container (along with DuckDNS and Letsencrypt) but it's still at the same version(18.03) and not the latest(18.04).

Thanks for asking that and I am going to piggy back on a couple of other questions. I was going to ask the same questions. Do we update the container and once that is done, update the Nextcloud ui the manual way on the first post of the thread? Would love to know the answer to yours and mine. 

[live4soccer7]

^ definitely a good question.

 

I have another quick question. Once SSL/Letsencrypt is setup and working, should I be able to access the docker at the local address:port (192.168.1.110:444) or will it only be accessible via the URL/Domain that was setup?

[saarg]

3 hours ago, Tucubanito07 said:

Thanks for asking that and I am going to piggy back on a couple of other questions. I was going to ask the same questions. Do we update the container and once that is done, update the Nextcloud ui the manual way on the first post of the thread? Would love to know the answer to yours and mine. 

When you update the container you update everything except nextcloud. So is pacakges and dependencies.

Update the container first, then nextcloud.

[saarg]

1 hour ago, live4soccer7 said:

^ definitely a good question.

 

I have another quick question. Once SSL/Letsencrypt is setup and working, should I be able to access the docker at the local address:port (192.168.1.110:444) or will it only be accessible via the URL/Domain that was setup?

You can access it via the IP, but you will be redirected to the domain when the page loads.

[Tucubanito07]

2 minutes ago, saarg said:

When you update the container you update everything except nextcloud. So is pacakges and dependencies.

Update the container first, then nextcloud.

You are amazing like always @saarg thank you. I figured that what it was doing but wanted to make sure.