chown in combination with symlinks
One of the things that writing Wandering Thoughts does is
give me the opportunity to be inaccurate in public. Yesterday I wrote
about how you should use '
chown, especially for recursive
chowns so that you don't change the ownership of
things that symlinks point to. As it happens, I was mistaken about some
aspects of the situation with
First off, I stand by my overall recommendation that you should
make a habit of always using '
chown -h'. Although using it with
-R is probably not necessary after all (on any modern system),
chown -h' remains the only way to safely chown all of the files
in a directory with eg '
chown -h user *' or '
chown -h user
*.html' or the like.
The situation with recursive chowns ('
chown -R') is a little less
obvious. First, as pointed out to me on Twitter, in
reality modern versions of GNU chown do not change what symlinks
point to with plain '
chown -R user dirtree'. Second, the POSIX
standard for chown
turns out to requires this behavior for '
chown -PR', so any version
chown that follows POSIX and has '
-P' as the default mode
-R' will behave this way even if its behavior isn't clear
from its manpage. All of OpenBSD, FreeBSD, and Illumos default
-P' this way. OpenBSD explicitly claims adherence to POSIX,
FreeBSD is unclear but probably behaves sensibly, and the Illumos
chown manpage explicitly and
clearly describes '
-P' as working like '
(It may be that my use of '
chown -hR' has always been somewhat
of a superstition, for all that the GNU
chown manpage uses it in an example.)
The bad news is that the clarity and explicitness of the Illumos
chown manpage and the POSIX specification is uncommon; other
people's documentation for
chown will generally leave you puzzled
and uncertain (or certain that they are actually dangerous). The
documentation for GNU chown, FreeBSD chown, and
OpenBSD chown all talk vaguely
about 'traversing' or 'following' symlinks and are written in the
context of descending through directory hierarchies. GNU chown even
has a section of its full documentation
which explicitly claims that '-P' is independent of '-h' and governs
only directory traversal.
It is technically true that calling '
chown(2)' on a symbolic link
causes the kernel to traverse or follow the symbolic link to change
the ownership of the target, and so in a very legalistic robot
logic way you could say that documenting
'-P' to not 'traverse' or 'follow' symlinks implies that chown won't
change the ownership of the target of symlinks. But I think very
few people are going to read it that way (and for GNU chown, you
are still left with the awkward fact that it explicitly rejects
All of this leads me to my overall recommendation that since all
of this is confusing, you should always use '
chown -hR' on
Unixes that support it, which is almost all of them except for
(GNU chown is probably not POSIX compatible here in general, but that's a complicated issue.)
Sidebar: The explanation for GNU chown's behavior
It turns out that the installed GNU chown manpage is more terse than the official documentation and this terseness leads it to be inaccurate. The versions of the chown manpage I have access to say, about the '--dereference' option:
affect the referent of each symbolic link (this is the default), rather than the symbolic link itself
The real full documentation here says instead (in part):
Do not act on symbolic links themselves but rather on what they point to. This is the default when not operating recursively.
The second sentence implies that -h is the default when operating
recursively, which reconciles the full documentation for -P with the
observed behavior of plain '
chown -R'. You should still use '
-hR', though. After all, the chown manual itself does.