Resolved The "Chown" command -for fixing user-folder issues

[macstatic]

Can someone confirm if the following use of the "chown" (change ownership) command is correct (with the slash at the end or not)?
If I understand correctly the following should set the correct ownership for a user's home folder and all files/folders within:

$ sudo chown -R peter:staff /Users/peter/

I'm asking because I've had problems relocating a home folder as I've described/shown with screenshots, and having come across this thread where the above command was used it appeared to fix it, but I want to be completely sure before starting to copy files over.

 

[mfram]

In this case, it doesn't matter if the trailing slash is there or not. Yes, that is the proper syntax on the command.

 

[macstatic]

Thanks for confirming!

I noticed that the "Public" folder came out wrong (compared to other user accounts).
Is this the only exception when trying to fix ownership on a user folder? Will the above command make right everything else, or are certain folders/system files etc. supposed to have different ownerships than this will do?

 

[HDFan]

Be very careful what you do with permissions. Apple has a lot of extended attributes, requirements for what permissions should be on certain folders/files, etc. Make sure you have backups before you make changes.

 

[macstatic]

You mean "exceptions to the rule"? That some sub-folders or specific files may have completely different ownerships than the above command will take care of?

I came across something interesting: Maintain file ownership & priveleges when copying with duplicate exactly in Mac OSX. I had to give it a try, doing the following:

a) copy the original user folder from the SSD (select the user-folder in question, then press CMD-C to copy it)
b) locate and select the hard drive (and correct location on it) where I want to place the new copy, then do a "paste exactly" (by pressing CMD-SHIFT-ALT-V)

This resulted in a copy which seemingly did the exact same thing as doing a "drag & drop" from one drive to the other, but upon further inspection the file ownership was the same as the original (including the "Public" folder, something the use of the chown command above for the entire user-folder didn't handle right).
Finally all was confirmed working after selecting the new home directory in the "Users & groups" system preference, then logging into it.
Using this method appears to be the best possible solution.

 

[hobowankenobi]

If moving an entire user account/home folder...from an old machine (or a backup), the easiest way:

1. Verify the user account for the home folder to be migrated does not yet exist on the destination Mac.
2. Move the user folder from the source to the destination.
3. Create a new user account, being sure the user short name is EXACTLY the same as the just moved home folder name.
4. The OS will present an option to use the existing folder (or not); select the existing user home folder (that was just moved).
5. The OS will repair all permissions on the just moved user home folder back to the default standards, including both Posix and ACLs.

Bonus points: If you want to change the user name...be sure to change the moved user home folder name to the new short user name first, before doing step #3.

Log in as that user to verify. Easy peasy.

 

[Brian33]

I realize you have marked this resolved, but if you want to be really rigorous...

Did the "paste exactly" technique preserve the ACLs? You can check the ACL permissions by adding the '-e' option (and file flags with the '-O' option). For example: ls -lhFOe shows a lot of info!

I noticed that all the standard directories have an ACL, and Public/Dropbox has a whole raft of them! group:everyone deny delete seems popular, and a bunch of the subdirs in ~/Library have them. No idea if they're important, though!

 

[macstatic]

If moving an entire user account/home folder...from an old machine (or a backup), the easiest way:

I've tried to replicate this but I'm not sure I've understood all the details.

1. Verify the user account for the home folder to be migrated does not yet exist on the destination Mac.
2. Move the user folder from the source to the destination.

I assume you mean copy, not move?
Simply by dragging and dropping the home folder in question, or some other way?

1. Create a new user account, being sure the user short name is EXACTLY the same as the just moved home folder name.
2. The OS will present an option to use the existing folder (or not); select the existing user home folder (that was just moved).
3. The OS will repair all permissions on the just moved user home folder back to the default standards, including both Posix and ACLs.

So, go to the "Users & groups" system preferences and create the exact same user again, and when MacOS recognizes there's a home folder with that name already it'll ask if you want to keep the "old" one (i.e. the one you just copied over to the destination disk) or create a brand new home folder (effectively overwriting the one you copied over)?

Bonus points: If you want to change the user name...be sure to change the moved user home folder name to the new short user name first, before doing step #3.

Log in as that user to verify. Easy peasy.

You mean before step #1 (creating a new user (with the same name) in "Users & groups"?
So after copying over the home folder to the destination drive, click on the home folder's name, then change it (as you would do with any folder when inthe Finder), then go to "Users & groups" to create the new user (with that same name as you just changed it to)?

If I've understood things above correctly, would this procedure be possible to do with two different OS installations (either the same OS version on two separate drives, or two different OS versions on two separate drives)?
This would come in handy a while back when I had various problems and wanted to reinstall MacOS (a clean install on a different SSD) which is no problem, but then I had to create a new user and copy over all my old user files, documents etc. to that new user.
As I understand it I could simply "re-connect" my existing home folder by using the method above (creating a new user with the same name)?

 

[macstatic]

I realize you have marked this resolved, but if you want to be really rigorous...

Did the "paste exactly" technique preserve the ACLs? You can check the ACL permissions by adding the '-e' option (and file flags with the '-O' option). For example: ls -lhFOe shows a lot of info!

I noticed that all the standard directories have an ACL, and Public/Dropbox has a whole raft of them! group:everyone deny delete seems popular, and a bunch of the subdirs in ~/Library have them. No idea if they're important, though!

I didn't mark the subject as resolved, so better solutions (if any) are always welcome!
To check with those options, do you mean to issue the command while first inside the user's home folder, or while in the folder containing all the users (i.e. /Volumes/MacHD/Users/ )?

I tried the command in both instance, but don't know what to look for.
One interesting thing I did notice however, when issuing it from within the /Users/ folder was that some users had the same name (I assume owner) as the home folder's name while others didn't. My guess is

$ ls -lhFOe
total 0
drwxr-xr-x+ 17 john  staff  -  578B Mar 19 12:06 john/
 0: group:everyone deny delete
drwxr-xr-x@ 27 xyz       staff  -  918B Mar  6 10:25 power/
drwxr-xr-x+ 11 phil     admin  -  374B Mar  1 13:44 phil/
 0: group:everyone deny delete
drwxr-xr-x  12 john  staff  -  408B Jan  8 10:25 justin/
$

 

[Brian33]

To check with those options, do you mean to issue the command while first inside the user's home folder, or while in the folder containing all the users (i.e. /Volumes/MacHD/Users/ )?

I'd run the command within /Users (to show each users' home directory), /Users/john (for example, to show john's top-level directories), and /Users/john/Public (to show the Dropbox directory, which has a bunch of ACL permissions). If those all looked good, I'd assume the copy was faithful.

I tried the command in both instance, but don't know what to look for.

I was thinking you could visually compare the output of the command for your original home directory and the copied home directory. Ideally there would be no differences (at least none that can't be explained, like date/timestamps, for example). See below to interpret the output.

One interesting thing I did notice however, when issuing it from within the /Users/ folder was that some users had the same name (I assume owner) as the home folder's name while others didn't.

Yeah, some of your users' home directories seem non-standard, to me. In my experience, the ownership always matches the name of the home directory, which always matches the (short) username. You have home directory 'power' owned by user 'xyz', and home dir 'justin' is owned by user john. I'm not saying you can't have it that way, but is that what you intended? Seems to me there should be a good reason for diverting from the typical.

Home dir 'john' and home dir 'phil' appear as I'd expect for users john and phil, including the typical ACL permission (which is missing on the others -- though again, note that I'm not sure it's important).

$ ls -lhFOe
total 0
drwxr-xr-x+ 17 john  staff  -  578B Mar 19 12:06 john/
0: group:everyone deny delete
drwxr-xr-x@ 27 xyz       staff  -  918B Mar  6 10:25 power/
drwxr-xr-x+ 11 phil     admin  -  374B Mar  1 13:44 phil/
0: group:everyone deny delete
drwxr-xr-x  12 john  staff  -  408B Jan  8 10:25 justin/
$

In the ls -lhFOe command output here are some important points:

• The name of the directory or file is on the far right (I know it doesn't make much sense).
• The first column shows 'd' for directories and '-' for regular files.
• The next nine letters are three groups of three indicating the POSIX (unix-style) permissions on the item, for the owner, group members, and others. These correspond to what people usually mean by file "permissions" and I think is what you see in Finder's "Get Info" windows in the Sharing & Permissions section.
• Then there may be a '+' indicating there is some ACL info, or a '@' indicating extended attributes (which we haven't even talked about!)
• I've forgotten what the next number is -- I think it's irrelevant for this discussion.
• But the next two "words" are important: the owner of the file/directory and the group name (well, one of them anyway) that may be able to affect that file/directory.
• The next line (beginning with '0:') shows the list of ACL (Access Control List) permissions for the preceding file/directory. I don't know any other way of examining ACLs on a stock system (although I think the "Tinker Tool System" program has a GUI for them).

So looking again at your output's last line, you can see that a home directory called 'justin' is owned by a user named 'john'. If this is supposed to be the home dir for a user named 'justin' I think that will cause permission problems. Perhaps that's one you copied over in some manner?

If I wanted the most exact copy, I would want to see the POSIX permissions and ACLs and owner and group names all be the same between the original source and the copy.

OTOH, if what you've done works when you log into the accounts, it might be good enough. I just thought you might be interested in a more detailed comparison of the copying methods.

I didn't mark the subject as resolved

Somehow it got marked Resolved, but I wouldn't worry about it! Those prefixes don't seem to be used much anyway...

 

[hobowankenobi]

I assume you mean copy, not move?
Simply by dragging and dropping the home folder in question, or some other way?

Yes, correct. Technically a copy. I should have been more clear. Moving is possible but gains nothing, and in fact is a risk...as if there is any issue, there is no do-over.

 

[hobowankenobi]

You mean before step #1 (creating a new user (with the same name) in "Users & groups"?
So after copying over the home folder to the destination drive, click on the home folder's name, then change it (as you would do with any folder when inthe Finder), then go to "Users & groups" to create the new user (with that same name as you just changed it to)?

Yes. If the existing folder (the one just moved) is named exactly the same as the user short name, the OS will use that (assuming the user selects this option upon being prompted). It will assign it to the user being created, and update/repair all permissions.

It will not make a new user home folder...unless the user DOES NOT choose to use it. If the user does not select the existing home folder, a new default home is made, and the moved folder is renamed and retained.

In this case, one could rerun the process, by deleting the new user, rename the folder as needed, and creating the user again. Nothing lost or risked.

 

[hobowankenobi]

If I've understood things above correctly, would this procedure be possible to do with two different OS installations (either the same OS version on two separate drives, or two different OS versions on two separate drives)?
This would come in handy a while back when I had various problems and wanted to reinstall MacOS (a clean install on a different SSD) which is no problem, but then I had to create a new user and copy over all my old user files, documents etc. to that new user.
As I understand it I could simply "re-connect" my existing home folder by using the method above (creating a new user with the same name)?

Yep. One can consolidate many accounts on another Mac by simply copying existing home folders before user accounts creation.

The only caveat that I am aware of: The OS must be the same or newer, NOT older. Some things like Mail and Calendar databases get upgraded, but there is no (easy) downgrade.

I do this on lab computers with 20+ accounts. As an admin user, drag (copy) all user home folders to new Mac. Users log in for the first time (create a new account), but get all their history and data in the moved home folder. Works even users are standard (non-admin)....no passwords, no permissions issues.

 

[hobowankenobi]

For viewing and fixing home directory ACLs and POSIX with an easier interface...there used to be a few free and shareware tools, but I think all have gone bust sadly. There is one talked about here, but I have not used it yet.

On a brighter note, Apple has added a repair feature within recovery mode.

Tinkertool System is the only 3rd party tool I am aware of that does full permission reporting and mods via a nice GUI. Scroll down to see the screenshots of the ACL inspector here. There is a free time-limited demo...should be enough to resolve a one-time problem!

 

[macstatic]

I was thinking you could visually compare the output of the command for your original home directory and the copied home directory. Ideally there would be no differences (at least none that can't be explained, like date/timestamps, for example). See below to interpret the output.

Ah! Yes, visually comparing folders is a good idea. Thanks for your thorough explanation!
Obviously it would be a lot of work to compare every folder and sub-folder for a user, but it's good to know what to do when you want to check one or two.

Yes, a couple of home folders yield very strange result. One of them is from a different 10.13 High Sierra installation and I've been messing with permission changes back and forth because of problems, then probably making things worse because I didn't know what to do
So now I've completely reinstalled High Sierra (on a different SSD), then created new users as well. And in order to transfer the old user files I booted into the "old" High Sierra setup, and from my old user account copied my files over to my new account's "Public" folder.
Then I rebooted into my "new" High Sierra setup, logged into my new user account, then moved the files over to their appropriate locations (Pictures, Documents etc.). That appeared to fix their file permissions/ownerships to my new account. I did all this in several chunks (so as not to fill up my HDD with two copies of everything, in addition to my Time Machine backups). Seems to work fine.

 

[macstatic]

For viewing and fixing home directory ACLs and POSIX with an easier interface...there used to be a few free and shareware tools, but I think all have gone bust sadly. There is one talked about here, but I have not used it yet.

On a brighter note, Apple has added a repair feature within recovery mode.

Tinkertool System is the only 3rd party tool I am aware of that does full permission reporting and mods via a nice GUI. Scroll down to see the screenshots of the ACL inspector here. There is a free time-limited demo...should be enough to resolve a one-tie problem!

Thanks for clearing things up! I will try to "link" my old user account to my "old" High Sierra setup once I'm 100% sure I've transferred all my files over to the new account/new setup and see what comes of it.

Transferring the various files and folders within "Documents", "Pictures" etc. isn't any problem, but certain proprietary files deeply hidden in the system and stuff I've installed which isn't obvious right away is a challenge. I want to be 100% sure I have everything before I
For now I've rebuilt everything from scratch and manually transferred things over, but the next time something goes wrong I will know what to do, and I can avoid having to go through this very time consuming re-install/move everything process.
I already have TinkerTool (for configuring various things, similar to Onyx and other tools), but wasn't aware of the additional functions in the paid version, so this might be worth considering. I've also used BatchMod (shown on that page with free/shareware tools you linked above), but you really have to know a bit about what you're doing (which I can't say I do -at least not which folders/files should have what kind of ownership). I think I used it in High Sierra, but I can't say for sure. If they're all outdated in the sense that they don't properly work with High Sierra it's better to go for Tinkertool System. I'll give the demo a go first (it appears version 5 is what works with High Sierra as the current version 7 needs MacOS 10.11 Big Sur or later).
Also, I didn't know about the recovery mode repair feature. Thanks for all those useful comments and suggestions!

 

[macstatic]

Yes. If the existing folder (the one just moved) is named exactly the same as the user short name, the OS will use that (assuming the user selects this option upon being prompted). It will assign it to the user being created, and update/repair all permissions.

It will not make a new user home folder...unless the user DOES NOT choose to use it. If the user does not select the existing home folder, a new default home is made, and the moved folder is renamed and retained.

In this case, one could rerun the process, by deleting the new user, rename the folder as needed, and creating the user again. Nothing lost or risked.

OK, I'm going to try this out as my old home folder has now got all its relevant files copied over to the new home folder, so if something goes wrong it's no biggie.
First however I'd like to mention that the "recovery mode repair" you mentioned earlier didn't work for me because it only caters for home folders on the boot drive. My users are on a separate and much larger HDD and not the boot-SSD.

So, I create a new user with the exact same name as the "old" home folder (the one with all the ownership issues). This of course creates that user on the SSD and thus doesn't encounter a user by the same name (the "old" home folder is on the HDD).
At this stage, should I just proceed with creating this user on the SSD, then when that's done, right-click for "Advanced options" for that user and select the home directory path to where my "old" home folder is? I'm guessing at that stage I'll be alerted that there's a user by the same name there etc.?


PS: I think I understand why my "old" home folder shows such strange permissions: because it belongs to another instance of MacOS (same 10.13.6 version, but on two different SSDs, and the "old" home folder was created while booting into my "old" MacOS 10.13.6 High Sierra). When I boot into my "new" 10.13.6 the permissions are all wrong and meaningless, but if I reboot into the "old" OS and log into the "old" home folder the permissions look fine!

I want to try out your suggestions to see if I can make the "old" home folder usable with the "new" OS (i.e. all permissions get fixed).

By the way: I found this page which explains in layman's terms what the correct permissions are for the various folders in MacOS!

 

[hobowankenobi]

Good points.

As for the user home on a different volume... the way you have it set up is tried and true, but as you point out, has its own challenges and limitations.

You could let the OS build a new default home folder (from the OS template), and then move data into the default folders (Documents, Photos, Movies, etc). Can't say for sure if that is 100% effective, but I expect it could be. The user Library contents could get messy.

I have never tried, but it might be a worthwhile test to create a symbolic link to the remote home folder, and drop in the default location (/Users directory on the boot drive). Once the symlink is there, one creates the new user...at which point the OS would see the correct directory (the symlink), and would then reset permissions on the actual folder.

Hypothetically.

I have done this before without issue for shared libraries (iTunes, Photos, etc.) that I wanted multiple users to have access to.

I may actually test the symlink idea for entire home folders. Would be good to know. If it works as expected, it would be easier and safer for home directories housed on different volumes.

 

[macstatic]

I'll look into symlinks, but gave the method we discussed earlier a try (creating a new user with the same name as the already existing "old" user, then changing the path over to where the "old" home folder was located and finally pressing OK). Nothing happened at that stage, but I haven't proceeded by rebooting and logging into that account to see.
When I have some more time it may be worth a go, but it doesn't look like this will fix any incorrect permissions.

 

[macstatic]

Well, I had to give it a go (adding the "old" user account to my "new" setup), so I did as follows:

1) created a new account (on the SSD) with the exact same short-name as my "old" home folder

2) still within "Users & groups" system preferences; I right-clicked on the "old" username to get to "Advanced options" where I changed the path to my home folder. So now it goes to the HDD, pointing to the home folder I had from before (and used with the "old" MacOS 10.13.6 installation

3) Time for testing! I logged out, then logged into the "old" user account. There I was (not surprisingly) met with all sorts of MacOS error messages asking me to fix this and that (none of them fixed anything anyway), so in the end I just had to log out (which was a hassle in itself, but I was finally able to do it).

4) So now I logged into my normal user account again, in order to try to fix permissions of the "old" account

5) At this stage I decided to try "Tinkertool System" as you had suggested. I found it a bit complex and "geeky", hard to understand for the casual user, but in the end I tried to "Propagate permissions" which appeared to mean "Fix permissions" or so it seems when I did some comparisons between my regular user and the "old" one. I could probably use "Batchmod" too, but would have to know the correct permissions first. I assume Tinkertool System simply "fixes" it to their correct values.

6) so now I log out, then in to the "old" account again and it works (well, so far, so good anyway).
EDIT: I had to redo the permissions with Batchmod as I obviously didn't understand Tinkertool System. I compared the permissions with my normal, working user account.

In summary: I've managed to "link" an already existing home folder to the login window! Having known this a while back would have saved me lots of work, but better late than never

 

[hobowankenobi]

Yeah, Default Apple permissions (at the least the invisible "deny" ACLs) are tricky, and not obvious. Getting them right for the average user is hard enough when they are visible via a tool like TT System.

Some of the ACLs seem to be set to protect users from themselves, so they (we) can't do much damage. More about data and OS safety from user damage or destruction than actual security.

It certainly makes sense why many elect to simply remove the ACLs and run the less complicated POSIX permissions only. As long as one is not file sharing with other platforms (Win in particular), running without ACLs makes a lot of sense regarding ease of correcting any permissions issues.

 

[macstatic]

Yeah, Default Apple permissions (at the least the invisible "deny" ACLs) are tricky, and not obvious. Getting them right for the average user is hard enough when they are visible via a tool like TT System.

Good to know it's not just me
Yes, this stuff is complex and I was hoping there was an app or Terminal command consisting of "fix all permissions to their correct default values", then forget all about it and get on with other things
Apparently there is no such thing around for some strange reason, myself thinking this was a standard which every user account would stick to (i.e. the permissions Apple gives each newly created user by default).

I found out that Tinkertool System didn't fix this properly (or most likely I didn't understand how to use it -it's probably a nice tool for IT techs and such), so I used BatchMod and fixed each user account's folders by comparing it with one I knew was working. A little more time consuming, but at least the folders now have their correct permissions. I'm not sure about all the contents (files, sub-folders) of those folders, but so far everything appears to work as it should.

Home dir 'john' and home dir 'phil' appear as I'd expect for users john and phil, including the typical ACL permission (which is missing on the others -- though again, note that I'm not sure it's important).

Well, since I used BatChmod then checking my user accounts with the "ls -lhFOe" command I can say it looks a whole lot better now. The only exception is that one user has "admin" written next to it while the others have "staff" (which is strange since those also have admin access. Then there's the difference of @, + or nothing at all at the end of the POSIX permissions row, but as I understand from an earlier comment of yours this isn't critical info.

On another note, getting back to my posting #5 where I had discovered the "paste exactly" feature of MacOS which would retain all permissions correctly. Well, there might be another way, according to a reply I got from a posting of mine entitled "Relocating a user to a different drive WITHOUT ownership issues?".
If I've understood the reply correctly there may be a simpler way to relocate a user to a different drive AND retain the correct permissions. Correct me if I'm wrong though:

a) (within the "Users & groups" preferences) create the new user (which in my case will be on the boot-SSD by default)

b) log out of the account you're currently using, then log into the new account

c) while logged into the new account, drag that the new account's home folder over to where you want it relocated (in my case the main HDD)

d) go back to the "Users & groups" preferences, right click on the new account's name, then change the path to its new location (the HDD).

e) reboot

f) log into the newly created account


This is basically what I've done all along, but I did the opposite of what I highlighted in red in steps b and c. So by copying the home folder over to the new location while actually using that same account I assume that would retain the correct ownerships since I'd be the same user of it, right?
I've got to try that when I get the time, and could skip the "paste exactly" feature, instead just copying the normal way in the Finder (drag & drop the home folder).