Help Me Narrow Down Where I Go Wrong (NextCloud Remote Tutorial)

  • I am following this this tutorial to try and get NextCloud working remotely, but I am getting a "refuse to connect" error when trying to access Nextcloud through my domain.

    During setup of everything, I get an error (another post) when I tried to add --network my-net to Extra arguments both in the nextcloud and letsencrypt containers. For the letsencrypt container, however, I am successfully able to add --cap-add=NET_ADMIN to Extra arguments. From my previous thread I created, I am pretty sure that the work around to the Extra arguments error I got was to go to the tab Networks in Docker, and then click on my-net to highlight it, and then click "Connect," and choose "nextcloud", leave everything else blank, and click save. And then do it all again and choose "letsencrypt." Then under "containers" in my-net, it shows "nextcloud,letsencrypt". This is the correct thing to do, right? If not, maybe that's what is causing me to not connect to my Nextcloud with my dns domain?

    Another thing that happens, and doesn't go according to what the tutorial shows, is when I go to create certificates using the command docker logs -f letsencrypt. I do get (my DNS domain redacted):

    Congratulations! Your certificate and chain have been saved at:
    Your key file has been saved at:

    However, after it says, "If you like Certbot, please consider supporting our work by" (and then some websites), this is what happens:

    I checked \AppData\Letsencrypt\etc\letsencrypt\live\ and see fullchain.pem and privkey.pem there. At this point, if I use a port checker tool, ports 80 and 443 are open, and I can go to my domain in my browser and it shows "Welcome to our server". As soon as I edit nextcloud.subdomain.conf.sample and save it as nextcloud.subdomain.conf and restart the letsencrypt container, port 80 & 443 are blocked and my domain I'm trying to access refuses to connect. But I can continue to get into my Nexcloud using https://localipaddress:444. Here is everything that it is in my nextcloud.subdomain.conf file (it looks slightly different than what's in the video; it has an extra line with listen [::]:443 ssl;):

    If I continue with the tutorial and navigate to /sharedfolders/AppData/Nextcloud/www/nextcloud/config/ and try to open the config.php file with Notepad ++, it says "Can not open file." So I have to navigate to the config folder and use nano to edit config.php. After this, I still get a refuse to connect error, but I also can't get into my Nextcloud with the local IP address (it redirects to the subdomain, as expected after changed the config.php file).

    So how do I narrow down where the problem is, and where do I begin to fix it?

  • I think I may have made some progress. I read this thread, and after changing the line proxy_max_temp_file_size 2048m to proxy_max_temp_file_size 1024m in the nextcloud.subdomain.conf file and restarting the letsencrypt container, I noticed that ports 80 & 443 were still open! However, when I tried to access, I got "502 Bad Gateway". If I completely delete the line proxy_max_temp_file_size 1024m (or 2048m which is default), ports 80 & 443 are still open, but I still get "502 Bad Gateway" when trying to access my domain.

  • Success!!! I was very close... so I Googled about 502 Bad Gateway with regards to getting Nextcloud on OMV working remotely, and I came across this thread, which then brought me to this thread. After reading about checking to see if the network and proper dockers were joined, I thought, "But I already did that under the Networks tab in docker." But I decided to check anyway. I saw that the nextcloud docker was joined to my-net (the network I created), but letsencrypt was not! So I joined letsencrypt, and BAM, it worked!

    I think that in my effort to fix things, I had deleted letsencrypt and started over with it, but forgot to join it again. So when I changed 2048m to 1024m in the nextcloud.subdomain.conf file, it would have worked right away, had I joined the containers properly.

    As a side note, there is no need to remove listen [::]:443 ssl; and I can actually completely delete the line proxy_max_temp_file_size 1024m; since I don't want limits on file size uploads (someone pointed out this problem in the comments on the YouTube video tutorial).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!