Issue Description
Since a couple of days, can’t tell exactly since when the automated task ^Perform store maintenance operations’ fails with reason ‘Filesystem error (store.filesystem-error): reason = Permission denied (os error 13), causedBy = crates/store/src/dispatch/blob.rs:221, causedBy = crates/store/src/write/blob.rs:141, causedBy = crates/services/src/task_manager/maintenance.rs:273’
Sound like a folder permission issue, but installation didn’t let me set anything so I’d say it’s pretty default.
Expected Behavior
Works.
Actual Behavior
Does not work.
Relevant Log Output
None.
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
PostgreSQL
Blob Storage
Filesystem
Search Engine
PostgreSQL
Directory Backend
Internal
Additional Context
Stalwart 0.16.11
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
Let me look into the blob filesystem error and maintenance task to understand what’s happening.
This is a clear filesystem permissions issue. The Stalwart process is trying to delete blob files during maintenance (the delete_blob operation calls fs::remove_file) and getting Permission denied (os error 13). This means the OS user running the Stalwart process does not have write permission on the blob storage directory or its files.
Here’s what to check and fix:
-
Find your blob storage path – look in the WebUI under Settings > Storage > Blob Store, or check your configuration. It is typically something like /opt/stalwart-mail/data/blobs or similar.
-
Check the owning user of the Stalwart process:
ps aux | grep stalwart
-
Check permissions on the blob directory:
ls -la /path/to/blob/store
-
Fix ownership so the Stalwart process user owns (or has write access to) that directory and all files within it:
chown -R stalwart:stalwart /path/to/blob/store
# or whatever user your process runs as
chmod -R u+rwX /path/to/blob/store
This is the most likely cause – something (a manual copy, a backup restore, a package update, or a root-run command) changed ownership or permissions on files under the blob store path without the Stalwart process user being the owner. The maintenance task tries to delete expired/unlinked blobs, hits files it cannot remove, and fails with os error 13.
You can verify the exact path configured for blob storage in the WebUI under Settings > Storage > Blob Store (the path field).
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Blob store path is /var/opt/stalwart
ls -al /var/opt
drwxr-xr-x. 258 stalwart stalwart 8192 9. Dez 2025 stalwart
chown -R stalwart:stalwart /var/opt/stalwart
chmod -R u+rwX /var/opt/stalwart
Those command did the trick, but why? Permissions are still the same.
Subfolders have all been created by Stalwart itself, so why should they have wrong permissions?
Sure, the parent folder permissions are the same, but whatever it was trying to delete inside was different, and the recursive flag fixed it.
Did you happen to list the whole directory tree beforehand?
That EACCES came from the filesystem blob backend deleting or rewriting a file inside the blob tree, not from the top-level directory, which is why the parent looking unchanged was misleading. At least one file or subdirectory under /var/opt/stalwart had a different owner or mode (something created by a root-run process, a restore, or an earlier run as another user), and the recursive chown/chmod is what fixed that inner entry.
Worth confirming the whole tree stays owned by the stalwart user and that no backup or maintenance job writes into it as root, so it doesn’t drift back.
Thanks. Looks got at the moment.
find /var/opt/stalwart -printf '%u\\n' | sort -u
stalwart