|
NAMEmount_unionfs —
mount union file systems
SYNOPSIS
DESCRIPTIONThemount_unionfs utility attaches
directory above uniondir in such a
way that the contents of both directory trees remain visible. By default,
directory becomes the upper layer and
uniondir becomes the lower layer.
The options are as follows:
To enforce file system security, the user mounting a file system
must be superuser or else have write permission on the mounted-on directory.
In addition, the vfs.usermount
sysctl(8)
variable must be set to 1 to permit file system mounting by ordinary users.
However, note that Filenames are looked up in the upper layer and then in the lower
layer. If a directory is found in the lower layer, and there is no entry in
the upper layer, then a shadow directory will be created
in the upper layer. The ownership and the mode bits are set depending on the
If a file exists in the upper layer then there is no way to access a file with the same name in the lower layer. If necessary, a combination of loopback and union mounts can be made which will still allow the lower files to be accessed by a different pathname. Except in the case of a directory, access to an object is granted via the normal file system access checks. For directories, the current user must have access to both the upper and lower directories (should they both exist). Requests to create or modify objects in
uniondir are passed to the upper layer with the
exception of a few special cases. An attempt to open for writing a file
which exists in the lower layer causes a copy of the
entire file to be made to the upper layer, and then for
the upper layer copy to be opened. Similarly, an attempt to truncate a lower
layer file to zero length causes an empty file to be created in the upper
layer. Any other operation which would ultimately require modification to
the lower layer fails with The union file system manipulates the namespace, rather than
individual file systems. The union operation applies recursively down the
directory tree now rooted at uniondir. Thus any file
systems which are mounted under uniondir will take
part in the union operation. This differs from the
MASQUERADE MODEWhen a file (or a directory) is created in the upper layer, themasquerade mode sets it the fixed access mode bits
given in ufile (for files) or
udir (for directories) option and the owner given in
udir and gid options, instead
of ones in the lower layer. Note that in the
masquerade mode and when owner of the file or
directory matches one specified in uid option, only
mode bits for the owner will be modified. More specifically, the file mode
bits in the upper layer will be (mode in the lower layer) OR (mode given in
ufile AND 0700), and the ownership will be the same as
one in the lower layer.
The default values for
EXAMPLESThe commandsmount -t cd9660 -o ro /dev/cd0 /usr/src mount -t unionfs -o noatime /var/obj /usr/src mount the CD-ROM drive /dev/cd0 on
/usr/src and then attaches
/var/obj on top. For most purposes the effect of
this is to make the source tree appear writable even though it is stored on
a CD-ROM. The The commands mount -t cd9660 -o ro /dev/cd0 /usr/src chown 2020 /usr/src mount -t unionfs -o noatime -o copymode=masquerade -o uid=builder \ -o udir=755 -o ufile=644 /var/obj /usr/src also mount the CD-ROM drive /dev/cd0 on
/usr/src and then attaches
/var/obj on top. Furthermore, the owner of all files
and directories in /usr/src is a regular user with
UID 2020 when seen from the upper layer. Note that for the access mode bits,
ones in the lower layer (on the CD-ROM, in this example) are still used
without change. Thus, write privilege to the upper layer can be controlled
independently from access mode bits and ownership in the lower layer. If a
user does not have read privilege from the lower layer, one cannot still
read even when the upper layer is mounted by using
The command mount -t unionfs -o noatime -o below /sys $HOME/sys attaches the system source tree below the sys directory in the user's home directory. This allows individual users to make private changes to the source, and build new kernels, without those changes becoming visible to other users. Note that the files in the lower layer remain accessible via /sys. SEE ALSOintro(2), mount(2), unmount(2), fstab(5), mount(8), mount_nullfs(8)HISTORYThemount_null utility first appeared in
4.4BSD. It was renamed to
mount_unionfs in FreeBSD 5.0.
The AUTHORSIn FreeBSD 7.0, Masanori OZAWA <ozawa@ongs.co.jp> reimplemented handling of locking, whiteout, and file mode bits, and Hiroki Sato <hrs@FreeBSD.org> wrote about the changes in this manual page.BUGSTHIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED.This code also needs an owner in order to be less dangerous - serious hackers can apply by sending mail to <freebsd-fs@FreeBSD.org> and announcing their intent to take it over. Without whiteout support from the file system backing the upper
layer, there is no way that delete and rename operations on lower layer
objects can be done. Running find(1) over a union tree has the side-effect of creating a tree of shadow directories in the upper layer. The current implementation does not support copying extended attributes for acl(9), mac(9), or so on to the upper layer. Note that this may be a security issue. A shadow directory, which is one automatically created in the
upper layer when it exists in the lower layer and does not exist in the
upper layer, is always created with the superuser privilege. However, a file
copied from the lower layer in the same way is created by the user who
accessed it. Because of this, if the user is not the superuser, even in
Visit the GSP FreeBSD Man Page Interface. |