Hi,
On Sat, May 02, 2026 at 10:11:15PM -0400, Greg Wooledge wrote:
> On Sun, May 03, 2026 at 00:58:35 +0000, Andy Smith wrote:
> > For some reason your filesystem has gone read-only. If I were you I'd be
> > looking further back in the logs to see if there is anything about that,
> > as I would expect there to be.
>
> Could be. And a read-only file system is extremely easy to check,
> so that should be checked first.
>
> It could also be a restriction added by a systemd unit. Tracking down
> all of the restrictions across potentially multiple systemd units will
> be more challenging, if it turns out the file system is not read-only.
I think you are probably right and OP won't find any earlier logging
about a filesystem being globally read-only because it isn't.
Having searched around I've found a few hits for this error message and
many of them involve the thing doing the mail delivery having restricted
permissions via the systemd unit.
For example this one with software called netdata involves netdata being
started without ability to write /var/spool/postfix/maildrop and getting
the exact same error when trying to send notification emails:
https://www.spamcop.net/sc?id=z6963466407z15976b2b8b2abb7f62add98676d85c9bz
So perhaps OP does need to look at the monit.service file to check it
isn't having its view of the filesystem restricted too severely.
Looking at:
https://sources.debian.org/src/monit/1:5.35.2-3/system/startup/monit.service.in?hl=16#L16
I'm guessing
ProtectSystem=strict
might be the culprit. Although I confess I don't really understand why a
process launched by monit would be directly trying to write to the
postfix directory as I would have thought it talks to postfix and then
something from postfix delivers the mail. But since the same thing
appears to have happened with netdata and other software then I think
it's got a good chance.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
