Re: Preventing writes to the underlying directory when a mounted filesystem disappears

The Wanderer <[email protected]> Mon, 27 Jul 2026 08:03:31 -0400
Newsgroups gmane.linux.debian.user
Organization This space intentionally left blank.
Message-ID <[email protected]>
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ow6FfntXSTtEUe0QT26rObKmVALn8Kl2N
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 2026-07-27 at 07:55, Greg Wooledge wrote:

> On Mon, Jul 27, 2026 at 08:25:40 -0300, Marcelo Laia wrote:
>=20
>> - Debian Testing
>> - rsyslog
>> - Log files stored on an external USB SSD
>> - The root filesystem should remain as untouched as possible, while
>> the SSD receives all log writes.
>=20
>> If the USB SSD is unexpectedly disconnected, the USB bus resets, or
>> the filesystem becomes unmounted for any reason, the mount point
>> directory still exists. As I understand it, applications may
>> continue writing to that directory, which now belongs to the
>> underlying root filesystem. On systems using flash storage, this
>> could eventually wear out the internal storage without immediately
>> being noticed.
>=20
> My first thought would be to create a subdirectory on the mounted
> external device, and write the logs to files within that
> subdirectory.
>=20
> If/when the external device goes away, that subdirectory will not
> exist, so you won't be able to create the log files specified in the
> configuration.

That was my own first thought as well, but it only works if you have
that much control over the applications that will be writing the files
(and if they won't automatically create any "missing" directories in the
path specified for them to write to). I haven't looked at rsyslog
configuration specifically, this morning, so I don't know whether that
consideration would apply in practice.

The first alternative I've managed to think of would be to look at
permissions, such that the processes that would be writing the files
won't have write permission to the underlying directory, only to the
mounted one. Depending on how the software involved will be configured,
however, that could be difficult to adjust - and since this is
apparently going to be a system-level service (rsyslog), it might kind
of need some fairly high-end write access, such that this might be
nontrivial to restrict.

The only other fallback option that's occurred to me is to mount the
root filesystem read-only, such that if the mounted writable FS goes
away, any writes would be rejected for being to a read-only filesystem.
Depending on what the situation surrounding this setup is intended to
be, however, it could be the case that *other* things (external to the
log daemon) will need to be able to write to the root filesystem - in
which case that wouldn't be a viable option either.

--=20
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw


--Ow6FfntXSTtEUe0QT26rObKmVALn8Kl2N
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmpnSRMACgkQBKk1jTQo
MmuNcw//dfnKp/zCEwy59o3b3dFiad83LKlBf6qCg3p/jqqzHK0NDSeuElEzOuFC
62WGQdisrd7SRvbYI2wVQ8vIGgos56zXu24oMHH+FkjQ6qYWepDKrq3TOJNmLbA2
BmpNQbtpP8YAK0J7+mvTMklwcOQEnmGVqwZu9ZtOTicpaL4ZVlRNLXfmjWuu9v+S
DquQSypqEA4rUljUSk27PY9gkrjdONhz37SfZGT870zaXlMQ8a76IdyP7O5s8rFB
onHgT8qUyCbGjOEcOkjw2PPz5W4UaydOFkCn1neUTckZQ0RuBLCmv1OYuJvIFJ0M
NDlL3Fxz/avdvtaMZflej2cZQhK6eYqTdFiuL7GXAoq0ZOI4Jw27Nt2OR1S2ZXjh
n20Codnd7TbmEkUfz1c9Ixm5pcMD1UHiyAGXtU0G2t4DbHyhzlZ4O0irWaXd6QE4
aU+bJSbl1BdlpZj22ww/o5EnmBEOTOs/Dem4/43XZwQasI8BHpkj0gHsncdHXHfb
SFxMpejm+f5wnGDJLXakNhEC8mqJS1H3Xdxk4WNO0AKfavi0mIhXCjqX7tyuL6Y3
QcRH1xmM/ZFKVz5ki2F4VJ5mcOcaT86Gf/ScEcMAxheT6ZzUu0dd+X87iLqSYfmX
ugN/bODXWFbeCRr6NbWRxt6qVYv+rActYiV1xjhkQcPDUEDqT7Q=
=xb8z
-----END PGP SIGNATURE-----

--Ow6FfntXSTtEUe0QT26rObKmVALn8Kl2N--