BIND(1) BIND(1)
NAME
bind, mount, unmount - change name space
SYNOPSIS
bind [ option ... ] source target
mount [ option ... ] source target [ spec ]
unmount [ source ] target
DESCRIPTION
The bind and mount commands modify the file name space of
the current process and other processes in the same name
space group (see sys-pctl(2)). For both calls, target is the
name of an existing file or directory in the current name
space where the modification is to be made.
For bind, source is the name of an existing file or direc-
tory in the current name space. After a successful bind,
the file name target is an alias for the object originally
named by source; if the modification doesn't hide it, source
will also still refer to its original file. The evaluation
of source (see sys-intro(2)) happens at the time of the
bind, not when the binding is later used.
Both source and target files must be of the same type:
either both directories or both files.
For mount, source can be a shell command, a network address,
or a file name. If source is surrounded by brace characters
({ and }), it is invoked as a sh(1) command and its standard
input is mounted (no authentication takes place in this
case). If source contains an exclamation mark (!), or there
is no file of that name, it is assumed to be a network
address for a machine acting as a file server. This argu-
ment should then conform to the conventions described in
dial(2). Otherwise source should be the name of a file that
when opened gives a connection to a file server, something
serving the 9P protocol described in intro(5), formerly
called `Styx'. The optional spec argument to mount is
passed in the attach(5) message and selects amongst differ-
ent file trees offered by the server.
The effects of bind and mount can be undone by unmount. If
two arguments are given to unmount, the effect is to undo a
bind or mount with the same arguments. If only one argument
is given, everything bound to or mounted on target is
unmounted.
By default, bind and mount replace the target file by the
Page 1 Plan 9 (printed 12/21/24)
BIND(1) BIND(1)
new one, source. Henceforth, an evaluation of the pathname
target will be translated to the new file. If they are
directories (for mount, this condition is true by defini-
tion), target becomes a union directory consisting of one
directory (the source directory).
A union directory unites the contents of the source and tar-
get directories. If the same name appears in both directo-
ries, the name used is the one in the directory that is
bound before the other. In particular, if the directories
have subdirectories of the same name, only the contents of
the subdirectory in the top directory will be seen. If the
subdirectory contents are themselves to be united, that must
be done first in a separate bind or mount.
Note that the # character in the name of a kernel device
must be quoted when used in a bind or unmount command, or
the shell will take it as the start of a comment.
Options control aspects of the modification to the name
space:
-b Both files must be directories. Add the source direc-
tory to the beginning of the union directory repre-
sented by the target directory.
-a Both files must be directories. Add the source direc-
tory to the end of the union directory represented by
the target directory.
-c This can be used in addition to any of the above to
permit creation in a union directory. When a new file
is created in a union directory, it is placed in the
first element of the union that has been bound or
mounted with the -c option. If that directory has not
got write permission, the create fails.
-q Exit quietly without printing a diagnostic if the bind
or mount fails.
-A For mount only. Do not authenticate the connection to
the server before proceeding with mount. Otherwise the
connection is authenticated by security-auth(2).
-C alg
For mount only, specify the algorithm, alg, to be used
following authentication for digesting or encryption.
See ssl(3) for the supported algorithms. The default
is none: ssl(3) is not used after authentication.
-k kfile
For mount only, specify the keyfile to be used when
Page 2 Plan 9 (printed 12/21/24)
BIND(1) BIND(1)
authenticating. The default is
/usr/user/keyring/default. See keyring-auth(2) for
more details. (If the -9 option is given, this option
is interpreted differently: see below.)
-9 For mount only, and only when hosted on Plan 9. Source
is a Plan 9 file server; use Plan 9's factotum as
authentication agent to authenticate the mount. (Note
that a Plan 9 file service that is known not to authen-
ticate can be mounted from any Inferno host, by using
the -A option to suppress Inferno authentication.) The
existing Plan 9 file servers do not encrypt connec-
tions, so the -C option is ignored. The value of the
-k option is added to the key specification for
factotum(4) for authentication.
-P When source is a network address, use styxpersist(2) to
try to simulate a permanent connection, even should the
server reboot. Note the caveats on that page.
-o For mount only, the file server serves the 1995 version
of Inferno's Styx protocol, and mount inserts a process
that translates to the current version.
SOURCE
/appl/cmd/bind.b
/appl/cmd/mount.b
/appl/cmd/unmount.b
SEE ALSO
sh(1), dial(2), keyring-auth(2), security-auth(2), sys-
intro(2), sys-bind(2), intro(3), getauthinfo(8)
Page 3 Plan 9 (printed 12/21/24)