[Debian 13] Cyrus SASL Authentication Server won't start

I am conducting tests on Debian 13.2.0. So far Virtualmin 7 was able to install and run except Cyrus SASL Authentication Server. Investigating this issue I found the fix must be done in this file /etc/default/saslauthd.

This is the default value
OPTIONS=“-c -m /var/spool/postfix/var/run/saslauthd -r”

By changing it I was able to start the server
OPTIONS=“-c -m /run/saslauthd -r”

A few comments related to this change. Here are the advantages of the original variant (OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"):

  1. Chroot for Postfix – theoretically safer: if something goes wrong with Postfix, SASL is isolated.
  2. Worked fine on older Debian versions, for setups needing strict process separation.

Disadvantages:

  1. Incompatible with systemd on Debian 13 – the PID file is not where systemd expects it → timeout and “failed” service status.
  2. Harder to maintain – the socket inside chroot is harder to access for testing or debugging.
  3. More complicated Postfix configuration – requires extra chroot adjustments, group membership, and permissions.

Personal opinion: On Debian 13, the modern and simple variant (without chroot, using /run/saslauthd) is more stable, easier to maintain, and fully compatible with systemd. The original setup worked in the past but causes unnecessary issues on modern systems.

We can still use the original variant, but several steps are needed:

  1. Keep saslauthd running in the Postfix chroot:
    OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

  2. Create the PID directory that systemd expects:
    sudo mkdir -p /run/saslauthd
    sudo chown root:sasl /run/saslauthd
    sudo chmod 755 /run/saslauthd

  3. Create a symbolic link between the chroot and the systemd PID location:
    sudo ln -s /var/spool/postfix/var/run/saslauthd/mux /run/saslauthd/mux

  4. Optionally, modify the systemd unit to point to the correct PID file:
    sudo systemctl edit saslauthd
    and add
    [Service]
    PIDFile=/run/saslauthd/saslauthd.pid

  5. Reload systemd and restart saslauthd:
    sudo systemctl daemon-reexec
    sudo systemctl restart saslauthd
    sudo systemctl status saslauthd

Pros:

  • Maintains Postfix chroot isolation
  • Works on Debian 13 without systemd timeouts

Cons:

  • More complex than the modern /run/saslauthd approach
  • Requires maintaining the link and PID directory
  • Harder to test and debug

This allows the original setup to function on modern Debian while preserving chroot security.

Investigating deeper, there is no such user named ‘sasl’. This command was not solving the issue and it is not creating the user:
virtualmin-config-system -i SASL

Where did you get the idea there is supposed to be a sasl user?

Also, we don’t create random users.

Also, it looks like your post was at least partially generated by an LLM. I don’t mind that so much if it’s been validated to be correct, but it seems like it’s maybe leading you astray a little bit. We’ve talked about the problem with sasl on Debian and newer Ubuntu versions here quite a few times, and I’m pretty sure Ilia’s prerelease version works around this packaging bug on Debian (and it is a bug in their packaging, not really anything we’re doing wrong…they changed Postfix behavior without changing things that interact with it).

root@server:/run# ls -lah /var/spool/postfix/var/run/
total 12K
drwxr-xr-x 3 root root 4.0K Dec 25 16:52 .
drwxr-xr-x 3 root root 4.0K Dec 25 16:52 ..
drwxr-xr-x 2 root sasl 4.0K Dec 25 18:08 saslauthd

It is no secret that I used an LLM in my investigation. I have also read all the posts related to SASL issues in Ubuntu and Debian. None of the solutions worked in my case. I am using Debian 13.2.0 with the Virtualmin version downloaded from the official website, and I have not made any other modifications. I just wanted to show how I solved the problem by modifying the SASL options.

That’s group, not user.

If you see an actual name, and not a number, in the output of ls, it means the entity exists. If there were nosasl group, you’d see a number there.

From what I can tell looking at the source, we’re treating Debian 13 the same as a new Ubuntu versions: Fix SASL on Debian 13 · virtualmin/Virtualmin-Config@b1c2c9c · GitHub

Which seems to do the right thing for the changed path: Virtualmin-Config/lib/Virtualmin/Config/Plugin/SASL.pm at 81cc7b446216d7926f2c9d5c7f6e8ce4416284b1 · virtualmin/Virtualmin-Config · GitHub

So, do you have that file? (/etc/systemd/system/saslauthd.service.d/override.conf)

Thank you Joe. This is what Virtualmin installed on my system

      $saslinit = "/etc/init.d/saslauthd";
      # Ubuntu 24.04 uses native saslauthd.service, so we need
      # to fix PIDFile location because chroot Postfix expects
      # it to be in /var/spool/postfix/var/run/saslauthd
      my $os_ver = $gconfig{'real_os_version'};
      if ($os_ver && $os_ver =~ /^(24)/) {
        my $systemd_saslauthd_override_path = "/etc/systemd/system/saslauthd.service.d";
        $self->logsystem("mkdir -p -m 755 $systemd_saslauthd_override_path")
          if (!-d $systemd_saslauthd_override_path);
        write_file_contents($systemd_saslauthd_override_path . "/override.conf",
          "[Service]\n".
          "PIDFile=/var/spool/postfix/var/run/saslauthd/saslauthd.pid\n");
        $self->logsystem("systemctl daemon-reload");
        $self->logsystem("systemctl restart saslauthd.service");
      }

It seems the change from the August 22 is missing from the official Virtualmin package.

The file override.conf is missing. Using the whole file code from GitHub, the virtualmin-config command ran very quickly. The service is running and this file was created.

Please note that I installed Debian 13 in a virtual machine, then ran the command from the Virtualmin website. I didn’t make any other changes.

In conclusion, the problem I reported was resolved in August, but what Virtualmin installed now in December did not include the solution.

Yes, we weren’t ready to provide a new Virtualmin Config for compatibility and some other reasons.

It won’t happen again. Sorry about that! The upcoming Virtualmin 8 will fix this issue!

The solution to your problem is simple though:

wget -O /tmp/virtualmin-config.deb https://download.virtualmin.com/virtualmin-config-latest.deb && sudo apt install /tmp/virtualmin-config.deb
virtualmin-config-system -i SASL

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.