2

I did sudo mv /tmp /var/lib/apt/lists not realizing that it would move the whole folder and not just the contents.

I since do (as suggested in Accidentally deleted tmp folder)

sudo mkdir -m 1777 /tmp

on startup, but after a while it disappears again. What can I do? how can I debug this?

It seems that /tmp is renamed to /snapshot.0 (or with a higher index if other snapshots already exist).

Restart does not solve it. But shutting down without a /tmp isn't a problem either, on startup a new /tmp is there. However within 4 minutes it is renamed to another snapshot.

What happens without /tmp:

  • no tab completion in bash (sometimes)
  • programs such as chromium-browser and system monitor don't start
  • apt-get seems to rely on /tmp as well

I currently execute sudo mv /snapshot.0 /tmp whenever /tmp disappears.

Experiments:

I start the computer(as we will see /tmp is still there apparently it survived restart) and open a terminal where I execute:

$ while true; do 
   t=$(date +%H:%M:%S);      #timestamp as hour minute seconds
   date;ls -lt / | head -3;  print out date and most recent folders in /
   ls -l /tmp        > ~/Desktop/ls.tmp.log.${t}; 
   ls -l /snapshot.0 > ~/Desktop/ls.snap.log.${t}; 
   sleep 60; 
done;

I do nothing else! log in terminal:

Di 23. Jun 19:44:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
drwxr-xr-x  34 root root       1000 Jun 23 19:42 run
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:45:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:46:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:47:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:48:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:49:13 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:48 snapshot.0
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/tmp': No such file or directory

So within 5 minutes /tmp has been renamed to /snapshot.0.

there is no difference between ls.tmp.log.19:4[4-8]:12 There is also no difference between ls.tmp.log.19:48:12 and ls.snap.log.19:49:13 so it can't be the content of /tmp.

Progress:

While I was hoping for a solution that makes things as they were before(without reinstalling the system) Giorgos Saridakis' suggestion of symlinks does work helps a lot. However I still can't start system monitor:

$ gnome-system-monitor 
cannot create temporary directory for the root file system: Permission denied

despite having all permissions set:

$ ls -lt /
total 2097264
drwxrwxrwt   8 root root       4096 Jun 27 15:21 snapshot.0
-rw-r--r--   1 root root          0 Jun 27 15:10 lifesign
...
lrwxrwxrwx   1 root root         11 Jun 23 22:12 tmp -> /snapshot.0

I guess I'll have to write a demon after all...

I wrote a script:

#!/bin/bash
while true;
do
    if [ ! -d "/tmp" ];
    then mv /snapshot.0  /tmp 2>> /home/t/tmp.rename.bg.err;
     date >> /home/t/tmp.rename.bg.log;
    fi;
    sleep 10;
done

that is executed with

sudo bash tmp.rename.sh &

after login. It's not ideal but I don't have to get into writing daemons just yet.

4
  • 1
    This might seem silly, but have you tried moving it back with sudo mv /var/lib/apt/lists /tmp?
    – tfstwbbnb
    Jun 22, 2020 at 0:43
  • @tfstwbbnb Yes, I did.
    – user2740
    Jun 22, 2020 at 22:11
  • Was your /tmp originally a simple directory or a filesystem ? You can check with grep /tmp /etc/fstab and post the result if something is found.
    – ChrisAga
    Jun 23, 2020 at 18:51
  • 1
    @ChrisAga I think it was just a directory, I don't remember doing anything special for /tmp. grep /tmp /etc/fstab returns nothing.
    – user2740
    Jun 23, 2020 at 18:57

2 Answers 2

2
+50

It seems you've stumbled on a persistent part of the Kernel, I believe this is not solvable in the proper way.

In the absence of will to reinstall the whole system, why don't you try creating a symbolic (or a hard) link from /snapshot.0 to /tmp:

sudo ln -s /snapshot.0 /tmp 

If that doesn't work, I would make a small daemon to constantly check if /tmp is there and create it, if not found (with lock permissions maybe).

Difficult situation, I sympathize :)

4
  • 1
    Hmm, I was really hoping I didn't have to reinstall the system... Do you think a version upgrade might fix it? How should I go into the next upgrade, with /tmp deleted or symlinked?
    – user2740
    Jun 26, 2020 at 17:38
  • Maybe a kernel update will fix things, but who can say ? if the links don't work (supposing that maybe a hard link will keep /tmp alive, that's the idea), apart from a system upgrade, a simple daemon will do the job. It's not perfect of course, but you could live with it Jun 26, 2020 at 18:07
  • Giorgos, what do you mean by "a persistent part of the kernel"? Are you saying this regular rename is a kernel bug? It's certainly not normal behaviour and I can't find it documented as a side-effect anywhere. (The closest I can find is snapper, but that's only on a match for snapshot.0.) Thanks
    – roaima
    Jun 29, 2020 at 13:25
  • 1
    It appears the kernel seeks to locate a given i-node for /tmp and removes the new /tmp created again and again. This would certainly not be a kernel bug, rather a security measure, which probably doesn't have to do with /tmp alone. I am simply interpreting what is observed roaima and making the best guess from that perspective. Jun 29, 2020 at 13:51
0

Just delete the create one after booting and make a new directory of tmp as followed:

sudo mkdir -m 1777 /tmp
chown root:root /tmp

here -m is called mode of creation of a directory,which Set the file permission bits of the newly-created directory to the specified mode value.

After executing the above command, Now run the command below to check the permissions of the directory.

ls -ld /tmp

and It should be looking like this

Screenshot

5
  • The newly created /tmp directory has been moved to snapshot.0 as well...
    – user2740
    Jun 22, 2020 at 21:59
  • does this repeatedly happen ? Jun 23, 2020 at 6:06
  • 1
    Yes, for example after the log that I added to the question, I created a new /tmp dir. It lasted for 50 minutes until it got replaced.
    – user2740
    Jun 23, 2020 at 19:15
  • Do you experience even after transferring the ownership to root? Do you use root as a default user in Kali Linux? Jun 24, 2020 at 5:40
  • I'm not using Kali but Ubuntu. My default user is not root. I don't have to transfer ownership since sudo mkdir already sets root as the owner.
    – user2740
    Jun 24, 2020 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.