Hello everyone - I have a question regarding UID and GID numbers. First, a bit of background: Yesterday I suffered a complete power failure. My UPS batteries ran everything for an hour, but that was not long enough. My CentOS6 server shut itself down, just like it should. When the power came back up, the perfectly running server was no longer working. The boot hard drive was complete toast. ARGH! OK, I have backups and spare hard drives. CentOS6 is getting a bit long in the tooth. I have to reformat and reinstall CentOS before restoring backups anyway, so I decided now is the time to move to CentOS7. I chose to rip the bandage! The CentOS6 installation was quite old. Back in those days the default UID for new users was 500. That's how I set up my user account on the machine. My main workstation is Fedora 29, but it started life MANY cycles ago and also has my UID=500. That all works nicely with the nfs share coming off the server. On newer builds I have wrestled with having my UID=1000, as is the new standard. File permissions on the nfs share were never quite right. It was not irritating enough to make me desperate, but it was annoying. I got around it with a lot of 777 and 666 permissions settings. I looked at rpc-idmapd but was never able to make it work. Now with CentOS7 my server user account is UID=1000. The nfs share is on a separate drive (not the one that failed), and all of the files on it are still owned by UID=500. It works from my main workstation, but is really unclean. So now the questions: What will it take to change all the files to the new UID? What will it take to change my main workstation to the new UID **without** having to create a new user account? I think I can do this in two steps. 0) backup, backup, backup! 1) On the server - use "find" to find all files owned by UID=500. Chown them to UID=1000. Repeat for gid=500. 2) Tricky - On the workstation, boot to non-gui. Login as root. Repeat the same two "find" commands as on the server. Edit the /etc/passwd and /etc/group files to show the new UID and GID numbers. What does this do to the shadow files? Are there other places I need to look for the UID and GID numbers? Thanks! -- Bill Gee
On Thu, Feb 14, 2019 at 11:04:11AM -0600, Bill Gee wrote:> I think I can do this in two steps. > 0) backup, backup, backup!This is already running and you've tested the restore process, right?> 1) On the server - use "find" to find all files owned by UID=500. Chown > them to UID=1000. Repeat for gid=500.Yes.> 2) Tricky - On the workstation, boot to non-gui. Login as root. Repeat the > same two "find" commands as on the server. Edit the /etc/passwd and > /etc/group files to show the new UID and GID numbers.Yes. Although order does not matter -- personally I'd make the account change first. Also, you can use `usermod -u` and `usermod -g` (possibly both at once) and this will correctly change ownership of all files in the home directory (but not outside of that).> What does this do to the shadow files? Are there other places I need to > look for the UID and GID numbers?shadow (and gshadow) are name based, so shouldn't be a problem. You may need to change some spool files in /var in addition to in /home. Nothing else *should* be using the numeric values. (Possibly some tar files?) -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader
Hello everyone - Update: Many thanks to Matt Miller for the tip on usermod options. That worked very well! I did not know those options existed and would never have thought to look for them. After making and testing backups, I started with my main workstation. Rebooted in runmode=3, then ran the usermod -u and -g options. I did this in two runs. I first had to uninstall docker since it had taken over GID=1000. No big deal, I am not using it. After the usermod programs ran, I then did a "find -uid=500" with an exec option to change ownership. Repeat for changing GID. It found a few dozen files that were not in my home directory. Rebooted main workstation. Everything came back up, no errors. So far after about a day of use it is working just fine. On the server I ran the two "find" commands against the entire file system. It took about half an hour to run. No surprise there as it was finding and changing several hundred thousand files. I ran the uid change in one terminal and the gid change in another. Between the two of them they consumed about 90% on both processor cores. I did not reboot the server since I made no changes to the user account on it. Testing from several workstation - everything gets the permissions I expect. A few odd things that used to get blocked are now working. WooHoo! With all that done I made a fresh complete backup of the server. That backup should have all the new uid and gid associations in it. Next step is to revert to more sensible permissions. No more 777 and 666. That will take a while. It's not critical, so I will do it in spare (!) time. Thanks! -- Bill Gee On Thursday, February 14, 2019 11:45:33 AM CST Matthew Miller wrote:> On Thu, Feb 14, 2019 at 11:04:11AM -0600, Bill Gee wrote: > > I think I can do this in two steps. > > 0) backup, backup, backup! > > This is already running and you've tested the restore process, right? > > > 1) On the server - use "find" to find all files owned by UID=500. Chown > > them to UID=1000. Repeat for gid=500. > > Yes. > > > 2) Tricky - On the workstation, boot to non-gui. Login as root. Repeat the > > same two "find" commands as on the server. Edit the /etc/passwd and > > /etc/group files to show the new UID and GID numbers. > > Yes. Although order does not matter -- personally I'd make the account > change first. > > Also, you can use `usermod -u` and `usermod -g` (possibly both at once) and > this will correctly change ownership of all files in the home directory > (but not outside of that). > > > What does this do to the shadow files? Are there other places I need to > > look for the UID and GID numbers? > > shadow (and gshadow) are name based, so shouldn't be a problem. You may need > to change some spool files in /var in addition to in /home. > > Nothing else *should* be using the numeric values. (Possibly some tar > files?) > >