Repository navigation
[BUG] Certificates do not get deployed if SUBDOMAINS is left blank #611
Description
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 incorrect and points to the wrong folder name, see comment below!root:root, and thus the certificates fail to be generated in the format that nginx requires properly.
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
- Deploy container
- Observe error in container logs
Environment
- OS: TrueNAS SCALE
- How docker service was installed: built-inCPU 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=568Container 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.
Activity
github-actions commentedon May 30, 2026
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
ericswpark commentedon May 31, 2026
Oops, that wasn't the issue. Turns out the symlink created points to
.example.com:But the live key generated does not have the preceding period:
The issue was because I left
SUBDOMAINSblank and supplied a wildcard subdomain inEXTRA_DOMAINS. I was able to temporarily work around this issue by supplying a dummy subdomain that does point to this server inSUBDOMAINS; 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.
[-][BUG] Certificates fail to be deployed due to permissions problems[/-][+][BUG] Certificates do not get deployed if SUBDOMAINS is left blank[/+][-][BUG] Certificates do not get deployed if SUBDOMAINS is left blank[/-][+][BUG] Certificates do not get deployed if `SUBDOMAINS` is left blank[/+]aptalca commentedon May 31, 2026
It is possible, but since you didn't fill out the template fully, it's anybody's guess why it didn't work
ericswpark commentedon May 31, 2026
@aptalca I've edited the original post to add the environment variables used. The temporary fix was doing something like:
(edit: the line above originally said
host.example.combut 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 commentedon May 31, 2026
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 commentedon May 31, 2026
@aptalca I've read through the README but still do not see the misconfiguration.
SUBDOMAINSis 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
SUBDOMAINSaswildcard? Wouldn't that generate a root-level wildcard (i.e.,*.example.com), which I do not want? As supplied inEXTRA_DOMAINS, I want this cert to provide just*.host.example.com.aptalca commentedon May 31, 2026
It doesn't break, but you also set
ONLY_SUBDOMAINS=trueso 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
wildcardexactly) so your setting ofSUBDOMAINS=host.example.comis incorrect. It would attempt to coverhost.example.com.example.comIf the only address you want covered is
*.host.example.com, then you can set:ericswpark commentedon May 31, 2026
@aptalca thank you for the clarification. And yeah, I made a mistake copying my configuration over to this issue thread; I am using
SUBDOMAINS=hostas the workaround, not including the domain.I wasn't aware that the
URLparameter could include subdomains likehost.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=truebut have leftSUBDOMAINSblank (or omitted it entirely). But feel free to close the issue if that is not relevant.LinuxServer-CI commentedon Jul 1, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
ericswpark commentedon Jul 2, 2026
This is still relevant, please don't mark as stale.
LinuxServer-CI commentedon Aug 2, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.