On some systems,
/tmp is a
tmpfs by default, and this is the configuration provided by systemd’s “API File Systems”. Fedora-based systems follow this pattern to various extents; Fedora itself ships
/usr/lib/systemd/system/tmp.mount and enables it, but RHEL 8 ships it without enabling it. On such systems, masking and unmasking the unit is the appropriate way of disabling or enabling a
/tmp, as documented in the API File Systems documentation.
Other systems such as Debian don’t ship
tmp.mount in a directly-usable location; this is why you need to copy it to
/etc/systemd/system if you want to use it. This has the unfortunate side-effect of creating a full override of
/etc, which means that if the
systemd package ships a different version of
/lib/systemd/system in the future, it will be ignored. On such systems I would recommend using
In both setups,
/etc/fstab is still the recommended way of customising
/tmp mounts, e.g. to change their size;
man systemd.mount says
In general, configuring mount points through
/etc/fstab is the preferred approach to manage mounts for humans.
and the API File Systems documentation concurs.
Using mount units is recommended for tooling, i.e. for automated configuration:
For tooling, writing mount units should be preferred over editing
(This means that tools which want to automatically set up a mount shouldn’t try to edit
/etc/fstab, which is error-prone, but should instead install a mount unit, which can be done atomically and can also be overridden by a system administrator using systemd features.)
/etc/default/tmpfs is used by Debian’s
sysvinit, so it’s irrelevant with systemd.