Solved Strange chown(8) behavior

Greetings all,

ls -als /home/user results in showing ownership as user:1001. When I issue
chown -R user:user /home/user, the system responds with
CSS:
chown: user: illegal group name
However, id user as well as /etc/passwd, shows correct UID, GID for the user.

I found an old post reporting the same issue - https://forums.freebsd.org/threads/chown-nobody-not-working.48313/, but the proposed solution did not work. Neither did shutting down and restarting the system. How do I fix this?

Kindest regards,

M
 
You are confusing the user name and the group name.
"user:1001" says that the user name is "user" and the group is unnamed, but has a GID of "1001"
User names are enumerated in /etc/passwd. Group names are enumerated in /etc/group.
On your enumerating host, /etc/group does not have an entry for group 1001.
There is no such group as "user", so the chown fails.
If you have appropriate permission, chown -R user:1001 /home/user would work.

I expect that GID "1001" for /home/user came from another host via NFS...
With NFSv3, the UIDs and GIDs on participating hosts should be the same on shared file systems -- for least surprise, and maximum utility.
 
Hi gpw928,

thank you for the explanation, I am arguably confusing issues.

The issue arose because as I was investigating the NFS mount and noticed that the server has inconsistent naming, wherein some directories/files have ownership user:user, but others have user:1004. In other words, some of the directories/files were created when GID was somehow associated with the name user (GID was named user?), but then the association/name was lost. Note that all the files were created by the same user. So, something must have happened.

The link that I posted suggested disassociation between the /etc/passwd, the /etc/pwd.db and the /etc/spwd.db.

To add to my confusion, my other (FreeBSD and OpenBSD) machines do have user:user as the UID and GID ownership. Can I manually edit the /etc/group file? Or, can I name the group with gid=1001 user?

Kindest regards,

M
 
With NFSv3, the UIDs and GIDs on participating hosts should be the same on shared file systems -- for least surprise, and maximum utility.
I think what you mean to say is this: With NFSv3, the UID -> user name mapping should be the same on all hosts. And the GID -> group name mapping should also be the same on all hosts, but it doesn't have to be the same as the user mapping. So for example if user 1001 = alice and user 1002 = bob, then it is perfectly fine if group 1001 = engineering, group 1002 = marketing, as long as those four assignments are used consistently across all nodes.

thank you for the explanation, I am arguably confusing issues.
Yes, I think you should learn a little bit about the fundamentals of users and groups.

The issue arose because as I was investigating the NFS mount and noticed that the server has inconsistent naming, wherein some directories/files have ownership user:user, but others have user:1004. In other words, some of the directories/files were created when GID was somehow associated with the name user (GID was named user?), but then the association/name was lost. Note that all the files were created by the same user. So, something must have happened.
Not necessarily "associated with". Could also be on a different host; or it could be that the mapping or the GID were changed.

Can I manually edit the /etc/group file?
Absolutely.

Here is a nutshell lesson: Each file (and directory and many other things) has two numeric fields which identify the ownership. They are called user and group, and are typically values between 0 and 65535. The only thing that is stored with the file metadata, and transmitted over NFS, are those two numbers. In reality, they are the only thing that matters. Want to see the numeric values? Use "ls -l -n".

On each computer, those two numbers are then mapped to nice human-readable strings. For user number -> user name, that is done in the file /etc/passwd. And for group -> group name, in /etc/group. If there is an entry missing for a user or group number, programs will just display the numeric value. Both files also have other information (/etc/passwd has lots of it, and it is super important, if you screw it up you can make your computer hard to fix), so be careful editing them. But in reality, as far as user/group mapping is concerned, these two files are only cosmetics; the real work is done with the numbers.

Unfortunately, there is no rule that these two files have to be the same on all machines that use NFS; and there is no rule that they should not have entries removed or changed while data exists that uses removed ID numbers. Sys admins just have to be careful.

Kindest regards,

M
[/QUOTE]
 
I think what you mean to say is this: With NFSv3, the UID -> user name mapping should be the same on all hosts. And the GID -> group name mapping should also be the same on all hosts, but it doesn't have to be the same as the user mapping.
Thank you. What I wrote was ambiguous.
transmitted over NFS, are those two [UID, and GID] numbers
True for NFSv3. In NFSv4, it's possible to use the names.
 
Hi gpw928,

thank you for the command, however, after sleeping on it, I decided to keep the group as a numeric value. In fact, I would pefer all the users groups to be numerical values.

Hi ralphbsz,

With NFSv3, the UID -> user name mapping should be the same on all hosts. And the GID -> group name mapping should also be the same on all hosts, but it doesn't have to be the same as the user mapping.
thank you, that is a good point.

Yes, I think you should learn a little bit about the fundamentals of users and groups.
I do believe to understand the UID/GID concept. What I was confused was why I was unable to map the numerical value of GID onto the human-readable name, which gpw928, clearly explained.

On each computer, those two numbers are then mapped to nice human-readable strings. For user number -> user name, that is done in the file /etc/passwd. And for group -> group name, in /etc/group.
My understanding was that when the file /etc/passwd is modified, preferably by pw(8) the change is propagated to the /etc/group. So I was surprised, that this was not the case. Because it would suggest to lead the following scenario. Upon initial user creation, the numerical UID and GID are mapped on human-readable string. Then the /etc/passwd is modified, e.g., to change the GID, but if the change is not propagated to the /etc/group, the file would show a wrong user to GID mapping. Or, am I missing a concept again?

Kindest regards,

M
 
My understanding was that when the file /etc/passwd is modified, ... the change is propagated to the /etc/group.
It is not automatically propagated. It is perfectly possible to edit both files with a standard text editor (see footnote below), and create a variety of nonsensical situations.

preferably by pw(8)
I don't know enough about pw to be sure that is makes consistent updates to passwd and group files. The fact that it has both usermod and groupmod functionality makes me think that one can use it to change either file independently; I would check both files by hand after using pw.

(Footnote: After editing /etc/passwd, don't forget to update the database version that are actually used for login and process creation, using pwd_mkdb; or just use vipw to edit that file.)

So I was surprised, that this was not the case. Because it would suggest to lead the following scenario. Upon initial user creation, the numerical UID and GID are mapped on human-readable string. Then the /etc/passwd is modified, e.g., to change the GID, but if the change is not propagated to the /etc/group, the file would show a wrong user to GID mapping. Or, am I missing a concept again?

Yes, you are missing a concept.

Let's start with user Alice who has UID 1001, and at birth is put into group 1001, which is called AliceGroup. File /etc/passwd will contain an entry for username=Alice which says that she has UID 1001 and her default group is 1001. File /etc/passwd says that group 1001 exists, and is named AliceGroup. Perfect.

Now you go into /etc/passwd and change Alice's default group to 1002. Say for example that GID=1002 also exists in /etc/group, and is called BobGroup. This is not a mistake! It could be a deliberate choice: From now on, when Alice creates files, they shall be stored in Bob's group. That could for example be if Alice has been moved to Bob's project at work, and is helping him, so the files should be owned by him. So this mapping is not necessarily "wrong". The reason is that /etc/group does not contain the user to GID mapping; it instead has the GID to group name mapping (and a few other things that are not terribly useful, unless you are sharing data and the last column in /etc/group becomes necessary).

On the other hand, in a world where each user has a group of their own, and they are not shared, that setting is probably a mistake. But Unix itself can't know that. Both scenarios (Alice is legitimately in BobGroup vs. Alice should be in AliceGroup) can be sensible.

But the really important thing is this: None of this affects files and directories already on disk. Say there is a home directory /home/Alice, which contains lots of files owned by UID=1001 and GID=1001. If you change Alice's UID and GID entries in /etc/passwd and /etc/group, those files will continue to be owned by 1001. For example, if GID 1002 is named AliceGroup now, and a new mapping 1001 -> AaronGroup is put into /etc/group, then it will correctly say that the files in /home/Alice are owned by AaronGroup. The mapping that happens in the /etc/ files is independent of the numbers stored in the files and directories.
 
Hi ralphbsz,

thank you for the time to write this.
It is not automatically propagated.
I always thought that it was because adduser(8) always creates a uid/gid pair. However, based on your writing, I have reread it, and it says:
The adduser utility is a shell script, implemented around the pw(8) command, for adding new users.

Yes, you are missing a concept.
Obviously, I was. In fact, I just came across a scenario that you describe cf., https://www.azabani.com/2021/09/24/freebsd-home-group-sharing.html, which I now understand with the help or your explanation and the note under the heading UNIQUE GROUPS in the adduser(8).

So today was not lost as I have learned something.

Kindest regards,

M
 
Back
Top