Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

Zitat von Soma

Yep, did it yesterday:

I'm staying at a house that has the router available (and the access details in plain site, ).

So, made a simple SWAG stack,

Made a duckdns domain.

Portforwarded the 80 to 81, 443 to 444 on the router to the IP of the test Pi

Launched the stack

But hit a wall due to problems with letsencrypt acme server beeing down.

Read a bit and found instructions to create the certificate by bashing to swag and running certbot with duckdns plugin.

After 5 minutes, I had SWAG page fully secured.

So, yeah, it's that simple,

Only thing I still haven't done, is moving the domain to a private one I bought (holding on to when I move to OMV6)

Alles anzeigen

It's just as easy. I was nervous when I bought a domain as I'd never done that sort of thing.

Only thing different you have to do is create an A record and then just create CNAME's for each of your subdomains (I'm not sure on subfolder).. then redeploy swag to get a new key for the new subdomain.

This is one reason why personally, I like using the "network mode" in my containers to attach them to swag. By doing that, it keeps me from having 1 big ass docker-compose/stack file with all my containers I need routed through swag. Also, if I need to adjust the stack of just one of my containers... I don't have to redeploy the entire stack, since almost all my containers are in their own stack.

Zitat von Soma

That is your problem, change OMV port to 90 or other than 80

I don't think so. I'm on my way home but I'm pretty sure my router settings look exactly like his.

I have OMV on port 80

Zitat von Soma

I remember a thread that you said you had port 90 (or 99 )

When we where doing the subdomain.conf for OMV

Thinking better, it won't conflict with SWAG, so probably doesn't matter.

Unless some other container/yml on the same stack is using port 80

Since Starbuck1973 issue doesn't relate to macom guide (I trust is the one you made) maybe it's better to follow this on a new/different thread so it won't mix infos for who ever reads this.

Alles anzeigen

Actually it pretty closely conforms to macoms guide (the one I wrote before that, was more along the lines of TDL's video.. which was problematic). Only thing I changed was separating the swag stack and using network mode.

Edit: oh, and I did change my OMV port to 99 (surprised you remembered that..lol) when I forwarded the OMV webUI through my domain... but I really just done that for proof of concept and didn't keep it very long. I find the webUI kinda useless from the Internet... If I need access to my server from the Internet, I use SSH (which I do via a wetty docker through my domain..lol)

Zitat von Soma

Ok, so if I understand correct, you have on the SWAG stack:

Code

networks:
  default:
    # Use a custom driver
    driver: custom-driver-1

And on the rest of the stacks:

Code

networks:
  default:
    external: true
    name: my-pre-existing-network #<---- the name of the network from above

Nope... example... my swag stack...

version: "2.2"
services:
  swag:
    image: ghcr.io/linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=100
      - URL=my-domain.xyz
      - SUBDOMAINS=www,piwigo,calibre-web,airsonic,wetty,nextcloud,kavita
      - VALIDATION=http
      - EMAIL=myemail@domain.com
      - CERTPROVIDER=zerossl
    volumes:
      - /NAS/AppData/swag:/config
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 444:443
      - 81:80
    restart: unless-stopped

Once I deploy swag, and successfully get a key for my domain, etc. I need to figure out the network mode docker assigned to the container. 99% of the time (unless you've made a ton of attempts at this).. it will be container-name_default. But I've had a few times where I've seen it different.

You can do this by looking under Networks in Portainer, or with the following command

docker inspect container_name | grep NetworkMode

So in my case, as you see, swag was assigned the network of "swag_default".

ken@openmediavault:~$ docker inspect swag | grep NetworkMode
            "NetworkMode": "swag_default",
ken@openmediavault:~$ 

Now, any containers I want to link through swag... I just add that network mode to the stack.... This allows me to keep my stacks separate from "swag" making individual stacks are easy to update and deploy w/o effecting anything else (if they were all in one huge stack or compose file)

A couple of examples (note the network_mode in each of the stacks below under "container_name").

Hopefully that makes sense.

version: "2.2"
services:
  nextcloud:
    image: ghcr.io/linuxserver/nextcloud:latest
    container_name: nextcloud
    network_mode: swag_default
    environment:
      - PUID=1000
      - PGID=100
    volumes:
      - /NAS/AppData/nextcloud:/config
      - /NAS/Media/.Nextcloud:/data
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - mariadb
    #ports:
      #- 450:443
    restart: unless-stopped
  mariadb:
    image: ghcr.io/linuxserver/mariadb:alpine
    container_name: nextclouddb
    network_mode: swag_default
    environment:
      - PUID=1000
      - PGID=100
      - MYSQL_ROOT_PASSWORD=yeah-right.. :)
    volumes:
      - /NAS/AppData/nextclouddb:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped

version: "2.2"
services:
  airsonic:
    image: ghcr.io/linuxserver/airsonic
    container_name: airsonic
    network_mode: swag_default
    environment:
      - PUID=1000
      - PGID=100
    volumes:
      - /NAS/AppData/airsonic:/config
      - /NAS/Media/Music:/music
      - /NAS/Media/Music/.Playlists:/playlists
      - /NAS/Media/Music/.Podcasts:/podcasts
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 4040:4040
    restart: unless-stopped

version:  "2"
services:
     wetty:
        image: svenihoney/wetty:latest
        container_name: wetty
        network_mode: swag_default
        environment:
            - PUID=1000
            - PGID=100
            - REMOTE_SSH_SERVER=192.168.1.166  ##Adjust
            - REMOTE_SSH_PORT=22
        volumes:
            - /etc/localtime:/etc/localtime:ro
        ports:
            - 3000:3000
        restart:  unless-stopped

and that's it. Once they are all on swag's network.. it's just a matter of setting up their CNAME on my domain panel and then setting up their subdomain.conf in the swag configuration folder.

Once that is done, restart the containers, and they'll be at https://subdomain.my-domain.xyz

Hopefully that makes sense. It's honestly way easier than it sounds.

Zitat von Soma

I already had understood what you had done.

Just thought the network environment to be different, (as I wrote above, since that's how it's described on the docker-compose docs )

With those examples, it's pretty much straight forward.

And no need to edit subdomain.confs from app to LAN IP,

Nice one.

Alles anzeigen

EXACTLY!

As for the network mode differences.. I think it's different for various versions of docker-compose. Virtually all of mine are 2.2.. so they "just work" the way I did it.

And like you said, it's dead nuts simple. I change to the proxy-confs folder, copy some service.subdomain.conf.sample and drop the sample, and that's really all I have to do.

Zitat von Soma

I already had understood what you had done.

Just thought the network environment to be different, (as I wrote above, since that's how it's described on the docker-compose docs )

With those examples, it's pretty much straight forward.

And no need to edit subdomain.confs from app to LAN IP,

Nice one.

Alles anzeigen

That's also partially why I'm so confused w/ th eother posters problem.. because I think he said he had other containers routing through swag w/o issue, but he couldn't get nextcloud to work. Then you were explaining about modifying the .conf files, etc...

I'm sure what you were saying was right, That's just not stuff I've ever needed to do w/ this approach and thus why I was completely lost..

Zitat von Soma

Yes, but kept (re)using old volumes with failed attempts on Nextcloud.

So, too many errors.

Starting from scratch has given a better picture of where it fails and how to solve the issues.

Since I don't use the method you described, I told him/her to edit the conf (because I know it will work)

After all is running and configured, it will be easy to modify the YMLs to use your method (if required).

Then all it takes it to delete the modified confs, copy a new sample and restart SWAG.

When I rotate home for Christmas, I'll take the plunge and switch (finally) my configuration.

Only catch I'll have are the services running on a different Pi (hence, different host).

I'll still need to have those confs edited by hand,

Alles anzeigen

And that was really my main goal. Clearly people were still struggling with it (given this thread's been going on a couple years).. so I was trying to make it more or less "cut and paste simple".. other than the config.php there's really no files, etc. that have to be edited.. but you have to do that anyway.

Soma

I was looking at Starbuck1973 router settings (pic in post 944)... Only difference I can tell in his and mine.. is mine is "BOTH" (TCP/UDP).. and his is TCP only... would that be a reason this is failing?

On networks, you can just create the network in the command line. For instance: docker network create swag-net and then in every container yml you want on that one network include network_mode: swag-net

https://docs.docker.com/network/bridge/