12

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
Roflo
  • 369

1 Answers1

17

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" */

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
  • 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 '16 at 15:18
  • 1
    And I welcome edits or better answers, because I still don't understand why chmod works in this strange manner. – Giacomo Catenazzi May 30 '16 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 '16 at 22:01