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.

13 comments

More Articles by Anthony Lawrence - Find me on Google+

Click here to add your comments




Fri Feb 27 09:32:01 2009: 5524   Vladimir
http://strixbg.blogspot.com

Very helpful. Thank you!





Fri Feb 27 17:50:17 2009: 5531   OnkarJoshi
http://onkarjoshi.wordpress.com/

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




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




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




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
http://www.allbijoux.ro



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




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




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




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
http://bcstechnology.net



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



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




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




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.





Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.