Why would chmod give "No such file or directory" when running recursively?

linux ubuntu permissions unix chmod

14,956

Solution 1

This bug looks related:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706097

I can reproduce it in debian 7 with coreutils 8.13-3.5.

I think that not using "--changes" or "--verbose" can workaround the problem.

Solution 2

I just had this happen to me this week when using --verbose. Was initially puzzled but think I have narrowed it down. This only happens when the SETGID bit is set.

Test setup:

$ mkdir --parent foo/bar

Without SetGID, no error:

$ chmod --recursive --changes o-rwx foo
mode of ‘foo’ changed from 0775 (rwxrwxr-x) to 0770 (rwxrwx---)
mode of ‘foo/bar’ changed from 0775 (rwxrwxr-x) to 0770 (rwxrwx---)

With SETGID, error:

$ chmod --recursive g+s foo
$ chmod --recursive --changes o-rwx foo
mode of ‘foo’ changed from 2775 (rwxrwsr-x) to 2770 (rwxrws---)
chmod: getting new attributes of ‘bar’: No such file or directory

As a workaround, use find:

$ find foo | xargs chmod --changes o-rwx
mode of ‘foo’ changed from 0775 (rwxrwxr-x) to 0770 (rwxrwx---)
mode of ‘foo/bar’ changed from 0775 (rwxrwxr-x) to 0770 (rwxrwx---)

Hope this helps!

14,956

Pablo

You can find my blog at https://pupeno.com where I publish about coding and other stuff.

Updated on September 18, 2022

Comments

Pablo over 1 year
I can change the permissions of the file directly:
```
# chmod --changes --recursive ug+rwX       /var/www/shared/tmp/cache/assets/BA0/280/sprockets%2F286302903364106648b609d708884f78
```
and I can also change the permissions of the directory that contains the file:
```
# chmod --changes --recursive ug+rwX       /var/www/shared/tmp/cache/assets/BA0/280
```
when I try to change the permission of the directory that contains that directory, recursively, I get an error about the previous directory not being found:
```
# chmod --changes --recursive ug+rwX       /var/www/shared/tmp/cache/assets/BA0
chmod: getting new attributes of `280': No such file or directory
```
The current permissions, even though I don't how this can be of any influence, look like this:
```
# ls -alR /var/www/shared/tmp/cache/assets/BA0
/var/www/shared/tmp/cache/assets/BA0:
total 20
drwxrwsr-x   3 rails rails  4096 Jun  4 09:54 .
drwxrwsr-x 569 rails rails 12288 Jun  4 09:54 ..
drwxrwsr-x   2 rails rails  4096 Jun  4 09:54 280

/var/www/shared/tmp/cache/assets/BA0/280:
total 12
drwxrwsr-x 2 rails rails 4096 Jun  4 09:54 .
drwxrwsr-x 3 rails rails 4096 Jun  4 09:54 ..
-rw-rw-r-- 1 rails rails  481 Jun  4 09:54 sprockets%2F286302903364106648b609d708884f78
```
I'm running the commands as root. Any ides?
- Jeff Barnard almost 10 years
  
  This bug looks related, but it should only trigger when removing permissions and not when adding: bugs.debian.org/cgi-bin/bugreport.cgi?bug=706097
- Pablo almost 10 years
  
  @LatinSuD would you like to add that as an answer. I think the bug hits whether you are removing or adding attributes, if chmod has to stats the file. I'll edit the question with my workaround, but I think you deserve the credit.
- Jeff Barnard almost 10 years
  
  It looks like the bug is dumber than what i understood at first glance.
- NukaRakuForgotEmail almost 10 years
  
  I was only able to reproduce with SETGID on Ubuntu 14.04 with coreutils 8.12-1. Also, with both --changes and --verbose.
zyxue over 7 years

I repeated the experiment. It seems even though with chmod: getting new attributes of ‘bar’: No such file or directory, the permission of bar still get changed successfully, is that correct?