Ubuntu Version:
26.04 LTS
Desktop Environment (if applicable):
Server version
Problem Description:
I have just recently installed ubuntu 26.04 LTS server for test and observed that the command sudo chown -R username: userfile which is a short form and supposed to behave as sudo chown -R username:username userfile and change the user and group owner of userfile to username but only the user was changed, is this the new rust implementation and expected behaviour?
It seems it is the new rust coreutils but I doubt itâs expected behaviour, because they are meant as a drop-in replacement and differences between GNU coreutils and rust-coreutils are considered bugs. You can report this by running:
ubuntu-bug rust-coreutils
The bug has already been reported upstream. There is also this LP bug report, so maybe just report that you are affected too, @hypoclone.
The command did what you told it to, just change the username. If you want to change the group name, you need to indicate that also. Ubuntu sets user:group to the same name so that if you had a user âbobâ, you would do: sudo chown bob:bob userfile. Also, you donât need the â-Râ as that is for recursive and is used on directories when you want to chown files/directories within the top directory.
No, what @hypoclone wants is whatâs documented in chown(1) (noble):
If a colon but no group name follows the user name, that user is made the owner of the files and the group of the files is changed to that userâs login group.
oh thank you @peterwhite23 ! but i donât think such bug can be captured by ubuntu-bug rust-coreutils or i do not know how to use that, i think i will just use github if that is ok
Iâve updated my post, regarding the bug report.
FWIW, that tool doesnât âcaptureâ bugs. Itâs a helper for creating good reports with relevant system info etc. already attached. Itâs still up to the reporter to describe the issue.
⊠that user is made the owner of the files and the group of the files is changed to that userâs login group.
Given that user1 is in group thatgroup, the above says that
chown user1: thisfile
should result in the changes applied being
chown user1:thatgroup thisfile
and not
chown user1:user1 thisfile
Am I wrong?
The âlogin groupâ has the same name as the user, so sudo chown user1: is equivalent to sudo chown user1:user1, which is probably the reason for this GNU extension on the POSIX standard. Itâs just a minor convenience optimization, which I didnât even know existed until very recently.
Peter, I am sorry, but that is a mistaken assumption.
It is possible that it might be the same, if you use system installation defaults for the installerâs ID, and the installer did not choose, for reasons of their own, to change those to something that makes it harder for bad actors to do things, or to make it fit into a framework of role-based ACLs. There is no guarantee that they are the same.
So, âI am sticking to my gunsâ with my original comment, claim!
The scenario that you describe is a âhappy accidentâ, if nothing is changed post-install.
One would hope that omitting the group doesnât actually change the desired command from chown to chmod automatically though 
Thank you, Ogra, for catching that âfaux pasâ! Senior moment! My bad! I corrected that to avoid any misunderstanding!
You are right:
$ touch somefile
$ sudo useradd -g adm testuser
$ sudo chown testuser: somefile
$ ls -l somefile
-rw-r----- 1 testuser adm 0 May 28 20:41 somefile
I somehow got it into head that the login group would always be named after the user; donât know why; must have been something Iâve read ages ago and/or remembered wrong. Thanks for setting me straight!
This topic was automatically closed 18 hours after the last reply. New replies are no longer allowed.