7

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?

4
  • 1
    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
    – LatinSuD
    Jun 4, 2014 at 10:26
  • @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. Jun 4, 2014 at 11:28
  • It looks like the bug is dumber than what i understood at first glance.
    – LatinSuD
    Jun 4, 2014 at 11:48
  • I was only able to reproduce with SETGID on Ubuntu 14.04 with coreutils 8.12-1. Also, with both --changes and --verbose. Jun 4, 2014 at 11:51

2 Answers 2

4

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.

5

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!

1
  • 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?
    – zyxue
    Sep 20, 2016 at 18:50

You must log in to answer this question.

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