CHMOD(1) | User Commands | CHMOD(1) |
chmod - change the permissions mode of a file
chmod [-fR] absolute-mode file ...
chmod [-fR] symbolic-mode-list file ...
chmod [-fR] acl_operation file ...
chmod [-fR] [-@ named_attribute]...attribute_specification_list file ...
The chmod utility changes or assigns the mode of a file.
chmod can also be used to modify Access Control Lists (ACLs) on files and directories, and to modify boolean read-write system attributes on regular files, directories, and opaque extended attribute files.
An absolute mode command line has the following format:
chmod [options] absolute-mode file ...
where absolute-mode is specified using octal numbers nnnn defined as follows:
n
4000
20#0
Enable mandatory locking if # is 6, 4, 2, or 0.
For directories, files are created with BSD semantics for propagation of the group ID. With this option, files and subdirectories created in the directory inherit the group ID of the directory, rather than of the current process. For directories, the set-gid bit can only be set or cleared by using symbolic mode.
1000
0400
0200
0100
0700
0040
0020
0010
0070
0004
0002
0001
0007
For directories, the setgid bit cannot be set (or cleared) in absolute mode; it must be set (or cleared) in symbolic mode using g+s (or g-s).
A symbolic mode command line has the following format:
chmod [options] symbolic-mode-list file ...
where symbolic-mode-list is a comma-separated list (with no intervening white space) of symbolic mode expressions of the form:
[who] operator [permissions]
Operations are performed in the order given. Multiple permissions letters following a single operator cause the corresponding operations to be performed simultaneously.
who
u
g
o
a
If who is omitted, it defaults to a, but the setting of the file mode creation mask (see umask in sh(1) or csh(1) for more information) is taken into account. When who is omitted, chmod does not override the restrictions of your user mask.
operator
+
If permissions are omitted, nothing is added.
If who is omitted, add the file mode bits represented by permissions, except for the those with corresponding bits in the file mode creation mask.
If who is present, add the file mode bits represented by the permissions.
−
If permissions are omitted, do nothing.
If who is omitted, clear the file mode bits represented by permissions, except for those with corresponding bits in the file mode creation mask.
If who is present, clear the file mode bits represented by permissions.
=
If who is omitted, clear all file mode bits; if who is present, clear the file mode bits represented by who.
If permissions are omitted, do nothing else.
If who is omitted, add the file mode bits represented by permissions, except for the those with corresponding bits in the file mode creation mask.
If who is present, add the file mode bits represented by permissions.
Unlike other symbolic operations, = has an absolute effect in that it resets all other bits represented by who. Omitting permissions is useful only with = to take away all permissions.
permission
l
r
s
t
w
x
X
u,g,o
Permissions to a file can vary depending on your user identification number (UID) or group identification number (GID). Permissions are described in three sequences each having three characters:
User | Group | Other |
rwx | rwx | rwx |
This example (user, group, and others all have permission to read, write, and execute a given file) demonstrates two categories for granting permissions: the access class and the permissions themselves.
The letter s is only meaningful with u or g, and t only works with u.
Mandatory file and record locking (l) refers to a file's ability to have its reading or writing permissions locked while a program is accessing that file.
In a directory which has the set-group-ID bit set (reflected as either -----s--- or -----l--- in the output of 'ls -ld'), files and subdirectories are created with the group-ID of the parent directory—not that of current process.
It is not possible to permit group execution and enable a file to be locked on execution at the same time. In addition, it is not possible to turn on the set-group-ID bit and enable a file to be locked on execution at the same time. The following examples, therefore, are invalid and elicit error messages:
chmod g+x,+l file chmod g+s,+l file
Only the owner of a file or directory (or the super-user) can change that file's or directory's mode. Only the super-user can set the sticky bit on a non-directory file. If you are not super-user, chmod masks the sticky-bit but does not return an error. In order to turn on a file's set-group-ID bit, your own group ID must correspond to the file's and group execution must be set.
An ACL Operation command line has the following format:
chmod [options] A[number]- file ... chmod [options] A-acl_specification file ... chmod [options] A[index]{+|=}acl_specification file ...
Where acl_specification is a comma-separated list (with no intervening white space) of an ACL specification of the form:
A[index]+acl_specification
A-
Aindex-
A-acl_specification
A=acl_specification
A[index]=acl_specification
POSIX-draft ACL Specification (as supported by UFS)
POSIX-draft ACLs (as supported by UFS) are specified as colon (:) separated fields of the following.
user::perms
user:username:perms
group::perms
group:groupname:perms
other::perms
mask:perms
default:user::perms
default:user:username:perms
default:group::perms
default:group:groupname:perms
default:other:perms
default:mask:perms
The above specification allows for ACLs to be specified such as:
user:tom:rw-,mask:rwx,group:staff:r-x
NFSv4 ACL Specification (as supported by NFSv4 and ZFS)
NFSv4 ACLs provide richer ACL semantics. They provide both allow and deny entries, finer grained permissions, and enhanced inheritance control.
NFSv4 ACLs are specified as colon (:) separated fields of the following.
owner@:<perms>[:inheritance flags]:<allow|deny>
group@:<perms>[:inheritance flags]:<allow|deny>
everyone@:<perms>[:inheritance flags]:<allow|deny>
user:<username>:<perms>[:inheritance flags]:<allow|deny>
usersid:<sid string>:<perms>[:inheritance flags]:<allow|deny>
group:<groupname>:<perms>[:inheritance flags]:<allow|deny>
groupsid:<sid string>:<perms>[:inheritance flags]:<allow|deny>
sid:<sid string>:<perms>[:inheritance flags]:<allow|deny>
Permissions can be specified in three different chmod ACL formats: verbose, compact, or positional. The verbose format uses words to indicate that the permissions are separated with a forward slash (/) character. Compact format uses the permission letters and positional format uses the permission letters or the hyphen (-) to identify no permissions.
The permissions for verbose mode and their abbreviated form in parentheses for compact and positional mode are described as follows:
read_data (r)
list_directory (r)
write_data (w)
add_file (w)
append_data (p)
Currently, this permission is not supported.
add_subdirectory (p)
read_xattr (R)
write_xattr (W)
execute (x)
read_attributes (a)
write_attributes (A)
delete (d)
delete_child (D)
read_acl (c)
write_acl (C)
write_owner (o)
synchronize (s)
Currently, this permission is not supported.
Using the compact ACL format, permissions are specified by using 14 unique letters to indicate permissions.
Using the positional ACL format, permissions are specified as positional arguments similar to the ls -V format. The hyphen (-), which indicates that no permission is granted at that position, can be omitted and only the required letters have to be specified.
The letters above are listed in the order they would be specified in positional notation.
Permissions can be specified with these letters in the following way:
rwx--D--------
The hyphens can be removed to compact the string as follows:
rwxD
Several special permission sets or aliases are also supported. The following permission sets are used the same way that verbose permissions are specified.
full_set
modify_set
read_set
write_set
The optional inheritance flags can be specified in the three formats. The first format uses words to indicate the various inheritance flags separated with a forward slash (/) character.
file_inherit (f)
dir_inherit (d)
inherit_only (i)
no_propagate (n)
successful_access (S)
failed_access (F)
inherited (I)
The inheritance flags listed can also be specified in the compact format or as positional arguments similar to the ls -V format. A hyphen character indicates that the inheritance flag at that position is not specified in the positional ACL format.
The inheritance flags can be specified with these letters in any of the following equivalent ways.
file_inherit/dir_inherit/no_propagate
fd-n---
fdn
With this inheritance model, an ACL entry can be specified such as:
user:tom:read_data/write_data/read_attributes:file_inherit:allow user:fred:read_data:file_inherit/dir_inherit:deny user:bob:read_data:allow
An attribute operation command line has the following format:
chmod [options] attribute_specification_list file ...
where attribute_specification_list is the character S followed by a comma-separated list of one or more attribute_specifications. Each attribute_specification is of the form:
[operator]attribute_specifier
An operator is one of the following:
+
-
=
If an operator is not specified in an attribute_specification, chmod behaves as if + had been specified.
An attribute_specifier takes one of the following forms:
a
c[compact_attribute_list]
c'{'compact_attribute_list'}'
v[verbose_attribute_setting]
v['{'verbose_attribute_setting_list'}']
A compact_attribute_list is a list of zero or more adjacent attribute abbreviation characters from list of Attribute Names and Abbreviation Characters later in this section. An arbitrary number of hyphen (-) characters can be included in a compact_attribute_list. These are ignored.
A verbose_attribute_setting is an attribute name from the list of Attribute Names and Abbreviation Characters later in this section, optionally, immediately preceded by no. If the attribute name is used without no, the attribute is set; otherwise the attribute is cleared.
A verbose_attribute_setting_list is zero or more comma-separated verbose_attribute_settings.
Multiple operations specified for a file are accumulated and are all set for a file operand as a single attribute setting operation. If an attribute is specified more than once in an attribute_specification_list, the last specified operation is applied.
The following is a list of Attribute Names and Abbreviation Characters:
Attribute Name
hidden
system
readonly
archive
nounlink
immutable
appendonly
nodump
av_quarantined
av_modified
offline
sparse
The following options are supported:
-f
-R
-@ named_attribute
A named attribute of * carries meaning to chmod, and is considered to mean all extended attribute files associated with a file operand. This does not refer to the special files . and ...
A named attribute of .. carries special meaning to chmod, and is considered to mean the file operand itself. This allows chmod, in a single call, to apply the attribute specification mode to the specified named attribute file of the file operand and the file operand itself.
The following operands are supported:
absolute-mode
symbolic-mode-list
acl_operation
acl_operation is one of the following:
A[number] - A-acl_specification A[index]{+|=}acl_specification
attribute_specification_list
file
See largefile(7) for the description of the behavior of chmod when encountering files greater than or equal to 2 Gbyte (2^31 bytes).
Example 1 Denying execute Permission
The following example denies execute permission to everyone:
% chmod a-x file
Example 2 Allowing read-only Permission
The following example allows only read permission to everyone:
% chmod 444 file
Example 3 Making a File readable and writable
The following example makes a file readable and writable by the group and others:
% chmod go+rw file % chmod 066 file
Example 4 Locking a File From Access
The following example locks a file from access:
$ chmod +l file
Example 5 Granting read, write, execute, and set group-ID Permission on a File
The following example grants everyone read, write, and execute permissions on the file, and turns on the set group-ID:
$ chmod a=rwx,g+s file $ chmod 2777 file
Example 6 Prepending a New ACL Entry on a ZFS File
The following example prepends a new ACL entry on a ZFS file.
First, display the current ACL:
$ ls -v file.3 -rw-r--r-- 1 marks staff 0 Oct 9 15:49 file.3
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Issue the following command:
$ chmod A+user:lp:read_data:deny file.3
Display the new ACL:
$ ls -v file.3 -rw-r--r--+ 1 marks staff 0 Oct 9 15:49 file.3
0:user:lp:read_data:deny
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Example 7 Prepending a New POSIX-draft ACL Entry on a UFS File
The following example prepends a new POSIX-draft ACL entry on a UFS file.
First, display the current ACL:
$ ls -v file.2 -rw-r--r-- 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:group::r-- #effective:r--
2:mask:r--
3:other:r--
Issue the following command:
$ chmod A+user:lp:-wx file.2
Display the new ACL:
$ ls -v file.2 -rw-r--r--+ 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:user:lp:-wx #effective:---
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Example 8 Inserting an ACL Entry in a Specific Position on a ZFS file
The following example inserts an ACL entry in a specific position on a ZFS file system. It also illustrates the compact ACL format.
First, display the ACL to pick a location to insert a new ACE.
% ls -V file.1 -rw-r--r--+ 1 root root 0 Oct 6 12:16 file.1
user:lp:rw------------:-------:allow
owner@:--x-----------:-------:deny
owner@:rw-p---A-W-Co-:-------:allow
group@:-wxp----------:-------:deny
group@:r-------------:-------:allow
everyone@:-wxp---A-W-Co-:-------:deny
everyone@:r-----a-R-c--s:-------:allow
Next, insert a new entry in location 3. This causes the entries that are currently in position 3 - 6 to be pushed down.
Issue the following command:
$ chmod A3+user:marks:r:deny file.1
Display the new ACL:
$ ls -V file.1 -rw-r--r--+ 1 root staff 0 Feb 3 14:13 file.1
user:lp:rw------------:-------:allow
owner@:--x-----------:-------:deny
owner@:rw-p---A-W-Co-:-------:allow
user:marks:r-------------:-------:deny
group@:-wxp----------:-------:deny
group@:r-------------:-------:allow
everyone@:-wxp---A-W-Co-:-------:deny
everyone@:r-----a-R-c--s:-------:allow
Example 9 Inserting a POSIX-draft ACL in a Specific Position on a UFS File
The file system reorders ACLs when they are stored in the file system. The following example illustrates this behavior.
$ ls -v file.1 -rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:user:lp:rw- #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Now, insert an entry at index position 3. The command works, but the file system reorders the ACL.
$ chmod A3+user:marks:rw- file.1 $ ls -v file.1 -rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:user:lp:rw- #effective:r--
2:user:marks:rw- #effective:r--
3:group::r-- #effective:r--
4:mask:r--
5:other:r--
Rather than inserting the ACL entry in position 3 as requested, it actually ends up in position 2.
Example 10 Removing an ACL Entry on a ZFS File
The following example removes the lp entry from an ACL:
$ ls -v file.3 -rw-r--r--+ 1 marks staff 0 Oct 9 15:49 file.3
0:user:lp:read_data:deny
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
$ chmod A-user:lp:read_data:deny file.3 $ ls -v file.3 -rw-r--r-- 1 marks staff 0 Oct 9 15:49 file.3
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Example 11 Removing a POSIX-draft ACL on a UFS File
The following example removes the lp entry from an ACL:
$ ls -v file.2 -rw-r--r--+ 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:user:lp:-wx #effective:---
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
$ chmod A-user:lp:-wx file.2 $ ls -v file.2 -rw-r--r-- 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:group::r-- #effective:r--
2:mask:r--
3:other:r--
Example 12 Removing a Specific ACL Entry by Index Number on a ZFS File
Consider the following ACL:
$ ls -v file
0:group:staff:read_data/write_data/execute/read_acl:allow
1:user:bin:read_data:deny
2:user:bin:read_data:allow
3:owner@:write_data/append_data:deny
4:owner@:read_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow
5:group@:write_data/append_data:deny
6:group@:read_data/execute:allow
7:everyone@:write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:deny
8:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow
Remove the second user entry for bin.
$ chmod A2- file $ ls -v file
0:group:staff:read_data/write_data/execute/read_acl:allow
1:user:bin:read_data:deny
2:owner@:write_data/append_data:deny
3:owner@:read_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow
4:group@:write_data/append_data:deny
5:group@:read_data/execute:allow
6:everyone@:write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow
Example 13 Removing a Specific POSIX-draft ACL Entry on a UFS File
The following example removes the lp entry by index number from the following ACL:
$ ls -v file.1 -rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:user:lp:rw- #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
$ chmod A1- file.1
$ ls -v -rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:group::r-- #effective:r--
2:mask:r--
3:other:r--
Example 14 Removing All ACLs From a File
The following command works with either NFSv4/ZFS or POSIX-draft ACLs.
Consider the following ACL:
$ ls -v file.3 -rw-r--r--+ 1 marks staff 0 Oct 9 15:49 file.3
0:user:lp:read_data/write_data:allow
1:user:marks:read_acl:allow
2:owner@:execute:deny
3:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
4:group@:write_data/append_data/execute:deny
5:group@:read_data:allow
6:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
The existing ACL is effectively removed and is replaced with an ACL that represents the permission bits of the file.
$ chmod A- file.3 $ ls -v file.3 -rw-r--r-- 1 marks staff 0 Oct 9 15:49 file.3
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Example 15 Replacing an Entire ACL Entry on a ZFS File
Use the following chmod syntax if you want to replace an ACL in its entirety:
$ chmod A=owner@:read_data/write_data:allow,group@:read_data/
write_data:allow,user:lp:read_data:allow file.4 $ ls -v file.4 -rw-rw----+ 1 marks staff 0 Oct 9 16:12 file.4
0:owner@:read_data/write_data:allow
1:group@:read_data/write_data:allow
2:user:lp:read_data:allow
Example 16 Replacing an Entire POSIX-draft ACL on a UFS File
This operation is a little more complicated. The replacement ACL needs the necessary entries to represent the file owner, file group owner, other, mask and any additional entries you wish to set.
$ chmod A=user::rw-,group::rw-,other::---,mask:r--,
user:lp:r-- file.3 $ ls -v file.3 -rw-r-----+ 1 root root 0 Oct 9 16:14 file.3
0:user::rw-
1:user:lp:r-- #effective:r--
2:group::rw- #effective:r--
3:mask:r--
4:other:---
Example 17 Replacing a Specific Entry on a ZFS File
Consider the following ACL.
$ ls -v file.5 -rw-r--r--+ 1 marks staff 0 Oct 9 16:18 file.5
0:user:marks:read_data:allow
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Now, change the allow access to a deny for user marks:
$ chmod A0=user:marks:read_data:deny file.5 $ ls -v file.5 -rw-r--r--+ 1 marks staff 0 Aug 23 09:11 file.5 0:user:marks:read_data:deny 1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:allow 2:group@:write_data/append_data/execute:deny 3:group@:read_data:allow 4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
/write_acl/write_owner:deny 5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
:allow
Example 18 Replacing a Specific POSIX-draft ACL on a UFS File
Consider the following ACL.
$ ls -v file.4 -rw-r--r--+ 1 marks staff 0 Oct 9 16:21 file.4
0:user::rw-
1:user:lp:rwx #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Now, change the permission on lp from rwx to r--:
$ chmod A1=user:lp:r-- file.4 $ ls -v file -rw-r--r--+ 1 marks staff 0 Oct 9 16:21 file.4
0:user::rw-
1:user:lp:r-- #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Example 19 Setting ACL Inheritance Flags on a ZFS File
You can only set inheritance flags on ZFS files. When setting ACLs on directories, several inheritance flags can be optionally set.
Suppose you have an ACL entry for user lp that you want to be inherited to newly created files in a directory. First, you need to create an inheritable ACL entry on the directory:
$ chmod A+user:lp:read_data:file_inherit:allow test.dir $ ls -dv test.dir drwxr-xr-x+ 2 marks staff 2 Aug 23 09:08 test.dir/ 0:user:lp:read_data:file_inherit:allow 1:owner@::deny 2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow 3:group@:add_file/write_data/add_subdirectory/append_data:deny 4:group@:list_directory/read_data/execute:allow 5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny 6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow
The lp entry is inherited to newly created files in the directory test.dir.
$ touch test.dir/file.test $ ls -v test.dir/file.test -rw-r--r--+ 1 marks staff 0 Oct 9 16:29 test.dir/file.test
0:user:lp::deny
1:user:lp:read_data:allow
2:owner@:execute:deny
3:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
4:group@:write_data/append_data/execute:deny
5:group@:read_data:allow
6:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
The user lp entry is inherited to the newly created file. Multiple combinations of the inheritance flags can be specified. For example, if you wanted the lp entry to also be inherited to directories, then the following command can be used:
$ chmod A+user:lp:read_data:file_inherit/\
dir_inherit:allow test.dir
Example 20 Replacing System Attributes of a ZFS File
The following examples replace system attributes of a ZFS file:
$ chmod S=v{archive,hidden,readonly,system,appendonly,\
nonodump,immutable,noav_modified,noav_quarantined,\
nounlink,nooffline,nosparse} file1
or
$ chmod S=c{AHRSaiu} file1
or
$ chmod S=c{AHRSa-i--u--} file1
or
$ chmod S=cAHRSaiu file1
or
$ chmod -@ '..' S=cAHRSaiu file1
Assuming appropriate privileges, this results in the following system attributes of file1 being set: archive, hidden, readonly, system, appendonly, immutable, and nounlink. Assuming appropriate privileges, the following system attributes of file1 are cleared: nodump, av_modified, av_quarantined, offline, and sparse.
Example 21 Clearing All System Attributes of a ZFS File
The following examples clears all system attributes of a ZFS file:
$ chmod S-a file1
or
$ chmod -@ '..' S-a file1
Assuming appropriate privileges, all boolean read-write system attributes are cleared on file1.
Example 22 Setting a System Attribute of a Named Attribute File of a ZFS File
The following example sets a system attribute of a named attribute file of a ZFS file, but not of the file itself:
$ chmod -@ myattr S+vhidden file1
This results in the hidden system attribute being set for the named attribute file myattr of file1, but not the file itself.
Example 23 Setting a System Attribute of All Named Attribute File of a ZFS File
The following example sets a system attribute of all named attribute files of a ZFS file, but not of the file itself:
$ chmod -@ '*' S+a file1
Example 24 Setting a System Attribute of All Named Attribute Files of a ZFS File
The following example sets a system attribute of all named attribute files of a ZFS file, as well as of the file itself:
$ chmod -@ '..' -@ '*' S+vhidden file1
This results in the hidden system attribute being set for all named attribute files of file1, as well as the file itself.
Example 25 Recursively Descending Through a Directory Hierarchy
The following example recursively descends through a directory hierarchy, and sets all system attributes of all named attribute files, the ZFS file operands, as well as of the directory itself:
$ chmod -R -@ '..' -@ '*' S+a directory1
This results in the hidden system attribute being set for all named attribute files of all regular files and directories within the directory hierarchy of directory1, as well as of directory1 itself.
Example 26 Setting the hidden and system System Attributes of a ZFS File
The following examples set the hidden and system system attributes of a ZFS file:
$ chmod S+cHS file1
or
$ chmod S+vhidden,+vsystem file1
or
$ chmod S+v{hidden,system} file1
or
$ chmod S+c{-H-S--------} file1
or
$ chmod S-v{nohidden,nosystem} file1
or
$ chmod S-v{hidden,system},+v{hidden,system} file1
Example 27 Clearing All System Attributes of a ZFS File
The following example clears all system attributes of a ZFS file:
$ chmod S-a file1
or
$ chmod S=v{} file1
In the following two examples, the last attribute operation specified takes precedence.
In this example, the replacement attribute name list ({}) clears all system attributes for file1:
$ chmod S+cHS,=v{} file1
In this example, the clear attributes operation (-a) clears all system attributes of file1:
$ chmod S+vhidden,+vsystem,-a file1
Example 28 Setting the Values of All Boolean read-write System Attributes of a File
The following example sets the values of all boolean read-write system attributes of a file to the same as the boolean read-write system attributes of another file:
$ chmod S=v`ls -/v file1|sed -n '2s/.*{/{/p'` file2
Assuming appropriate privileges and that file1 and file2 have the same supported system attributes, all system attributes of file1 that are set are also set on file2. All system attributes of file1 that are cleared are also cleared on file2.
See environ(7) for descriptions of the following environment variables that affect the execution of chmod: LANG, LC_ALL, LC_CTYPE, LC_MESSAGES, and NLSPATH.
The following exit values are returned:
0
>0
See attributes(7) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
CSI | Enabled |
Interface Stability | Committed |
getfacl(1), ls(1), setfacl(1), chmod(2), fgetattr(3C), acl(7), attributes(7), environ(7), fsattr(7), largefile(7), standards(7)
Absolute changes do not work for the set-group-ID bit of a directory. You must use g+s or g-s.
chmod permits you to produce useless modes so long as they are not illegal (for instance, making a text file executable). chmod does not check the file type to see if mandatory locking is meaningful.
If the filesystem is mounted with the nosuid option, setuid execution is not allowed.
If you use chmod to change the file group owner permissions on a file with ACL entries, both the file group owner permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the effective permissions for additional users and groups who have ACL entries on the file. Use the getfacl(1) or ls(1) command to make sure the appropriate permissions are set for all ACL entries.
November 24, 2014 | OmniOS |