0

I have to write a script that runs at startup (this is a part that I don't know how to do yet) that erases the temporary files of the current user and I have the "Permission denied" error. The errors look like this:

'/tmp/systemd-private-long number-colord.service-LTsv8G' : permission denied ;
'/tmp/systemd-private-long number-systemd-timesyncd.service-PxhNq0' : permission denied ;
'/tmp/systemd-private-long number-rtkit-daemon.service-KQN6zN' : permission denied

This is my code so far:

TMPFILE=$(mktemp)|| exit 1
find /tmp -type f -user $USER -exec rm -f {} \;

if i run ls -l after i've created TMPFILE I get:

total 4
-rwxrwxrwx 1 bristena bristena 530 may 25 10:51 sh.01

if i do cd /tmp and then I run ls -l I get

total 12
drwx------ 3 root root 4096 may 25 10:14 systemd-private-long number-colord.service-LTsv8G
drwx------ 3 root root 4096 may 25 10:14 systemd-private-long number-rtkit-daemon.service-KQN6zN
drwx------ 3 root root 4096 may 25 10:14 systemd-private-long number-systemd-timesyncd.service-PxhNq0
-rw------- 1 bristena bristena 0 may 25 10:51 tmp.j0rvQtmz7G

from what I've seen online I can also use trap "rm -f TMPFILE; exit", but I don't know how to integrate the current user requirenment

All of your help would be deeply appreciated

3
  • I am using Ubuntu 16.04 and I am running this as a user. As for the files that trigger the error I'm not really sure, the errors look like this : '/tmp/systemd-private-long number-colord.service-LTsv8G' : permission denied ; '/tmp/systemd-private-long number-systemd-timesyncd.service-PxhNq0' : permission denied ; '/tmp/systemd-private-long number-rtkit-daemon.service-KQN6zN' : permission denied
    – helpmb
    Commented May 25, 2020 at 7:40
  • if i run ls -l after i've created TMPFILE I get: total 4 -rwxrwxrwx 1 bristena bristena 530 may 25 10:51 sh.01 if i do cd /tmp and then I run ls -l I get total 12 drwx------ 3 root root 4096 may 25 10:14 systemd-private-long number-colord.service-LTsv8G drwx------ 3 root root 4096 may 25 10:14 systemd-private-long number-rtkit-daemon.service-KQN6zN drwx------ 3 root root 4096 may 25 10:14 systemd-private-long number-systemd-timesyncd.service-PxhNq0 -rw------- 1 bristena bristena 0 may 25 10:51 tmp.j0rvQtmz7G
    – helpmb
    Commented May 25, 2020 at 8:00
  • I'm ready, it's edited
    – helpmb
    Commented May 25, 2020 at 8:08

3 Answers 3

2

With find /tmp -type f -user $USER -exec rm -f {} \; you are telling find to go find and delete any files owned by $USER in everywhere under /tmp.

Now, your /tmp contains sub-directories that are owned by root. In theory they could contain more files owned by $USER. So find will try to peek into those directories to look for them. But the root-owned directories have permissions drwx------, so only root will be able to access them in any way.

As a result, find will report the directories it failed to enter, to tell you that it could not search everywhere under /tmp and so it might theoretically have missed something.

Scripts that run at system startup will run as root unless specified otherwise, and so if you would run that same command in a system start-up script, it would have full access to all directories under /tmp and would not have this problem at all: find running as root would be able to perform an exhaustive search into all directories under /tmp.

But if you run it as your own user account, then you would have to either ignore the "permission denied" errors since you expect them, or perform a more complicated search that first looks for directories $USER can access under /tmp and then removes any files in them.

Or if you're only looking for temporary files created by the same script, then you would want to look at temporary files in the /tmp directory only, and ignore any sub-directories of /tmp. If you want to do this, google on how to use the -prune option of find; it's a bit tricky one.

The trap command is slightly different. It can be used to ensure that your script will always clean up its temporary files (unless killed by an uncatchable signal like SIGKILL or a system crash). In a POSIX-compatible shell you would use it like this:

TMPFILE=$(mktemp)|| exit 1
trap "rm -f $TMPFILE" EXIT

In this trap command, EXIT is not a command, but the condition that will cause the trap to be triggered. The condition can be a signal, or a special value 0 or EXIT. Both of those two special values will mean "this trap action should be executed whenever this shell process is exiting for any reason."

0

In order to avoid the error messages of

find /tmp -type f -user $USER -exec rm -f {} \;

you can either redirect them

find /tmp -type f -user $USER -exec rm -f {} \; 2>/dev/null

or prevent find from running into that problem:

find /tmp \( -type d \( -executable -o -prune \) \) -o -type f -user $USER -exec rm -f {} \;
0

This one is nice, you even can add the days -atime +3 files 3 days old

find /tmp \( -type d \( -executable -o -prune \) \) -o -type f -atime +3  -user $USER -exec rm -f {} \;
1
  • This looks like a copy/paste of a previous answer with the addition of the -mtime argument. Minor enough addition that it should be a comment to the accepted answer, not an answer in its own right.
    – doneal24
    Commented Nov 27, 2022 at 20:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .