Owner/permissions issue

[Cor anglais 16]

My wife and I recently consolidated our user accounts (we realized after several years that we really don't need two separate accounts on our iMac) by copying all my files to her home folder and erasing my account and home folder. Then I used

sudo chown -R $username ~$username

to change the owner of all my files to her (overkill, I know, but I thought it wouldn't hurt—famous last words). Now I can open all my files but can't edit any of them. ls -l shows my wife as the owner of everything, but various permissions of something like drwxr-xr-x+ or -rw-r--r--@ or other permutations, depending on the file.

I would think that chown would provide me all the permissions I need to edit the files by itself. Using chmod to set universal home folder permissions of rwxrwxrwx seemed dangerous. But is this what I need to do after all?

 

[chown33]

The expression ~$username, assuming that's literally what you entered, doesn't expand to a directory.

Also, unless you set username beforehand, it's an undefined shell variable.

Illustrations:

echo $USER ~ $HOME
echo $username  # This will show nothing if username is unset

EDIT

I recommend the -v option to chown, so you can see what it does.

I also recommend reading the man page for 'ls', so you can see the options to get it to show you ACLs. ACLs are basically fine-grained extended permissions.

 

[Floris]

chown doesn't seem to do recursive on directories.

 

[KALLT]

s -l shows my wife as the owner of everything, but various permissions of something like drwxr-xr-x+ or -rw-r--r--@ or other permutations, depending on the file.

I would think that chown would provide me all the permissions I need to edit the files by itself. Using chmod to set universal home folder permissions of rwxrwxrwx seemed dangerous. But is this what I need to do after all?

No, you should not recursively overwrite all permissions like that. The permissions are fine. All you need are the first three bits, the others are irrelevant for the user directory. Both examples you gave should work. You should try this command and see whether there are any access-control restrictions or file flags:

ls -leO ~

chown doesn't seem to do recursive on directories.

No, it does. That is what the -R option is for. The command as given by the OP just makes no sense. Even assuming that they used a variable for the username, ~$username would still be wrong.

The correct command would be:

sudo chown -R username ~

~ refers to /Users/username/ of the user who executes the command
~username would lead to /Users/username/username

I am a bit surprised though that the command could be used at all. chown exits with an error if the username or target file/directory does not exist.

 

[Floris]

I have the same problem on my external drive, and -R didn't work for me on El Capitan . No matter what I tried. It applied it to the main dir, but no dirs or their files inside of it.

I use: chown -R floris staff /Volume/Media2

 

[KALLT]

File ownership in volumes is weird when volume ownership is disabled/ignored. Everything effectively belongs to you already. If file ownership is important to you, then you must keep it enabled, at which point everything belongs to root. You can do that by right-clicking on the volume, select ‘Get Info’ and uncheck the box at the bottom (might need to unlock first).

 

[Floris]

File ownership in volumes is weird when volume ownership is disabled/ignored. Everything effectively belongs to you already. If file ownership is important to you, then you must keep it enabled. You can do that by right-clicking on the volume, select ‘Get Info’ and uncheck the box at the bottom (might need to unlock first).

That's indeed how i resolved it when i moved an external drive from my old mac pro to the imac.
By saying [x] ignore ownership. It's nothing personal on there, just some media (b-roll stuff for clips) so i didn't feel too bad about risking permission issues or 'free for all' idea.

 

[Cor anglais 16]

The expression ~$username, assuming that's literally what you entered, doesn't expand to a directory.

Also, unless you set username beforehand, it's an undefined shell variable.

I didn't literally type $username, I just used that for purposes of posting the code here. (I hope that nobody would be so dim as to literally type "$username" into the shell and think it would work!)

The correct command would be:

sudo chown -R username ~

I'll give this a try later today and see what happens, and let you know.

 

[chown33]

I didn't literally type $username, I just used that for purposes of posting the code here.

All we know is what you tell us. For example, we can't tell what your experience with shell or other languages is unless you tell us. If you said you typed something in, then my starting premise is that what you tell us you did is actually what you did. Hence my comment.

If you use a metasyntax that looks like shell expressions, then my first guess is that you're posting an actual shell expression. If you'd used a simpler metasyntax with a placeholder name, such as:

sudo chown -R wifename ~wifename

Then at least it would have been clear that no actual $'s were involved.

(I hope that nobody would be so dim as to literally type "$username" into the shell and think it would work!)

I don't think it's a question of being "dim", more one of inexperience or unawareness.

For example, see this thread, which I'd say falls under inexperience:
https://forums.macrumors.com/threads/i-need-help-with-terminal.1994613/

Summary: some pasted code contained curly ("smart") quotes, because the original website didn't take "quote smartening" into account.

The originating website is written by a University Computer Science professor, so it's understandable why someone without experience might take it literally. I'd give the professor a D for inadequate attention to detail in something that will be widely read by inexperienced users.


Another example is in post #4, where KALLT wrote:

~username would lead to /Users/username/username​

This turns out to be incorrect. The expression ~username will expand to either the literal string "~username", or if there's a user whose actual literal username is "username", then it will expand to the home dir of that user. Here are some examples to try:

echo ~username
echo ~/username
echo ~nobody
echo ~root

Note the subtle but important difference between the first two.

Based on this, do I think KALLT is dim? Nope.
Do I think he's inexperienced? Nope.
Do I think he might be unaware of all the details of exactly how ~expressions are evaluated? Yup.

 

[Cor anglais 16]

Tried the suggested command, adding -v to keep an eye on everything. Owner was changed successfully, unfortunately there's no change in my inability to edit the files! One file selected at random has permissions of rw-r--r--@. Does the @ indicate an access control list that needs to be disabled? Also, ls -a returns "staff" after the owner's name. Does that indicate that the owner belongs to a different user group than one that is allowed to edit the file?

 

[chown33]

Tried the suggested command, adding -v to keep an eye on everything. Owner was changed successfully, unfortunately there's no change in my inability to edit the files! One file selected at random has permissions of rw-r--r--@. Does the @ indicate an access control list that needs to be disabled?

The '@' does indicate an ACL. Whether it needs to be disabled depends on what access it defines. To see the ACL, use:

ls -l@

If you use that command on a directory, the ACLs of every listed file will be shown.

Also, ls -a returns "staff" after the owner's name. Does that indicate that the owner belongs to a different user group than one that is allowed to edit the file?

No, it indicates that the file's owning group-id is "staff". That is, members of the group "staff" who aren't the owning user will be granted access defined by the "group" part of the access permissions. This is a completely different question than whether the owning user of a file belongs to a group.

To find out if a user is a member of a group, use the 'id' command.


For file access, the resulting access hierarchy will be:
1. If the effective user-id matches the file's owner, apply the "user" part of the access permissions.
2. Otherwise, if the effective group-id matches the file's owning group-id, apply the "group" part of the access permissions.
3. Otherwise apply the "other" part of the access permissions.

https://en.wikipedia.org/wiki/File_system_permissions#Traditional_Unix_permissions

The ACL permissions are also applied, but I'm pretty sure they're supplementary, i.e. after one of the three main access permissions has been selected and applied.

The man page for chmod explains ACLs.

 

[Cor anglais 16]

The '@' does indicate an ACL. Whether it needs to be disabled depends on what access it defines.

Thanks—as it turns out the ACL were the issue. I used chmod -RN to disable them, and everything seems to be working as it should.