Recursive chown

I had email this morning from someone using "chown" to fix up permissions on a directory. He had discovered "-R" in the man page but had run into a small problem.

Let's say the directory was /usr/fred. He had done:

cd /usr/fred
chown -R fred:group *

He noted that had done pretty much what he wanted, but had ignored the "dot" files: .profile, .login etc.

So to fix that, he did:

cd /usr/fred
chown -R fred:group .*

That succesfully changed the ownership of the "dot" files, but had an unexpected (to him) side effect: /usr was also changed.

Of course that would be true, because ".*" includes ".." and the ".." of /usr/fred is /usr. A useful command flag seemed to be difficult or impossible to use as desired.

Well, that's not the case. The "-R" is perfectly happy to do the job if you invoke it like this:

cd /usr/fred
chown -R fred:group .
 

See the difference? Just ".", meaning current directory. That will correctly change all fles, including .login, .profile and everything else, but it won't touch ".." and therefore leaves /usr alone.

In this case, the misuse was noticed immediately and fixed, but I have often had panic calls from people where no one can login because of making this same mistake.

Actually, there's a little more to this. How did /usr/fred get the wrong ownership to start with? I looked more closely at the email and saw that "rcp" had been used to copy files from another system. It had been correctly invoked with "-p" and "-r", so the permissions and ownership should have been preserved.

However: rcp can't create users. If, for example, "fred" doesn't yet exist as a user on this new system, rcp can copy Fred's files from aother system (assuming proper access) but can't magically create files owned by Fred if "fred" doesn't exist here.

So the solution is to create all necessary users before using rcp. That would have avoided all of this.



Got something to add? Send me email.



14 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Fri Feb 27 09:32:01 2009: 5524   Vladimir

gravatar
Very helpful. Thank you!





Fri Feb 27 17:50:17 2009: 5531   OnkarJoshi

gravatar
Eeeks. Someone extracted, ran Tomcat, ActiveMQ, Apache httpd as root on one of the servers I am working on inside my normal application users home folders.

Your article served as a nice quick reference for recursive chgrp/chown.

Thanks.
OJ.



Tue Feb 2 21:31:41 2010: 8027   anonymous

gravatar


Hi, why the heck would you put code that you KNOW breaks stuff, and then AFTER the code, you explain that it breaks stuff? That is ridiculous. Thanks a lot. Serves me right for trusting you!



Tue Feb 2 21:51:22 2010: 8028   TonyLawrence

gravatar


Sigh..

So you don't read, you just charge ahead and type something that you don't understand?

And we are supposed to feel what? Sorry for you?

No.



Sat Feb 13 12:06:14 2010: 8081   marytee

gravatar


thanks for the useful information. This should prevent me from getting into trouble--at least as far as permissions go.



Sat Feb 27 10:37:38 2010: 8154   Bijuteriifantezie

gravatar


Founded your explanation about chown using google and was exaclty what I need. To modify chown rights for a lot of files and directory. Thank.



Mon May 23 05:57:53 2011: 9498   thomas

gravatar


Thank you, sir. No, I did not learn about the real details and wonders of recursively using chown. Instead, you saved me all of that and gave me some proper code. :]



Sun Mar 4 22:51:56 2012: 10708   anonymous

gravatar


chown -R user:group /path/to/the/dir works on all files, incl on dot files



Mon Mar 5 00:10:29 2012: 10709   TonyLawrence

gravatar


You aren't understanding this. Go back and read again.

The important thing to understand is that when he did

chown -R fred:group *



the '*" doesn't match files like ".vimrc" and so on. When he tried to fix that by using



chown -R fred:group .*



THAT matches . and .. which access th parent directory (..), creating this mess.







Mon Mar 5 15:23:11 2012: 10712   BigDumbDinosaur

gravatar


chown -R fred:group /usr/fred will produce the desired result.



Thu Aug 16 08:57:47 2012: 11239   Michael

gravatar


chown -R is safe in Linux and BSD Unix.
But in SysV Unix (Solaris, HP-UX, AIX): chown and chgroup follow symlinks!
Assume that user fred has created some symbolic links:

/usr/fred/mypasswd -> /etc/passwd
/usr/fred/mydir -> /
/usr/fred/michael -> ../michael

After a
chown -R fred:group .
/etc/passwd and / and /usr/michael will be owned by fred!
Therefore, SysV Unix needs
chown -hR fred:group

Also safe but slow is to skip the symlinks, using find:

find . \! -type l -exec chown fred:group {} \;

chmod follows symlinks in *all* Unix, so as an administrator please never use chmod -R !!
Instead get used to find! For Example:

find . \! -type l -exec chmod ug+rwx,o-w {} \;






Thu Aug 16 11:29:26 2012: 11240   TonyLawrence

gravatar


Interesting. I wouldn't call Linux "safe" (it's just handling symlinks differently - there is nothing safe or unsafe either way), but it is yet another example of how you have to be very careful when working in mixed environments.







Fri Feb 7 19:48:43 2014: 12416   Joe

gravatar


I'm embarrassed to admit I did exactly what you described. I realized the moment the chown didn't return immediately so I quickly killed it (still did enough damage). Worst of all I've been working on Linux platforms for over 10 years. I'm not sure what I was thinking...

------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us