Permission denied to change gid(group) of a file I own
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
Change the group ownership of the file/directory to a group that both you and the other user are members of;
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)
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