find: failed to restore initial working directory: Permission denied

Question

I am trying to find some files on a path /local/java_apps/ and then delete them using a shell script and generate a log file in the /home/jboss The code is as follows :

STAMP=$(date +"%m%d%Y%H%M%S")
sudo -u jboss find /local/java_apps/ -type f -iname '*.pdf' -mtime +180 -print -delete >> /home/jboss/.log_$STAMP 2>&1

The ls -ld /local/java_apps command gives:

drwxrwxr-x+ 3 root root 4096 Oct 10 2017 /local/java_apps/

The crontab looks like this:

0 1 * * 4 /etc/cron.weekly/servercleanup.sh

When the script is run by the crontab it gives the following error:

find: failed to restore initial working directory: Permission denied

Solution

find changes its directory as part of its internal operation. When you run the command, you're sitting in a directory that the jboss user doesn't have permission to go to, so when find tries to put its directory back to what it was, it fails. To fix the problem, run the command from a directory that jboss is allowed to access.

Comments

[mrc02_kr]

Can you paste output of ls -ld /local/java_apps ?

[Yash Gandhi]

Output : drwxrwxr-x+ 3 root root 4096 Oct 10 2017 /local/java_apps/

[mrc02_kr]

The permissions are 775 not 777. That's why user jboss cannot delete files from this folder.

[Joseph Sible-Reinstate Monica]

@YashGandhi I'm talking about your current working directory when you run the command, not the directory that it's in.

[AFP_555]

Wow, this sucks REALLY bad. How is it possible that such a core tool has this issue?

[Joseph Sible-Reinstate Monica]

@AFP_555 Is this really a big issue? Why do you need to run find from a directory that you don't have permission to enter? If it's really a big deal for some reason, you could see about sending upstream patches to make it use the *at functions instead.