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 tmpfs /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 tmp.mount in /etc, which means that if the systemd package ships a different version of tmp.mount in /lib/systemd/system in the future, it will be ignored. On such systems I would recommend using /etc/fstab instead.
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 /etc/fstab.
(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.
