[BUG] Certificates do not get deployed if `SUBDOMAINS` is left blank

[ericswpark]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When using the SWAG container, after fetching the certificates a hook at /config/etc/letsencrypt/renewal-hooks/deploy/10-default is run. However, this hook crashes because the symlink at /config/keys/letsencrypt is owned by root:root, and thus the certificates fail to be generated in the format that nginx requires properly. incorrect and points to the wrong folder name, see comment below!

Expected Behavior

I'm not sure whether this symlink is supposed to be created as root:root instead of the PUID:PGID supplied to the container as environment variables. However, the container runs as root, so there must be some step missing where it sets the correct permissions.

Use the proper location for the symlink

Steps To Reproduce

1. Deploy container
2. Observe error in container logs

Environment

- OS: TrueNAS SCALE
- How docker service was installed: built-in

CPU architecture

x86-64

Docker creation

URL=example.com
VALIDATION=dns
CERTPROVIDER=zerossl
DNSPLUGIN=cloudflare
PROPAGATION=60
EMAIL=example@example.com
ONLY_SUBDOMAINS=true
SUBDOMAINS=
EXTRA_DOMAINS=*.host.example.com
STAGING=false
DOCKER_MODS=linuxserver/mods:swag-dashboard|linuxserver/mods:swag-dbip
MAXMINDDB_LICENSE_KEY=<redacted>
MAXMINDDB_USER_ID=<redacted>
PUID=568 (apps user for Docker containers in TrueNAS)
PGID=568

Container logs

2026-05-30 19:34:10.979319+00:00Renewing an existing certificate for example.com and *.example.com
2026-05-30 19:34:14.949933+00:00Waiting 60 seconds for DNS changes to propagate
2026-05-30 19:35:38.009062+00:00Hook 'deploy-hook' reported error code 1
2026-05-30 19:35:38.009149+00:00Hook 'deploy-hook' ran with error output:
2026-05-30 19:35:38.009162+00:00/config/etc/letsencrypt/renewal-hooks/deploy/10-default: line 4: cd: /config/keys/letsencrypt: No such file or directory
2026-05-30 19:35:38.022117+00:002026-05-30T19:35:38.022117295Z
2026-05-30 19:35:38.022178+00:00Successfully received certificate.
2026-05-30 19:35:38.022215+00:00Certificate is saved at: /config/etc/letsencrypt/live/example.com/fullchain.pem
2026-05-30 19:35:38.022231+00:00Key is saved at:         /config/etc/letsencrypt/live/example.com/privkey.pem
2026-05-30 19:35:38.022245+00:00This certificate expires on 2026-08-28.
2026-05-30 19:35:38.022258+00:00These files will be updated when the certificate renews.
2026-05-30 19:35:38.022285+00:00NEXT STEPS:
2026-05-30 19:35:38.022301+00:00- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.
2026-05-30 19:35:38.024347+00:002026-05-30T19:35:38.024347437Z
2026-05-30 19:35:38.024419+00:00- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2026-05-30 19:35:38.024438+00:00If you like Certbot, please consider supporting our work by:
2026-05-30 19:35:38.024452+00:00* Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
2026-05-30 19:35:38.024466+00:00* Donating to EFF:                    https://eff.org/donate-le
2026-05-30 19:35:38.024491+00:00- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2026-05-30 19:35:38.247860+00:00ERROR: Cert does not exist! Please see the validation error above. Make sure you entered correct credentials into the /config/dns-conf/cloudflare.ini file.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[ericswpark]

Oops, that wasn't the issue. Turns out the symlink created points to .example.com:

root@swag:/config/keys# ls -al
lrwxrwxrwx  1 abc abc   39 May 30 15:45 letsencrypt -> ../etc/letsencrypt/live/.example.com

But the live key generated does not have the preceding period:

root@swag:/config/etc/letsencrypt/live# ls
README  example.com

The issue was because I left SUBDOMAINS blank and supplied a wildcard subdomain in EXTRA_DOMAINS. I was able to temporarily work around this issue by supplying a dummy subdomain that does point to this server in SUBDOMAINS; however, I think that it should also be possible to have a certificate that only has the wildcard subdomains? (Unless a subdomain must be required for SSL certs but I've never heard of this requirement)

Please feel free to close this issue if the assessment is wrong or if SWAG is working as intended.

[aptalca]

however, I think that it should also be possible to have a certificate that only has the wildcard subdomains?

It is possible, but since you didn't fill out the template fully, it's anybody's guess why it didn't work

[ericswpark]

@aptalca I've edited the original post to add the environment variables used. The temporary fix was doing something like:

SUBDOMAINS=host

(edit: the line above originally said host.example.com but that is incorrect, just a mistake when copying the config over)

even if I do not intend to actually serve requests from that subdomain.

[aptalca]

I suggest you read the readme and pay attention to the env vars.

What you did may seem like it works but it is certainly not the correct way to set this container up.

[ericswpark]

@aptalca I've read through the README but still do not see the misconfiguration. SUBDOMAINS is marked as an optional variable so it doesn't make sense for the container to break if it is not supplied. If it shouldn't be optional, then the container should warn me and the README should state as such.

Or is your intended solution supplying SUBDOMAINS as wildcard? Wouldn't that generate a root-level wildcard (i.e., *.example.com), which I do not want? As supplied in EXTRA_DOMAINS, I want this cert to provide just *.host.example.com.

[aptalca]

it doesn't make sense for the container to break if it is not supplied

It doesn't break, but you also set ONLY_SUBDOMAINS=true so you're telling it to process the SUBDOMAINS values anyway, hence the symlink pointing to .example.com, which contains a blank subdomain.

Also, values in SUBDOMAINS get the URL appended one by one (unless it's wildcard exactly) so your setting of SUBDOMAINS=host.example.com is incorrect. It would attempt to cover host.example.com.example.com

If the only address you want covered is *.host.example.com, then you can set:

URL=host.example.com
SUBDOMAINS=wildcard
ONLY_SUBDOMAINS=true

[ericswpark]

@aptalca thank you for the clarification. And yeah, I made a mistake copying my configuration over to this issue thread; I am using SUBDOMAINS=host as the workaround, not including the domain.

I wasn't aware that the URL parameter could include subdomains like host.example.com, and the given configuration makes sense.

I think it might be a good idea if the container could warn the user if they have specified ONLY_SUBDOMAINS=true but have left SUBDOMAINS blank (or omitted it entirely). But feel free to close the issue if that is not relevant.