How to change the folder that host all the certificates?

How to change the folder that hosts all the certificates?

1 Like

OK, I follow the guide and it’s still not working.

  1. I’m using Ubunto 20
  2. I set up $XDG_DATA_HOME inside: /etc/environment
  3. I reboot the server
  4. I enter a domain under the server and it’s still going to the old folder and nothing is happening in the new folder.

What I’m doing wrong?

You didn’t fill out the help topic template. Please do so. It’s unclear how you’re running Caddy, so it’s difficult to suggest a specific solution.

You can find the template by clicking on New Topic, and choose the Help category. The text area will be filled in with the template. You can copy it and fill it out as a reply in this topic.

Please also explain why you need to change the storage location.

1. Caddy version (caddy version):


2. How I run Caddy:

Using this install guide:

Did it:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf '' | sudo tee /etc/apt/trusted.gpg.d/caddy-stable.asc
curl -1sLf '' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

a. System environment:

Ubuntu 20

b. Command:

sudo systemctl reload caddy

d. My complete Caddyfile or JSON config:

    on_demand_tls {


tls {

reverse_proxy 77.777.7.777 {
    header_down -server
    header_down -proxy-cache
    header_down -proxy-cache-tag

3. The problem I’m having:

I’m trying to replace the data folder to AWS EFS folder.
I’m going to run multiple servers being AWS LB so I need all of them will use the same disk with all the SSLs.

4. Error messages and/or full log output:

No errors. It’s just don’t working with the folder I set up in the variable $XDG_DATA_HOME

5. What I already tried:

  1. I set up $XDG_DATA_HOME inside: /etc/environment
  2. I reboot the server
  3. I enter a domain under the server and it’s still going to the old folder and nothing is happening in the new folder.

Hope it help :slight_smile:

While in your server, run env and make sure your environment variable is actually set.

Yep, already done.
I can see it.
Maybe you know if there is a Caddy commend that tells me what is the Caddy data folder? it will help to see if he see that setting.

Does it output the folder it uses in logs when starting?

Also please show the env output with XDG_DATA_HOME

@job_noam ,

caddy environ

Prints the environment as seen by caddy, then exits. Can be useful when debugging init systems or process manager units like systemd.

@francislavoie , @matt a cli command to display current setup would be useful. That would include directories / storage adapters used etc. is it a viable option to implement? I.e. to answer simple questions like this “Where is caddy storing certs?”

1 Like

Yes, I see that:


But still, when I load a new domain and I get the SSL I don’t see it in the new folder. Strange.

When Caddy fetches SSL certs for the domain, it writes logs. Have you explored them?

1 Like

Also, what is the “old folder”?

Thanks for filling out the template @job_noam!

So, seeing as you’re running as a systemd service, probably the easiest way for you to change the storage location is to use the storage global option:

	storage file_system {
		root /etc/caddy_efs/caddy

Running caddy environ as your current user will show the environment for your current user, not the user under which Caddy will actually run, i.e. the caddy user, as per the systemd service config.

caddy run has the --environ flag. The default systemd service file uses that option. Check Caddy’s logs to see its output. It’s the same output as caddy environ, but outputs it first thing every time Caddy starts up as a systemd service.

Further on that same page in the docs, you’ll see you can use systemctl edit caddy to override some settings. You may use that to set environment variables just for the caddy systemd service.


Yep, the logs should show which storage is configured and also the environ subcommand and --environ flag will tell you what you need to know.

1 Like

It sound like good solution but when I add this setting to my global options it’s Caddy not working and don’t write any log.
This is my full Caddyfile that doesn’t work now:

        storage file_system {
                root /etc/caddy_efs/caddy
        log global_log {
            output file /etc/caddy/log/requests.log {
                roll_size 1gb
                roll_keep 5
                roll_keep_for 720h


tls {

reverse_proxy {
    header_down -server
    header_down -proxy-cache
    header_down -proxy-cache-tag

If I remove the new storage setting it’s working.

Are you sure there’s no logs? Caddy writes to stdout, which you can see by running journalctl -u caddy --no-pager | less, as explained in the docs:

The caddy user possibly doesn’t have permissions to write to that location. Make sure that permissions are properly configured.


As always you’re right :slight_smile:
So this is the log:

Aug 14 10:41:37 ip-172-30-3-91 caddy[433]: {"level":"debug","ts":1628937697.6378136,"logger":"http.stdlib","msg":"http: TLS handshake error from failed storage check: open /etc/caddy_efs/caddy/rw_test_9173474569021134360: read-only file system - storage is probably misconfigured"}
Aug 14 10:41:37 ip-172-30-3-91 caddy[433]: 2021-08-14 10:41:37.637847084 +0000 UTC m=+91.284299863 write error: can't rename log file: rename /etc/caddy/log/requests.log /etc/caddy/log/requests-2021-08-14T10-41-37.637.log: read-only file system

And I don’t understand why I’m getting it because I already set up the right permission:

sudo chmod -R 777 /etc/caddy_efs
sudo chown -R www-data:root /etc/caddy_efs
sudo chmod -R 777 /etc/caddy_efs/caddy
sudo chown -R www-data:root /etc/caddy_efs/caddy

Caddy runs as the caddy user, not as www-data. It is in the www-data group though.

I’m not sure I can help much with system permission issues. Caddy’s just using Golang syscalls for IO. You’ll just need to figure out the right combination of permissions.

I’d recommend not using 777 permissions though, because this will contain your server’s private keys. Best to keep those away from view of other applications that don’t need them.

OK thanks for the help Franc :slight_smile:

Maybe someone else can help me with the Ubuntu permission related to Caddy?
I tried everything I found online, but still, nothing is working.


Would make sense to share what you tried exactly.

One possible way to solve it would be to give maximum permission 777 and make it owned by the caddy user. Make sure it works. Then start decreasing permissions one by one, bit by bit, and/or changing folder/file ownership, until you figure out what permission is causing the issue when absent.

From the Caddy site, I’d expect some command available to make Caddy test its configuration and report any directory access issues.

As a general rule, not failing and falling back to default folder should be considered bad UX. If Caddy is instructed to use a particular directory, and if it cannot do so at the startup time, it should error and stop. Then it’s obvious there is a permission issue, and the user does not have to “guess” what was the issue.

The sooner an issue can be discovered, and the less research the user has to do to understand the issue, the better.

Whatever makes users guess is bad UX.