1 .\" Copyright (c) 1992 Drew Eckhardt (drew@cs.colorado.edu), March 28, 1992
2 .\" and Copyright (c) 1998 Andries Brouwer (aeb@cwi.nl)
3 .\" and Copyright (c) 2006, 2007, 2008, 2014 Michael Kerrisk <mtk.manpages@gmail.com>
5 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
7 .\" Modified by Michael Haardt <michael@moria.de>
8 .\" Modified 1993-07-21 by Rik Faith <faith@cs.unc.edu>
9 .\" Modified 1996-07-09 by Andries Brouwer <aeb@cwi.nl>
10 .\" Modified 1996-11-06 by Eric S. Raymond <esr@thyrsus.com>
11 .\" Modified 1997-05-18 by Michael Haardt <michael@cantor.informatik.rwth-aachen.de>
12 .\" Modified 2004-06-23 by Michael Kerrisk <mtk.manpages@gmail.com>
13 .\" 2007-07-08, mtk, added an example program; updated SYNOPSIS
14 .\" 2008-05-08, mtk, Describe rules governing ownership of new files
15 .\" (bsdgroups versus sysvgroups, and the effect of the parent
16 .\" directory's set-group-ID mode bit).
18 .TH CHOWN 2 2021-08-27 "Linux" "Linux Programmer's Manual"
20 chown, fchown, lchown, fchownat \- change ownership of a file
23 .RI ( libc ", " \-lc )
26 .B #include <unistd.h>
28 .BI "int chown(const char *" pathname ", uid_t " owner ", gid_t " group );
29 .BI "int fchown(int " fd ", uid_t " owner ", gid_t " group );
30 .BI "int lchown(const char *" pathname ", uid_t " owner ", gid_t " group );
32 .BR "#include <fcntl.h> " "/* Definition of AT_* constants */"
33 .B #include <unistd.h>
35 .BI "int fchownat(int " dirfd ", const char *" pathname ,
36 .BI " uid_t " owner ", gid_t " group ", int " flags );
40 Feature Test Macro Requirements for glibc (see
41 .BR feature_test_macros (7)):
47 /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
48 || _XOPEN_SOURCE >= 500
49 .\" || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
50 || /* Glibc <= 2.19: */ _BSD_SOURCE
56 _POSIX_C_SOURCE >= 200809L
61 These system calls change the owner and group of a file.
67 system calls differ only in how the file is specified:
70 changes the ownership of the file specified by
72 which is dereferenced if it is a symbolic link.
75 changes the ownership of the file referred to by the open file descriptor
81 but does not dereference symbolic links.
83 Only a privileged process (Linux: one with the
85 capability) may change the owner of a file.
86 The owner of a file may change the group of the file
87 to any group of which that owner is a member.
88 A privileged process (Linux: with
90 may change the group arbitrarily.
96 is specified as \-1, then that ID is not changed.
98 When the owner or group of an executable file is
99 changed by an unprivileged user, the
103 mode bits are cleared.
104 POSIX does not specify whether
105 this also should happen when root does the
107 the Linux behavior depends on the kernel version,
108 and since Linux 2.2.13, root is treated like other users.
109 .\" In Linux 2.0 kernels, superuser was like everyone else
110 .\" In 2.2, up to 2.2.12, these bits were not cleared for superuser.
111 .\" Since 2.2.13, superuser is once more like everyone else.
112 In case of a non-group-executable file (i.e., one for which the
116 bit indicates mandatory locking, and is not cleared by a
119 When the owner or group of an executable file is changed (by any user),
120 all capability sets for the file are cleared.
125 system call operates in exactly the same way as
127 except for the differences described here.
129 If the pathname given in
131 is relative, then it is interpreted relative to the directory
132 referred to by the file descriptor
134 (rather than relative to the current working directory of
135 the calling process, as is done by
137 for a relative pathname).
147 is interpreted relative to the current working
148 directory of the calling process (like
159 argument is a bit mask created by ORing together
160 0 or more of the following values;
162 .BR AT_EMPTY_PATH " (since Linux 2.6.39)"
163 .\" commit 65cfc6722361570bfe255698d9cd4dccaf47570d
166 is an empty string, operate on the file referred to by
168 (which may have been obtained using the
174 can refer to any type of file, not just a directory.
179 the call operates on the current working directory.
180 This flag is Linux-specific; define
182 .\" Before glibc 2.16, defining _ATFILE_SOURCE sufficed
183 to obtain its definition.
185 .B AT_SYMLINK_NOFOLLOW
188 is a symbolic link, do not dereference it:
189 instead operate on the link itself, like
193 dereferences symbolic links, like
198 for an explanation of the need for
201 On success, zero is returned.
202 On error, \-1 is returned, and
204 is set to indicate the error.
206 Depending on the filesystem,
207 errors other than those listed below can be returned.
209 The more general errors for
214 Search permission is denied on a component of the path prefix.
216 .BR path_resolution (7).)
221 is not a valid open file descriptor.
230 nor a valid file descriptor.
234 points outside your accessible address space.
238 Invalid flag specified in
243 A low-level I/O error occurred while modifying the inode.
246 Too many symbolic links were encountered in resolving
254 The file does not exist.
257 Insufficient kernel memory was available.
260 A component of the path prefix is not a directory.
267 is a file descriptor referring to a file other than a directory.
270 The calling process did not have the required permissions
271 (see above) to change owner and/or group.
274 The file is marked immutable or append-only.
276 .BR ioctl_iflags (2).)
279 The named file resides on a read-only filesystem.
282 was added to Linux in kernel 2.6.16;
283 library support was added to glibc in version 2.4.
288 4.4BSD, SVr4, POSIX.1-2001, POSIX.1-2008.
290 The 4.4BSD version can be
291 used only by the superuser (that is, ordinary users cannot give away files).
293 .\" SVr4 documents EINVAL, EINTR, ENOLINK and EMULTIHOP returns, but no
294 .\" ENOMEM. POSIX.1 does not document ENOMEM or ELOOP error conditions.
296 .\" SVr4 documents additional EINVAL, EIO, EINTR, and ENOLINK
297 .\" error conditions.
302 .SS Ownership of new files
303 When a new file is created (by, for example,
307 its owner is made the same as the filesystem user ID of the
309 The group of the file depends on a range of factors,
310 including the type of filesystem,
311 the options used to mount the filesystem,
312 and whether or not the set-group-ID mode bit is enabled
313 on the parent directory.
314 If the filesystem supports the
317 .BR "\-o\ bsdgroups" )
321 .BR "\-o\ sysvgroups" )
323 options, then the rules are as follows:
325 If the filesystem is mounted with
327 then the group of a new file is made
328 the same as that of the parent directory.
330 If the filesystem is mounted with
332 and the set-group-ID bit is disabled on the parent directory,
333 then the group of a new file is made the same as the
334 process's filesystem GID.
336 If the filesystem is mounted with
338 and the set-group-ID bit is enabled on the parent directory,
339 then the group of a new file is made
340 the same as that of the parent directory.
347 mount options are supported by ext2, ext3, ext4, and XFS.
348 Filesystems that don't support these mount options follow the
352 On older kernels where
354 is unavailable, the glibc wrapper function falls back to the use of
360 is a relative pathname,
361 glibc constructs a pathname based on the symbolic link in
363 that corresponds to the
369 semantics are deliberately violated on NFS filesystems
370 which have UID mapping enabled.
371 Additionally, the semantics of all system
372 calls which access the file contents are violated, because
374 may cause immediate access revocation on already open files.
376 caching may lead to a delay between the time where ownership have
377 been changed to allow access for a user and the time where the file can
378 actually be accessed by the user on other clients.
379 .SS Historical details
385 system calls supported only 16-bit user and group IDs.
386 Subsequently, Linux 2.4 added
391 supporting 32-bit IDs.
397 wrapper functions transparently deal with the variations across kernel versions.
399 In versions of Linux prior to 2.1.81 (and distinct from 2.1.46),
401 did not follow symbolic links.
404 does follow symbolic links, and there is a new system call
406 that does not follow symbolic links.
407 Since Linux 2.1.86, this new call (that has the same semantics
410 has got the same syscall number, and
412 got the newly introduced number.
414 The following program changes the ownership of the file named in
415 its second command-line argument to the value specified in its
416 first command-line argument.
417 The new owner can be specified either as a numeric user ID,
418 or as a username (which is converted to a user ID by using
420 to perform a lookup in the system password file).
422 .\" SRC BEGIN (chown.c)
430 main(int argc, char *argv[])
436 if (argc != 3 || argv[1][0] == \(aq\e0\(aq) {
437 fprintf(stderr, "%s <owner> <file>\en", argv[0]);
441 uid = strtol(argv[1], &endptr, 10); /* Allow a numeric string */
443 if (*endptr != \(aq\e0\(aq) { /* Was not pure numeric string */
444 pwd = getpwnam(argv[1]); /* Try getting UID for username */
453 if (chown(argv[2], uid, \-1) == \-1) {
467 .BR path_resolution (7),