Nextcloud Bad Gateway

Zitat von KM0201

Maybe it's a cache issue, where you tried before?

I would try this... open a browser in Privacy/Incognito mode... and go to subdomain.duckdns.org and see if it gives you a secure login. If it does you know it's a cache issue. To fix that, just go to subdomain.duckdns.org (on a regular non private browser) and Hold Control and click F5. That should refresh it to a secure site.

Start there.

Nothing changed.

It brings me to the external static IP and from there to the Router.

Edit:

I have to go to the address 192.168.1.1 to reach the router.

When I enter subdomain.duckdns.org, it brings me to the address 96.89.275.666 and the home page of the Router.

Thanks for your help.

I followed the last step, but when I could not access Nextcloud, I activated it again.

I have now activated the DMZ.

nothing has changed.

Anyway I'll investigate further, if I find a solution I'll share it.

Thanks again.

Zitat von KM0201

You shouldn't need DMZ, assuming your router is connected directly to modem, which connects to the Internet... which seems likely in your scenario. I was pointing this out as another user I was helping was having a similar problem while DMZ'd

I suspect there is a port problem or other issue in your case because if you go to your duckdns subdomain, it's taking you to your router login, which makes no sense at all.

I am directly connected to the modem, there is no other router in between.

I have external static IP provided by ISP.

I have transferred this problem to ISS, they are examining the situation, I think they will give information tomorrow.

Do you think I should close the DMZ?

KM0201

Could you please allow me to migrate your tutorial to Odroid-HC4 Forum-Topic.

Zitat von KM0201

What is different? It should be exactly the same. Only thing I could imagine beiñg different, is if you're trying to pull an image that is not the default one.

But otherwise, yeah I don't own it.. do as you please.

You are not aware because you have a good command of OMV and NC.

Your narration is understandable and applicable to rookies like me and non-native English speakers.

I really spent a lot of time setting up NC. They provided me with almost special support in this forum, so NC was up and running.

When I saw your topic and applied what was written, I got the perfect and effortless NC again. By making copy and paste and completing other settings, Nextcloud-DackDns was ready in 10-15 minutes.

For rookies like me, this kind of software is like atom science, believe me.

Thank you for letting me use your tutorial.

I will direct the article I will share to your topic.

Additional to the AWESOME tutorial posted by KM0201. I would like to add the following since I had some warnings when I logged in as root and checking some things. So following things I added to the Tutorial:

You can see it as a continuation after the following:

Zitat

This is optional, but once you're done and you can log in to your subdomain properly and securely... If you want to disable insecure access from your local network, go back to your stack and make this adjustment under the "nextcloud" portion

Code

ports:

- 450:443

to this

#ports:

#- 450:443

Then redeploy the stack and you'll no longer have local access.

Alles anzeigen

As last steps:
Logged in as root go to Settings --> Overview and check for warnings and errors. I had 2 warnings with a reference to

Hardening and security guidance — Nextcloud latest Administration Manual latest documentation

--> Enable Strict-Transport-Security: More info about what STRICT TRANSPORT SECURITY is @ https://www.nginx.com/blog/htt…-security-hsts-and-nginx/

To enable this use the following steps:

1.) Go to Swag_Config_Folder/nginx/

2.) use nano or other editor to edit ssl_conf

3.) Enable the following line by removing the hashtag.

# HSTS, remove # from the line below to enable HSTS

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

4.) docker restart swag

--> Enable Default Country code for phones:

Country codes are defined in following norm:

ISO 3166-1 alpha-2 - Wikipedia

To enable this use following steps:

1.) Go to Nextcloud_config_folder/www/nextcloud/config/

2.) Use nano or other editor to edit config.php

3.) Add following line in front of the );

'default_phone_region' => 'COUNTRYCODE SEE WIKIPEDIA' e.g. 'DE'

4.) docker restart nextcloud

--> All warnings should be gone now!

Go to https://scan.nextcloud.com/ and do a security check of your nextcloud instance by entering your Nextcloud URL.

I didnt notice, because I only accessed nextcloud from outside my lan, but after following this configuration setup, I cant access the nextcloud server on port 450 anymore locally by typing <mylocalip>:450. Only if I delete the lines we changed in the config.php, specified below, I can access it locally again by the local-IP on port 450 again.

The problem now is that it is not possible to connect to the nextcloud when im in my own LAN network. Also my phone doesnt sync to nextcloud, if its connected to the wifi, which is inside the same lan network as the nextcloud server.

My Configuration is [Public-IP:179.12.67.26 Modem 192.168.0.1] --> [ 192.168.0.2 Router 192.168.1.1 ] --> [192.168.1.2 Openmediavault running nextcloud & 192.168.1.X Clients wanting to talk to nextcloud. (phone, laptop)

I think since all the records are pointing to the public IP, it doesnt know where to go. after the router. So if I request nextcloud from within the lan it asks my router for the DNS entry of <nextcloud.mydomain.duckdns.org> and then gets back the public IP. Changing this in the hosts entry of the Router doesnt help though because if I set up a DNS override for <nextcloud.mydomain.duckdns.org>, going to my openmediavault server, it will just retrieve the openmediavault webpage.

So how can I make the <nextcloud.mydomain.duckdns.org connectable from inside my lan network?

Also I think I found another "issue" that might turn out as a security risk or as an inconvenience, e.g. if all clients get banned because of Brute force attempts that seem to come from the same IP-adress. (although its all different users).

After I went to my nextcloud/nginx/access.log, I saw that there were only local IP-adresses shown.

As shown in: Nextcloud docs, it is necessary to correctly forward the real IP-adresses of the clients accessing nextcloud so that Bruteforce-protection works.

Since swag is actually receiving the traffic for nextcloud, the only IP the nextcloud server ever sees for me is the one from the swag containers reverse proxy.

So it is necessary to forward the real IP adresses to nextcloud.

In the Nextcloud docs, it is described, that one should add some headers to the config.php of nextcloud which is in the location: <Nextcloud-Config-Folder/www/nextcloud/config/config.php>

I added the following line:

'forwarded_for_headers' => array('HTTP_X_FORWARDED', 'HTTP_FORWARDED_FOR'),

before the );

After doing this and restarting Nextcloud, Nextclouds access.log now actually sees the real IP in <Nextcloud-Config-Folder/nginx/access.log>.

[Optional info]

It is notable that inside <Nextcloud-Config-Folder/nginx/site-confs/default> there are the following lines, which were added after this github issue: https://github.com/linuxserver…55#issuecomment-754623561

set_real_ip_from 172.0.0.0/8;

real_ip_header X-Forwarded-For;

So if your swag is not in that IP-Range (e.g. 192.168.X.X) be the case, then it will not forward the real IP-Adress to nextcloud, which will always see the same local IP of your swag-reverse-proxy.

So either make sure the swag container is in this IP-Range (should be if using docker and not using host network), or add another line to this site-conf with the IP-Range you want, e.g.

set_real_ip_from 10.0.0.0/8;

set_real_ip_from 192.168.0.0/16;

Additionally, following the explanation about the "trusted Proxies" setting in the config.php in Nextcloud docs.

Zitat von Nextcloud docs

Set the trusted_proxies parameter as an array of:

IPv4 addresses,

IPv4 ranges in CIDR notation

IPv6 addresses

to define the servers Nextcloud should trust as proxies. This parameter provides protection against client spoofing, and you should secure those servers as you would your Nextcloud server.

I am also not really sure why you, KM0201, say to add those lines below to the config.php, since the local IP isnt a proxy and doesnt need to be there in my opinion.

Zitat von from KM0201

'trusted_proxies' =>

array (

0 => 'your.ip:450',

1 => 'nextcloud.YOUR_SUBDOMAIN.duckdns.org',

),

In my config.php, I did it likeso and it works flawlessly.

'trusted_proxies' =>
array (
0 => 'swag',
),

It is also described to do it like this inside of the Swag-Config-Folder

There it says:

Zitat von Swag-Config-Folder/nginx/proxy-confs/nextcloud.subdomain.conf.sample

# assuming this container is called "swag", edit your nextcloud container's config

# located at /config/www/nextcloud/config/config.php and add the following lines before the ");":

# 'trusted_proxies' => ['swag'],

Zitat von KM0201

Again, if you read what I wrote.. I said, "It's not the only way...". Some of that stuff was required before swag was even a twinkle in the eye and everyone was using letsencrypt.

I rarely change what works (unless it stops working), and how I setup nextcloud (even after the swag migration, etc..) is no exception

Hey, I dont know why exactly you take it somehow as insulting or badmouthing of what you post (if you do, atleast it sounds like that, coming from the short and seemingly annoyed answer), yet the only thing I ever intend to do is just post information that I found out, and that may be helpful for the community. Maybe that way some people can get a more comprehensive view of what their doing and they can decide what they do with the given information on their machines.

So you can do however you wish to do, of course, and your guide is really really helpful and I used it also to setup my nextcloud since its the best out there.

Yet I think it is allowed to add some stuff to the forum that maybe is useful to one or another, maybe even yourself, if you get some feedback on how others do some setups that work.

Thats why I added all the sources so that all of us in the forum can together get some more knowledge about what were doing.

And thats also why I add the information about trusted proxy setting and also the forwarding headers, since that is actually pretty important and if people want brute force protection to work they have to use that information. Same goes for trusted proxy, for which, with my knowledge, if I setup something as a trusted proxy, and it actually shouldnt be, then I make myself vulnerable to IP spoofing.

Concering the issue I described about accessing the nextcloud locally. How is that working for you all? do you have access locally KM0201

How can I use subfolder instead of subdomain with below guide?

Zitat von KM0201

OK, here's how I do it. not saying it's the only way, it's just simple and should have you up and running in about 15min. Everything that starts with a # needs to be adjusted for your system and then the # erased. Nothing other than those lines need to be changed despite what you've seen in other tutorials. DO NOT ADJUST THE ##network_mode at this time. That will come later when we set up the proxy. Again, do not mix this with other tutorials, you'll just fail and be frustrated. All of the below assumes you have a basic understanding of containers and command line (config paths, data paths, PUID/PGID, changing directories, nano, etc.)

You can use this in docker-compose or in a stack in portainer (I'd recommend using a stack as it will show if you have formatting errors. As I proceed I will assume you're using this in a stack.):

1. Create your directories and make adjustments to the stack below (you might want to delete old directories from previous attempts if you've been at this several times). Start with only the nextcloud and nextclouddb sections and don't worry about swag for now. When done, deploy the stack.. It takes this container a minute to setup, so watch the logs (docker logs -f nextcloud) and also watch the database container (docker logs -f nextclouddb) and wait for both to indicate they are done. Use Cntrl +C to exit the logs.

Code

version: "2.1"
services:
  nextcloud:
    image: ghcr.io/linuxserver/nextcloud:latest
    container_name: nextcloud
    ##network_mode: swag_default
    environment:
      #- PUID=1000
      #- PGID=100
    volumes:
      #- /path/to/nextcloud/config:/config
      #- /path/to/nextcloud/data:/data
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - mariadb
    ports:
      - 450:443
    restart: unless-stopped
  mariadb:
    image: ghcr.io/linuxserver/mariadb:latest
    container_name: nextclouddb
    ##network_mode: swag_default
    environment:
      #- PUID=1000
      #- PGID=100
      #- MYSQL_ROOT_PASSWORD=YOUR_MYSQL_PASSWORD
    volumes:
      #- /path/to/mariadb/config:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped

Alles anzeigen

2. When done, go to nextcloud UI (https://your.omv.ip:450 , must use https and accept security risk)

3. Enter an admin user/password

4. Click setup database then mysql/mariadb database

user: root

password (see stack, line 24 above)

database name: nextcloud

localhost: nextclouddb

5. Click Finish (this will take a few minutes as it downloads apps and sets up the database, be patient). Note: IF it 504's after it sets up, this is very likely due to Nextcloud's App Store being down, as it frequently is. Give the containers a couple minutes to finish setting up, then simply use the back button on your browser and you should be logged in to the Nextcloud interface

Once you're logged in you can complete a basic setup of Nextcloud, or move on to set it up the reverse proxy with swag and a free duckdns subdomain. Proceeding assumes you have set up a free duckdns account, have setup your free subdomain on this account, and have access to your duckdns token. If you don't understand this, stop, post and ask or Google it till you do. It's also recommended at this time, if you don't have an SSH session at this time, start one.

If you use this set up exactly, in your router you'll need to make sure port 444 is forwarded to 443 and port 81 is forwarded to 80 (note: 444/81 are internal ports, 443/80 are external)

6. In Portainer, Add a new stack.

7. Name the stack swag

8. Copy/paste the swag compose file below and make necessary adjustments. Remember, only the # lines need adjusted

Code

version: "2.2"
services:
  swag:
    image: ghcr.io/linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      #- PUID=1000
      #- PGID=100
      #- URL=YOUR_SUBDOMAIN.duckdns.org
      #- DUCKDNSTOKEN=YOUR_TOKEN
      - SUBDOMAINS=wildcard
      - VALIDATION=duckdns
      #- EMAIL=YOUREMAIL
    volumes:
      #- /path/to/config:/config
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 444:443
      - 81:80
    restart: unless-stopped

Alles anzeigen

9. Deploy the swag stack.

10. Use your SSH session to watch your swag log and make sure you get a Congratulations message that a key was received. Use Cntrl + c to exit the log.

Code

docker logs -f swag

11. When your key is successfully received, you can navigate to https://www.YOUR-SUBDOMAIN.duckdns.org and you should see the swag park page secured with SSL (padlock by the URL). This tells you the reverse proxy is set up properly. Now, we simply need to route nextcloud through the swag container. Note: If you have made several failed attempts to get a key, and the log throws an error that it could not retrieve a key due to to many attempts, see this post for a simple fix, then redeploy the stack.

12. In the command line, Navigate to /config/swag/nginx/proxy-confs

13. Copy swags sample nextcloud.subdomain.conf, and drop the .sample extension

Code

cp nextcloud.subdomain.conf.sample nextcloud.subdomain.conf

14. docker restart swag

15. In Portainer, go to your nextcloud stack

16. Uncomment the ##network modes in the stack. If you've followed this exactly, your swag network is going to be named swag_default. If you're unsure or maybe you've taken multiple cracks at this, simply click Networks on the left, and see what network name is assigned to the swag stack and if it is different, then make the appropriate change.

17. Deploy the nextcloud stack.

18. Navigate to: /config/nextcloud/www/nextcloud/config

19. nano config.php

20. Under trusted domains array add your domain (you should see your local IP address there as 0), be sure to add it before the ),

Code

1 => 'nextcloud.yoursubdomain.duckdns.org', 

21. Add or edit the lines below, after the ), and before the );

Code

'overwrite.cli.url' => 'https://nextcloud.yoursubdomain.duckdns.org',
'overwritehost' => 'nextcloud.yoursubdomain.duckdns.org',
'overwriteprotocol' => 'https',

When you're done, your config.php will look something like this (11, 23, 24, 25 are the lines I added in. A couple of those lines will already be there.. so you can either edit them as appropriate or delete them and add them in at the end like I did, either way just make sure there are no duplicates and it looks similar to the below

PHP

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'oc3wozk6kai4',
  'passwordsalt' => '2snos3M0EllfFy1CQH0Lah6kOEPyFC',
  'secret' => 'it8C+qSyNcafTBLDp8nHQCAq9o/Fs9nUOgd/gYNFN5/Ro4pW',
  'trusted_domains' => 
  array (
    0 => 'YOUR_LOCAL_IP:450',
    1 => 'nextcloud.YOURSUBDOMAIN.duckdns.org',
  ),
  'dbtype' => 'mysql',
  'version' => '20.0.6.1',
  'dbname' => 'nextcloud',
  'dbhost' => 'nextclouddb',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'oc_admin',
  'dbpassword' => 'YfPeqGJ8LlsOIkXpgiEtf3bejjLtUK',
  'installed' => true,
  'overwrite.cli.url' => 'https://nextcloud.YOURSUBDOMAIN.duckdns.org',
  'overwritehost' => 'nextcloud.YOURSUBDOMAIN.duckdns.org',
  'overwriteprotocol' => 'https',
  );

Alles anzeigen

14. Save and close (Cntrl x then Y to save)

15. Restart the Nextcloud container: docker restart nextcloud

16. Navigate to https://nextcloud.yoursubdomain.duckdns.org and log in.

This is optional, but once you're done and you can log in to your subdomain properly and securely... If you want to disable insecure access from your local network, go back to your stack and make this adjustment under the "nextcloud" portion

Code

    ports:
      - 450:443

to this

    #ports:
      #- 450:443

Then redeploy the stack and you'll no longer have local access.

You're done.

A few solutions to some common "issues"..

Log in as Admin, Go to Settings/Overview. You'll likely notice that there are some "warnings" regarding your setup...

Code

There are some warnings regarding your setup.

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 installation has no default phone region set. This is required to validate phone numbers in the profile settings without a country code. To allow numbers without a country code, please add "default_phone_region" with the respective ISO 3166-1 code ↗ of the region to your config file.

Thanks to oopenmediavault for pointing these out. There were a few typos in his instructions that caused an error when the containers were redeployed, so they are restated here...

These two are very simple fixes...

1.) Navigate to /config/swag/nginx/

2.) nano ssl.conf

3.) Remove hashtag from from the front following line.

#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

4.) docker restart swag

Country codes are defined in following norm:

ISO 3166-1 alpha-2 - Wikipedia

1.) Navigate to /config/nextcloud/www/nextcloud/config/

2.) nano config.php

3.) Add the following to the end, before the );

Code

'default_phone_region' => 'COUNTRY_CODE',  

##(note: do not miss the comma on the end of this line)

4.) docker restart nextcloud

Refresh your nextcloud admin page, and those two errors should be gone.

Some users may also get this error.

Code

There are some warnings regarding your setup.

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 as visible to the Nextcloud. Further information can be found in the documentation.

Alles anzeigen