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.
    – Pablo
    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

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.