Caddy don't start if not run as default user [systemd]

Help
1

Hi,

I try to run caddy service with a different user with following configuration:

  systemd.services.caddy.serviceConfig.ProtectHome = lib.mkForce "read-only";
  services.caddy = {
    enable = true;
    extraConfig =
      ''
        dev.localhost {
          root * /home/pascal/Data/_DEV/
          file_server browse
        }
      '';
    user = "pascal";  # without this option, caddy starts with no issue
  };

But caddy won’t start, and I’ve this error message:

systemd[21189]: caddy.service: Failed to execute /nix/store/s7z78i2w55c78ixq3gpswlh599i7xmh8-caddy-2.6.2/bin/caddy: Resource temporarily unavailable
systemd[21189]: caddy.service: Failed at step EXEC spawning /nix/store/s7z78i2w55c78ixq3gpswlh599i7xmh8-caddy-2.6.2/bin/caddy: Resource temporarily unavailable
systemd[1]: caddy.service: Control process exited, code=exited, status=203/EXEC

Any help appreciated :slight_smile:

2

We have had the same question with nginx as well. The short answer - don’t do it.

Caddy is supposed to run with a user that only has access to exactly the files it needs to process and nothing else. Exposing (parts of) your home directory is a really bad idea.

The module is locked down this way and you will have to open up a few things to make it work. Instead, move whatever files it needs to a place it always has access to.

1 Like
3

To clarify one small point: the issue isn’t running as another user, the issue is running as a regular account instead of a dedicated system account I believe. Don’t try to run system level systemd services without system users.

1 Like
4

Thx aanderse for clarifying this point.

5

A reorganization of my files solved my issue. Thx.

1 Like
6

why not

  systemd.services.caddy.serviceConfig = {
    ProtectHome = lib.mkForce "tmpfs";
    BindReadOnlyPaths = "/home/pascal/Data/_DEV/";
  };
  services.caddy = {
      enable = true;
      extraConfig =
        ''
          dev.localhost {
            root * /home/pascal/Data/_DEV/
            file_server browse
          }
        '';
    };

?

7

This works today… but it won’t work the next week after 13 more systemd hardening rules are applied to our module. For better or worse, depending on your perspective, NixOS is a very opinionated distro with respect to systemd configuration.

To be clear I’m not aware of any concrete plans to add more systemd hardening to caddy module and I was using sarcasm to make my point that you’re fighting an uphill battle against NixOS maintainers if you do what you have suggested.

1 Like
8

Hi there, it seems I’ve found the reason and a solution. As a heavy user of Caddy myself, I’ve encountered this issue multiple times on several servers before, and previously couldn’t pinpoint the cause or fix it. The workaround I used back then was to modify /lib/systemd/system/caddy.service to specify running as the root user.

Today, I’ve noticed it might be related to the inconsistency between the UID and GID of the caddy user in /etc/passwd. Upon observing the servers where the issue occurred, I found that the IDs of the caddy user and group were different. Adjusting this resolved the problem.

for example:

$ grep caddy /etc/passwd
caddy:x:999:998:Caddy web server:/var/lib/caddy:/usr/sbin/nologin

then I change to:

caddy:x:999:999:Caddy web server:/var/lib/caddy:/usr/sbin/nologin

Of course, make sure the modified UID, GID don’t conflict with existing users and groups.

it solved the problem.