IPB
>  Man Pages > Linux > Suse Linux 10.1 > Section 2 > chown man page

chown man page

Section 2 - Suse Linux 10.1 Man Pages

Other operating system man pages available here


Advanced Search

Hopefully, this page is exactly what you are looking for, but if not, you can always find further assistance on Unix/Linux Forum!


CHOWN(2)                   Linux Programmer's Manual                  CHOWN(2)




NAME

       chown, fchown, lchown - change ownership of a file


SYNOPSIS

       #include <sys/types.h>
       #include <unistd.h>

       int chown(const char *path, uid_t owner, gid_t group);
       int fchown(int fd, uid_t owner, gid_t group);
       int lchown(const char *path, uid_t owner, gid_t group);


DESCRIPTION

       These  system calls change the owner and group of the file specified by
       path or by  fd.   Only  a  privileged  process  (Linux:  one  with  the
       CAP_CHOWN  capability)  may change the owner of a file.  The owner of a
       file may change the group of the file to any group of which that  owner
       is  a  member.  A privileged process (Linux: with CAP_CHOWN) may change
       the group arbitrarily.

       If the owner or group is specified as -1, then that ID is not  changed.

       When  the  owner  or  group of an executable file are changed by a non-
       superuser, the S_ISUID and S_ISGID mode bits are  cleared.  POSIX  does
       not specify whether this also should happen when root does the chown();
       the Linux behaviour depends on the kernel version.  In case of  a  non-
       group-executable  file  (with  clear S_IXGRP bit) the S_ISGID bit indi-
       cates mandatory locking, and is not cleared by a chown().



RETURN VALUE

       On success, zero is returned.  On error, -1 is returned, and  errno  is
       set appropriately.


ERRORS

       Depending  on  the file system, other errors can be returned.  The more
       general errors for chown() are listed below.

       EACCES Search permission is denied on a component of the  path  prefix.
              (See also path_resolution(2).)

       EFAULT path points outside your accessible address space.

       ELOOP  Too many symbolic links were encountered in resolving path.

       ENAMETOOLONG
              path is too long.

       ENOENT The file does not exist.

       ENOMEM Insufficient kernel memory was available.

       ENOTDIR
              A component of the path prefix is not a directory.

       EPERM  The  calling  process did not have the required permissions (see
              above) to change owner and/or group.

       EROFS  The named file resides on a read-only file system.

       The general errors for fchown() are listed below:

       EBADF  The descriptor is not valid.

       EIO    A low-level I/O error occurred while modifying the inode.

       ENOENT See above.

       EPERM  See above.

       EROFS  See above.


NOTES

       In versions of Linux  prior  to  2.1.81  (and  distinct  from  2.1.46),
       chown()  did  not  follow  symbolic links.  Since Linux 2.1.81, chown()
       does follow symbolic links, and there is a  new  system  call  lchown()
       that does not follow symbolic links.  Since Linux 2.1.86, this new call
       (that has the same semantics as the  old  chown())  has  got  the  same
       syscall number, and chown() got the newly introduced number.

       The  prototype for fchown() is only available if _BSD_SOURCE is defined
       (either explicitly, or implicitly, by  not  defining  _POSIX_SOURCE  or
       compiling with the -ansi flag).


CONFORMING TO

       The  chown()  call  conforms  to SVr4, SVID, POSIX, X/OPEN.  The 4.4BSD
       version can only be used by the superuser (that is, ordinary users can-
       not  give away files).  SVr4 documents EINVAL, EINTR, ENOLINK and EMUL-
       TIHOP returns, but no ENOMEM.  POSIX.1  does  not  document  ENOMEM  or
       ELOOP error conditions.

       The  fchown()  call  conforms to 4.4BSD and SVr4.  SVr4 documents addi-
       tional EINVAL, EIO, EINTR, and ENOLINK error conditions.


RESTRICTIONS

       The chown() semantics are deliberately violated  on  NFS  file  systems
       which  have  UID  mapping  enabled.  Additionally, the semantics of all
       system calls which access  the  file  contents  are  violated,  because
       chown()  may  cause  immediate access revocation on already open files.
       Client side caching may lead to a delay between the time  where  owner-
       ship  have  been  changed to allow access for a user and the time where
       the file can actually be accessed by the user on other clients.


SEE ALSO

       chmod(2), flock(2), path_resolution(2)



Linux 2.6.7                       2004-06-23                          CHOWN(2)


Man(1) output converted with man2html and wrapped by fishsponge

This page was generated on Tue Feb 13 02:17:42 GMT 2007

Your favourite pages:

No pages logged yet.
Trying to save cookie...

Top 10 most popular pages:

sqlite3 man page (5080 hits)
(openSUSE 10.2)

adv_cap_autoneg man page (4745 hits)
(Solaris 10 11_06)

CPAN man page (4465 hits)
(Suse Linux 10.1)

ssh man page (4248 hits)
(Suse Linux 10.1)

svn man page (4219 hits)
(FreeBSD 6.2)

startproc man page (2190 hits)
(Suse Linux 10.1)

ssh-socks5-proxy-connect man page (2179 hits)
(Solaris 10 11_06)

netcat man page (2149 hits)
(Suse Linux 10.1)

pprosetup man page (2006 hits)
(Solaris 10 11_06)

signal man page (1989 hits)
(Suse Linux 10.1)

Useful Links

Go Back

Visitor Statistics


Valid XHTML 1.0 Transitional     Valid CSS!

Partners: Cambridge Plus :: Pyrenees Mountain Holidays :: USB Temperature Monitor :: <Link Available>
Unix Man Pages / Linux Man Pages :: HiFi Forum :: SIP VoIP Phone & Provider Reviews :: UNIX/Linux Forum Archives

More info on advertising on Unix/Linux Forum