In my department we have a small file server with CentOS and samba. I have root access to be able to perform some basic maintenance.

Today I was making some folders read-only, so I went ahead and did a chmod -R -w some-folder/, but for a few files I got the response:

chmod: ./somefile.pdf: new permissions are r-xrwxr-x, not r-xr-xr-x

After adding -v I don't get a lot of information:

mode of `./somefile.pdf' retained as 0575 (r-xrwxr-x)

I tried the following just to make sure:

# touch test-file
# chmod -v -R -w .
mode of `./somefile.pdf' retained as 0575 (r-xrwxr-x)
chmod: ./somefile.pdf: new permissions are r-xrwxr-x, not r-xr-xr-x
mode of `./test-file' changed to 0444 (r--r--r--)

I can't think of any good reasons why root wouldn't be able to do a chmod?

Some tidbits:

  • The filesystem is not read-only (only some files refused to be chmodded).
  • I ran the chmod commands as root but to no effect.
  • The partition where the files reside is ext4.

UPDATES: This is the output for lsattr on the file and containing folder:

# lsattr somefile.pdf
-------------e- somefile.pdf
# lsattr ..
-------------e- ../myfolder

There's no setuid present (ls -la):

dr-xr-xr-x  2 userxyz abc   4096 May 30 09:29 .
dr-xr-xr-x 17 userxyz abc   4096 Sep 19  2013 ..
-r-xrwxr-x  1 userxyz abc 275150 Aug  6  2013 somefile.pdf
  • You are acessing this files remotely ? May 30, 2016 at 14:42
  • 1
    What's the output of lsattr on those same files, and the directory above it?
    – Ryder
    May 30, 2016 at 14:44

1 Answer 1


According to sources, you have a naive expected mode. After ditching more, I think the cause is the -w option, which is not what you are expecting. You should give g-w or ugo-w (according to your needs).

Without giving an explicit target (a, o, g, u) some unexpected results could be provided, according to the umask value. I think such extra message is done because of such unexpected changes.

Edit: sources in http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/chmod.c#n301

Taken from google cache, a comment in that code that is not there anymore:

/* If true, diagnose surprises from naive misuses like "chmod -r file". POSIX allows diagnostics here, as portable code is supposed to use. "chmod -- -r file" */

  • Yes, this was it. I changed it to ugo-w and it doesn't complain any more. I'll wait some time before accepting out of courtesy to potential answerers.
    – Roflo
    May 30, 2016 at 15:18
  • 1
    And I welcome edits or better answers, because I still don't understand why chmod works in this strange manner. May 30, 2016 at 15:20
  • 5
    man chmod: "A combination of the letters ugoa controls which users' access to the file will be changed [...] If none of these are given, the effect is as if (a) were given, but bits that are set in the umask are not affected." So you can do stuff like chmod +w file and only give write access to those that would get it when creating a new file. The negative behaviour does seem a bit confusing though, so the warning seems like a good idea.
    – ilkkachu
    May 30, 2016 at 22:01

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.