Swag certificate not renewed

Nefertiti · 22. März 2024

I just realized my automatic renewal for the swag certificate failed, just wondering if because I move my docker directory out of var/lib. So now how to fix it?

Code

GID/UID
───────────────────────────────────────
User UID:    1000
User GID:    100
───────────────────────────────────────
using keys found in /config/keys
Variables set:
      
0
PGID=100
TZ=America/Los_Angeles
URL=xxxxxxxx.duckdns.org
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=duckdns
CERTPROVIDER=
DNSPLUGIN=cloudflare
EMAIL=xxxxxxx@gmail.com
STAGING=false
the resulting certificate will only cover the subdomains due to a limitation of duckdns, so it is advised to set the root location to use www.subdomain.duckdns.org
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for xxxxxxxxxx.duckdns.org will be requested
E-mail address entered: xxxxxxxx@gmail.com
dns validation via duckdns plugin is selected
Certificate exists; parameters unchanged; starting nginx
The cert is either expired or it expires within the next day. Attempting to renew. This could take up to 10 minutes.
<------------------------------------------------->
<------------------------------------------------->
cronjob running on Fri Mar 22 12:58:06 PDT 2024
Running certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/xxxxxxxx.duckdns.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewal configuration file /etc/letsencrypt/renewal/le-fou-volant.duckdns.org.conf is broken.
The error was: expected /etc/letsencrypt/live/le-fou-volant.duckdns.org/cert.pem to be a symlink
      
.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
No renewals were attempted.
Additionally, the following renewal configurations were invalid: 
  /etc/letsencrypt/renewal/xxxxxxxx.duckdns.org.conf (parsefail)

Alles anzeigen

Compose settings at the section

Leave blank to use a custom /etc/docker/daemon.json

I use to have this

Code

{
    "data-root": "/var/lib/docker",
    "runtimes": {
        "nvidia": {
            "args": [],
            "path": "nvidia-container-runtime"
        }
    }
}

Modified it for

Code

{
    "data-root": "/srv/dev-disk-by-uuid-9cd27ed0-ef9a-4346-ae1e-5e835ba05832/Media2/docker",
    "runtimes": {
        "nvidia": {
            "args": [],
            "path": "nvidia-container-runtime"
        }
    }
}

Not sure if it is the reason since the appData for the swag has not been changed?

Soma · 22. März 2024

Bring down the SWAG stack.

Pull and bring it up.

If it doesn't solve it, bring down, save your proxy confs and delete the swag config folder.

Put it up again. It will recreate the cert.

Redo your proxy confs.

KM0201 · 22. März 2024

Zitat von Soma

Bring down the SWAG stack.
Pull and bring it up.
If it doesn't solve it, bring down, save your proxy confs and delete the swag config folder.
Put it up again. It will recreate the cert.
Redo your proxy confs.

Isn't there a "keys" folder inside the swag config folder?.. I don't ue swag anynmore, but i seem to remember that. Seems you could just delete that folder and redeploy.

Soma · 22. März 2024

Zitat von KM0201

Isn't there a "keys" folder inside the swag config folder?.. I don't ue swag anynmore, but i seem to remember that. Seems you could just delete that folder and redeploy.

Yes. Might work also.

Wrote this from memory and I prefer to do "clean slate" to avoid any leftovers.

olduser · 22. März 2024

Zitat von KM0201

Isn't there a "keys" folder inside the swag config folder?

That should work.

I don't use swag anymore either but, it's worth noting that it does find the correct link however, it expects a symlink. When you used 'cp' to move everything, did you use -L, --dereference, follow symlinks? Regardless, it's a pain that swag makes those symbolic because a few containers I've used, ie. "mailu", will look there by default but will not work with symlinks.

Nefertiti · 22. März 2024

Zitat von Soma

Bring down the SWAG stack.
Pull and bring it up.
If it doesn't solve it, bring down, save your proxy confs and delete the swag config folder.
Put it up again. It will recreate the cert.
Redo your proxy confs.

It did works and I forgot; I also moved the AppData on the same disk without removing the original, did not see any change for a while

just question about the subdomain.conf

the original line

set $upstream_app emby;

does not work but

set $upstream_app 192.168.50.50;

which is my local IP is working?

Soma · 22. März 2024

Zitat von Nefertiti

set $upstream_app emby;
does not work but
set $upstream_app 192.168.50.50;
which is my local IP is working?

The syntax of the question is a bit strange.

If you are asking why it work's with IP and not by name means that your emby container isn't running on the SWAG network and you need to call it by the server IP.

To avoid this you need to edit the emby container to use the SWAG net.

For eg, I use the SWAG container with this network:

Code

#  This section creates a custom docker bridge network called swagnet. 
#  The driver line makes sure it is a bridge that can be used by other containers
networks:
  default:
    name: swagnet
    driver: bridge

And on all other containers:

Code

#This section attaches the container to the custom network created by the SWAG container.
networks:
  default:
    name: swagnet
    external: true

KM0201 · 22. März 2024

Zitat von Soma
The syntax of the question is a bit strange.
If you are asking why it work's with IP and not by name means that your emby container isn't running on the SWAG network and you need to call it by the server IP.

To avoid this you need to edit the emby container to use the SWAG net.

For eg, I use the SWAG container with this network:
Code
#  This section creates a custom docker bridge network called swagnet. 
#  The driver line makes sure it is a bridge that can be used by other containers
networks:
  default:
    name: swagnet
    driver: bridge
And on all other containers:
Code
#This section attaches the container to the custom network created by the SWAG container.
networks:
  default:
    name: swagnet
    external: true
Alles anzeigen

Another way to do that, if you already have swag running... (below assumes your swag container is named "swag")

Code

docker inspect swag | grep NetworkMode

example.. this is my jellyfin container...

Code

root@openmediavault:~# docker inspect jellyfin | grep NetworkMode
            "NetworkMode": "jellyfin_default",
root@openmediavault:~#

so, assuming you used "swag" as your container name, in all likelihood your swag network mode is "swag_default"

Now, just add the "network_mode" line to your emby stack.

Code

---
version: "2.1"
services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    network_mode: swag_default
    environment:

Then redeploy emby..

olduser · 22. März 2024

Zitat von KM0201

assuming you used "swag" as your container name, in all likelihood your swag network mode is "swag_default"

Why would it be "swag_default"?

FWIW, if you know you're putting related containers together, you should create a network yourself aside from the default.

Code

sudo docker network create "media" --subnet "172.18.0.0/16" --gateway "172.18.0.1"

Nefertiti · 22. März 2024

Zitat von KM0201
Another way to do that, if you already have swag running... (below assumes your swag container is named "swag")
Code
docker inspect swag | grep NetworkMode
example.. this is my jellyfin container...
Code
root@openmediavault:~# docker inspect jellyfin | grep NetworkMode
            "NetworkMode": "jellyfin_default",
root@openmediavault:~# 
so, assuming you used "swag" as your container name, in all likelihood your swag network mode is "swag_default"

Now, just add the "network_mode" line to your emby stack.
Code
---
version: "2.1"
services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    network_mode: swag_default
    environment:
Then redeploy emby..
Alles anzeigen

I picked this method above for the set $upstream_app emby; (Working ) if you guys thinking a better way let me know.

KM0201 · 23. März 2024

Zitat von olduser
Why would it be "swag_default"?

FWIW, if you know you're putting related containers together, you should create a network yourself aside from the default.
Code
sudo docker network create "media" --subnet "172.18.0.0/16" --gateway "172.18.0.1"

Because a lot of folks in the past setup services with portainer stacks. With Stacks, if you don't declare a network name, a network is created, and it's naming scheme is "container-name_default"

I was not suggesting this is the only way, just saying this is why on many older/migrated installs, it's not uncommon for "swag_default" to be swags network name

Nefertiti · 24. März 2024

Got a problem with plex
network_mode: host able to reach reach ip:32400

network_mode: swag_default give me white page

jellyfin same white page working with IP:8196 and network_mode: host but can reach it remote with network_mode: swag_default but not both!

~~and for nexcloud unable to reach it either~~

No issue with Emby or navidrome both working local and remote

EDIT:

working Nextcloud

Swag certificate not renewed

Jetzt mitmachen!

Ähnliche Themen

No external access with duckdns and Nginx Proxy manager

swag and https

SWAG Docker certbot: command not found

Making data externally available OpenVPN?