tmp.mount

Trynna3

Active Member
Joined
Jun 5, 2024
Messages
118
Reaction score
54
Credits
1,155
Hello folks,
is this feature very important?
I have finally succeeded in installing LMDE and UBUNTU 20.04.6 on one hard drive, along some data partition and mirroring it on an external hard drive.
When doing some checks I came across results like this:

~$ gparted
Unit tmp.mount does not exist, proceeding anyway.
GParted 1.0.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3

and then also:

~$ systemctl status tmp.mount
● tmp.mount
Loaded: masked (Reason: Unit tmp.mount is masked.)
Active: inactive (dead)

The bot says that some systems or administrators may mask tmp.mount in favor of other configurations. "For instance, modern systems might use other mechanisms to handle temporary files or have alternative configurations for /tmp."

Is it the case in my case?

I want to have a healthy and secure system and without this there might be some vulnerabilities.

checking further I got this:

~$ df -h /tmpFilesystem
Size Used Avail Use% Mounted on
/dev/nvme0n1p4 256G 24G 219G 10% /

the partition 4 is where I have Ubuntu installed. LMDE is on partition 3

I have got commands how to set up /tmp with tmpfs, but not sure whether it is actually important, as per beginning of my email, i.e. if a different solution is in modern systems?

TIA
 


Hello folks,
is this feature very important?
I have finally succeeded in installing LMDE and UBUNTU 20.04.6 on one hard drive, along some data partition and mirroring it on an external hard drive.
When doing some checks I came across results like this:

~$ gparted
Unit tmp.mount does not exist, proceeding anyway.
GParted 1.0.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3

and then also:

~$ systemctl status tmp.mount
● tmp.mount
Loaded: masked (Reason: Unit tmp.mount is masked.)
Active: inactive (dead)

The bot says that some systems or administrators may mask tmp.mount in favor of other configurations. "For instance, modern systems might use other mechanisms to handle temporary files or have alternative configurations for /tmp."

Is it the case in my case?

I want to have a healthy and secure system and without this there might be some vulnerabilities.

checking further I got this:

~$ df -h /tmpFilesystem
Size Used Avail Use% Mounted on
/dev/nvme0n1p4 256G 24G 219G 10% /

the partition 4 is where I have Ubuntu installed. LMDE is on partition 3

I have got commands how to set up /tmp with tmpfs, but not sure whether it is actually important, as per beginning of my email, i.e. if a different solution is in modern systems?

TIA
To the question "Is this feature important?", the answer is yes.

The first item worth checking is the state of the /tmp directory that systemd controls. One can run:
Code:
$ ls -ld /tmp
drwxrwxrwt 18 root root  400 Sep 13 07:38 /tmp
If there is an issue, it's useful to look into the systemd processes that control it. The /tmp directory is used extensively by a number of basic programs included systemd, which is why it's important (see below for docs).

Normally on a systemd system, tmp.mount is running, and it shows that it's about /tmp. For example here it shows it's loaded and active:
Code:
$ systemctl status tmp.mount
 tmp.mount - Temporary Directory /tmp
     Loaded: loaded (/usr/lib/systemd/system/tmp.mount; static)
     Active: active (mounted) since Fri 2024-09-13 06:53:15 AEST; 59min ago
 Invocation: 7fd83cc433004500ab41b486b5dfc3a2
      Where: /tmp
       What: tmpfs
       Docs: https://systemd.io/TEMPORARY_DIRECTORIES
             man:file-hierarchy(7)
             https://systemd.io/API_FILE_SYSTEMS
      Tasks: 0 (limit: 18702)
     Memory: 4K (peak: 1.7M)
        CPU: 3ms
     CGroup: /system.slice/tmp.mount

Sep 13 06:53:15 min systemd[1]: Mounting tmp.mount - Temporary Directory /tmp...
iSep 13 06:53:15 min systemd[1]: Mounted tmp.mount - Temporary Directory /tmp.

If tmp.mount is masked, one can unmask and reload the daemon for systemd so that it recognises the new state after unmasking. One can use the following commands as root or a selection of them:
Code:
systemctl umask tmp.mount
systemctl status tmp.mount
systemctl daemon-reload
systemctl enable --now tmp.mount
systemctl status tmp.mount

As to the details of tmp.mount and the docs, one can run the following to see where the docs are:
Code:
$ systemctl cat tmp.mount
# /usr/lib/systemd/system/tmp.mount
# <snip>
[Unit]
Description=Temporary Directory /tmp
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://systemd.io/API_FILE_SYSTEMS
<snip>
 
Last edited:
systemctl unmask tmp.mount
typo, it's umask ;)

And depending on distro umask might not work at all.
On Debian and probably on debian based distros this function to work requires "explicit pam_umask configuration with usergroups option`:

I still haven't touched umask and didn't go into details on how to use it, so might be missing something.
 
typo, it's umask ;)

And depending on distro umask might not work at all.
On Debian and probably on debian based distros this function to work requires "explicit pam_umask configuration with usergroups option`:

I still haven't touched umask and didn't go into details on how to use it, so might be missing something.
Thanks for the typo alert ... now amended.

The alternative to using the systemd umask option, if by chance it doesn't work, is to find the link that points tmp.mount to /dev/null (which is the usual way of masking it) and delete the link. Then one can reload the systemd daemon, enable and start tmp.mount to get it up.

Here is the link on this machine where tmp.mount is loaded and running:
Code:
$ ls -l /usr/lib/systemd/system/local-fs.target.wants
total 0
lrwxrwxrwx 1 root root 17 Aug 16 07:00 run-lock.mount -> ../run-lock.mount
lrwxrwxrwx 1 root root 12 Aug 16 07:00 tmp.mount -> ../tmp.mount
 
OK, thanks, I will investigate.

I think I had this after I backed up my newly installed hard drive with two distros on an external disc and the system rebooted from it and I was checking for errors after copying the whole thing. It is all so new to me and complicated, so I might be missing some basics.

My question also was whether some other system or settings don't cover this feature a different way, as the bot suggested?
 
Hello, just an update.
The above was for Ubuntu, which I don't use heavily. My main system is LMDE (when I don't use Win10, still dragging that one). And checking in LMDE the tmp was on nvme, now changed to the RAM.
I'll look into the Ubuntu once again, when I have more time and will to do it (maybe). I only installed Ubuntu for the SGD remote app for work, since Oracle lists this Linux version as compatible. But I might not need to use it in the future and might go for a different alternative distro, or just stick with LMDE, time will show.
Just I need to remember doing regular backups of the entire system, so it reflects these changes.
 

Members online


Top