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--