It appears I still miss some things about the way permissions work. I am on a debian 7 system btw. just now I have this file of which I downloaded and it belongs to myuser:myuser, that is both user and group are set to me. It also resides in my $HOME directory since that is where I downloaded it to.

So far so good. Now I want to share this file with some other users of the pc and for that I want to switch the group ownership of the file to group "users". however that fails:

nass@quarx:~/xmas_carol$ chgrp -R users * 
chgrp: changing group of movie.mov': Operation not permitted

And the contents of the folder are:

-rwxr-xr-x 1 nass nass 2482411461 Feb  6 03:57 movie.mov

I am fuzzy about what is going on with the permissions. Can someone explain

  • is /xmas_carol samba/nfs mount ? – Rahul Patil Feb 6 '14 at 2:21
  • The solution is setfacl (if filesystem has ACLs). see unix.stackexchange.com/questions/101263/… – ctrl-alt-delor Jun 1 '17 at 20:29
  • I had the same error until I realized I had JUST ADDED myself to that group. In other words, I had to logout, log back in, for the changes to take effect. – Jonathan Apr 6 '18 at 22:45

Your user is probably not a member of the users group, so you don't have the right to give a file to that group. To illustrate:

$ groups
terdon sudo netdev fuse vboxsf vboxusers

$ ls -l file
-rw-r--r-- 1 terdon terdon 604 Feb  6 03:04 file
$ chgrp users file
chgrp: changing group of ‘file’: Operation not permitted
$ chgrp vboxusers file
$ ls -l file
-rw-r--r-- 1 terdon vboxusers 604 Feb  6 03:04 file

This behavior is mentioned in the POSIX specs:

Only the owner of a file or the user with appropriate privileges may change the owner or group of a file.

Some implementations restrict the use of chgrp to a user with appropriate privileges when the group specified is not the effective group ID or one of the supplementary group IDs of the calling process.

The main reason for this is that if you aren't a member of a group, you should not be able to modify what that group has access to. This answer on chown permissions is also relevant.

Traditionally, on shared systems, you have a users group to which all regular users belong and that is the primary group of each user. That way, files are created owned by the users group and all users can read them.

Anyway, since that is not the way that Debian-based distros are set up these days, the way to give a specific user access to your file would be to either

  1. Change the group ownership of the file/directory to a group that both you and the other user are members of;

  2. Just change the permissions of the file/directory accordingly:

    $ chmod 755 /home/terdon
    $ ls -ld /home/terdon
    drwxr-xr-x 170 terdon terdon 491520 Apr 20 13:43 /home/terdon/

    That will make the directory accessible to everybody.


On recent UNICes (and "recent" has a rather broad meaning here), you cannot change files' group ownership to a group you are not a member of. Legacy versions of different UNIX flavors supported this, for use-cases such as yours, but it proved to be a security problem.

The problem of being able to change group ownership to foreign groups is a quite trivial one: If the file system the file resides on has group quotas enabled, a user with malicious intend could simply fill up the foreign group's quota, making it impossible for users with this group as primary group ID to create any further files. This could easily affect even processes already running and cause them to die because of "full disk".

To circumvent your problem there are (at least) two possibilities: First, you could ask your system's super user to add the intended target group to your account's list of supplementary groups. Of course this only makes limited sense if you otherwise don't have a relation to this group.

The other way for not needing to make the file world-writable, what is surely not desired, is using ACLs to give the intended group read- and write-permissions:

$ setfacl -m group:thegroupsname:rwx the_file(s)
  • you don't have to give execute (on a regular file), and probably don't want to give away write permission. – ctrl-alt-delor Jun 1 '17 at 20:27

It might be because the immutable bit is set. Get the list of file attributes running

lsattr /path/to/your/file

if i appears, then the immutable attribute is set and no one can modify the file (even root).

To remove the attribute you must run as root

chattr -i /path/to/your/file

To see more file system attributes read the man pages

man chattr
man lsattr
  • Good point, but from the question I suppose the questioner is not having super user rights, which you need to clear the immutable flag (at least on all filesystems I came along so long). Also, since he just extracted an archive, it's most probably not the issue since the used archiver would had needed to set it (same problem). – Andreas Wiese Apr 21 '14 at 12:54

If you had added yourself to the group just now, be sure to log out, log back in to make sure the changes take effect.

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.