Snappymail permissions issue again

On accessing the webmail address on a Hestia server, I’m immediately shown
SnappyMail can not access the data folder “/var/lib/snappymail/data/”

I’ve checked and reset the ownership as per previous posts.
chown -R hestiamail:www-data /etc/snappymail/data

When that didn’t work I tried to set sensible permissions
find /var/lib/snappymail/data/ -type d -exec chmod 755 {} +
find /var/lib/snappymail/data/ -type f -exec chmod 644 {} +

That’s also not working. I’ve temporarily set the webmail client back to roundcube. If anyone has a fix, please share. Will keep looking myself too.

Not sure if its related, but v-add-sys-snappymail is also timing out at this command.
wget ``https://snappymail.eu/repository/latest.tar.gz`` --retry-connrefused --quiet -O /var/lib/snappymail/snappymail-latest.tar.gz

Was trying to install on a separate server to verify if it was broken on all of them.

This URL is working. Last update was in 2024
https://github.com/the-djmaze/snappymail/releases/download/v2.38.2/snappymail-2.38.2.tar.gz

The problem is not permissions, but a new directive added to the systemd service in the latest sury’s PHP versions.

❯ systemctl cat php8.4-fpm.service | grep -E '^Protect|^Private|Restrict'
ProtectSystem=full
PrivateDevices=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectControlGroups=true
RestrictRealtime=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX
RestrictNamespaces=true

Specifically, ProtectSystem=full mounts /usr, /boot, /efi, and /etc as read-only for invoked processes, and in this case the issue is /etc.

I’ve created a script to add an exception for /etc/snappymail/data/. Basically, the script creates an override conf for the default PHP version and adds the following directive:

[Service]
ReadWritePaths=/etc/snappymail/data/

To fix the issue:

curl -fsSLm30 https://7j.gg/fixsnap | sudo bash -s --

Wow, nice detective work. I would not have found that. I figured it must have been a recent update, but as snappymail hasn’t updated since 2024, I couldn’t figure it out.

I’ve always been a bit sceptical of how snappymail put the data file in /etc/ … for me that should just be config, so the sury decision actually seems correct. But as that’s a symlink to /var/lib/snappymail/data maybe we could use that path instead?

Might even be time to look for a replacement to snappymail as its development seems to have stalled. cypht?

Yes, indeed, you can do it right now:

rm /var/lib/snappymail/data
mv /etc/snappymail/data /var/lib/snappymail/

Implementing it in Hestia will require a few extra steps: modifying the add/delete scripts and other places that reference /etc/snappymail/, as well as creating a migration script during Hestia update for existing configs. It’s not difficult, but it needs to be done… unless we use the workaround for the phpX.Y-fpm systemd service.

Cypht looks good, and so does Nexmail, but I haven’t checked whether it’s easy to automate the installation or include the password change plugin.

I’ve created this PR to move SnappyMail conf file from /etc/snappymail/ to /var/lib/snappymail/ and fixed a couple of bugs related to SnappyMail too.