2020-02-12 20:01:15 +03:00
. \"
. \" Copyright 2018 Antonio Russo <antonio.e.russo@gmail.com>
. \" Copyright 2019 Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
. \" Copyright 2020 InsanePrawn <insane.prawny@gmail.com>
. \"
. \" Permission is hereby granted, free of charge, to any person obtaining
. \" a copy of this software and associated documentation files (the
. \" "Software"), to deal in the Software without restriction, including
. \" without limitation the rights to use, copy, modify, merge, publish,
. \" distribute, sublicense, and/or sell copies of the Software, and to
. \" permit persons to whom the Software is furnished to do so, subject to
. \" the following conditions:
. \"
. \" The above copyright notice and this permission notice shall be
. \" included in all copies or substantial portions of the Software.
. \"
. \" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
. \" EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
. \" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
. \" NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
. \" LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
. \" OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
. \" WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
.TH "ZFS\-MOUNT\-GENERATOR" "8" "2020-01-19" "ZFS" "zfs-mount-generator" "\" "
2018-04-07 00:11:09 +03:00
.SH "NAME"
2018-05-11 22:44:14 +03:00
zfs\- mount\- generator \- generates systemd mount units for ZFS
2018-04-07 00:11:09 +03:00
.SH SYNOPSIS
2020-02-12 20:01:15 +03:00
.B @systemdgeneratordir@/zfs\-mount\-generator
2018-04-07 00:11:09 +03:00
.sp
.SH DESCRIPTION
2018-05-11 22:44:14 +03:00
zfs\- mount\- generator implements the \fB Generators Specification\fP
2018-04-07 00:11:09 +03:00
of
.BR systemd (1),
and is called during early boot to generate
.BR systemd.mount (5)
units for automatically mounted datasets. Mount ordering and dependencies
2020-02-12 20:01:15 +03:00
are created for all tracked pools (see below).
.SS ENCRYPTION KEYS
If the dataset is an encryption root, a service that loads the associated key (either from file or through a
.BR systemd\-ask\-password (1)
prompt) will be created. This service
. BR RequiresMountsFor
the path of the key (if file-based) and also copies the mount unit's
.BR After ,
.BR Before
2018-04-07 00:11:09 +03:00
and
2020-02-12 20:01:15 +03:00
.BR Requires .
All mount units of encrypted datasets add the key\- load service for their encryption root to their
.BR Wants
and
.BR After .
The service will not be
.BR Want ed
or
.BR Require d
by
2018-04-07 00:11:09 +03:00
.BR local-fs.target
2020-02-12 20:01:15 +03:00
directly, and so will only be started manually or as a dependency of a started mount unit.
.SS UNIT ORDERING AND DEPENDENCIES
mount unit's
.BR Before
\- >
key\- load service (if any)
\- >
mount unit
\- >
mount unit's
.BR After
It is worth nothing that when a mount unit is activated, it activates all available mount units for parent paths to its mountpoint, i.e. activating the mount unit for /tmp/foo/1/2/3 automatically activates all available mount units for /tmp, /tmp/foo, /tmp/foo/1, and /tmp/foo/1/2. This is true for any combination of mount units from any sources, not just ZFS.
2018-04-07 00:11:09 +03:00
2020-02-12 20:01:15 +03:00
.SS CACHE FILE
Because ZFS pools may not be available very early in the boot process,
information on ZFS mountpoints must be stored separately. The output of the command
2018-04-07 00:11:09 +03:00
.PP
.RS 4
2020-02-12 20:01:15 +03:00
zfs list -H -o name,mountpoint,canmount,atime,relatime,devices,exec,readonly,setuid,nbmand,encroot,keylocation,org.openzfs.systemd:requires,org.openzfs.systemd:requires-mounts-for,org.openzfs.systemd:before,org.openzfs.systemd:after,org.openzfs.systemd:wanted-by,org.openzfs.systemd:required-by,org.openzfs.systemd:nofail,org.openzfs.systemd:ignore
2018-04-07 00:11:09 +03:00
.RE
.PP
for datasets that should be mounted by systemd, should be kept
separate from the pool, at
.PP
.RS 4
.RI @sysconfdir@/zfs/zfs-list.cache/ POOLNAME
.
.RE
.PP
The cache file, if writeable, will be kept synchronized with the pool
state by the ZEDLET
.PP
.RS 4
history_event-zfs-list-cacher.sh .
.RE
.PP
.sp
2020-02-12 20:01:15 +03:00
.SS PROPERTIES
The behavior of the generator script can be influenced by the following dataset properties:
.sp
.TP 4
.BR canmount = on | off | noauto
If a dataset has
.BR mountpoint
set and
.BR canmount
is not
.BR off ,
a mount unit will be generated.
Additionally, if
.BR canmount
is
.BR on ,
.BR local-fs.target
will gain a dependency on the mount unit.
This behavior is equal to the
.BR auto
and
.BR noauto
legacy mount options, see
.BR systemd.mount (5).
Encryption roots always generate a key-load service, even for
.BR canmount=off .
.TP 4
.BR org.openzfs.systemd:requires\-mounts\-for = \fI path\fR...
Space\- separated list of mountpoints to require to be mounted for this mount unit
.TP 4
.BR org.openzfs.systemd:before = \fI unit\fR...
The mount unit and associated key\- load service will be ordered before this space\- separated list of units.
.TP 4
.BR org.openzfs.systemd:after = \fI unit\fR...
The mount unit and associated key\- load service will be ordered after this space\- separated list of units.
.TP 4
.BR org.openzfs.systemd:wanted\-by = \fI unit\fR...
Space-separated list of units that will gain a
.BR Wants
dependency on this mount unit.
Setting this property implies
.BR noauto .
.TP 4
.BR org.openzfs.systemd:required\-by = \fI unit\fR...
Space-separated list of units that will gain a
.BR Requires
dependency on this mount unit.
Setting this property implies
.BR noauto .
.TP 4
.BR org.openzfs.systemd:nofail = unset | on | off
Toggles between a
.BR Wants
and
.BR Requires
type of dependency between the mount unit and
.BR local-fs.target ,
if
.BR noauto
isn't set or implied.
.BR on :
Mount will be
.BR WantedBy
local-fs.target
.BR off :
Mount will be
.BR Before
and
.BR RequiredBy
local-fs.target
.BR unset :
Mount will be
.BR Before
and
.BR WantedBy
local-fs.target
.TP 4
.BR org.openzfs.systemd:ignore = on | off
If set to
.BR on ,
do not generate a mount unit for this dataset.
.RE
See also
.BR systemd.mount (5)
.PP
2018-05-11 22:44:14 +03:00
.SH EXAMPLE
To begin, enable tracking for the pool:
.PP
.RS 4
touch
.RI @sysconfdir@/zfs/zfs-list.cache/ POOLNAME
.RE
.PP
Then, enable the tracking ZEDLET:
.PP
.RS 4
2018-06-07 19:59:59 +03:00
ln -s "@zfsexecdir@/zed.d/history_event-zfs-list-cacher.sh" "@sysconfdir@/zfs/zed.d"
2018-05-11 22:44:14 +03:00
2019-11-13 21:23:23 +03:00
systemctl enable zfs-zed.service
2018-05-11 22:44:14 +03:00
2019-11-13 21:23:23 +03:00
systemctl restart zfs-zed.service
2018-05-11 22:44:14 +03:00
.RE
.PP
2020-02-12 20:01:15 +03:00
Force the running of the ZEDLET by setting a monitored property, e.g.
.BR canmount ,
for at least one dataset in the pool:
2018-05-11 22:44:14 +03:00
.PP
.RS 4
zfs set canmount=on
.I DATASET
.RE
.PP
This forces an update to the stale cache file.
2020-02-12 20:01:15 +03:00
To test the generator output, run
.PP
.RS 4
@systemdgeneratordir@/zfs-mount-generator /tmp/zfs-mount-generator . .
.RE
.PP
This will generate units and dependencies in
.I /tmp/zfs-mount-generator
for you to inspect them. The second and third argument are ignored.
If you're satisfied with the generated units, instruct systemd to re-run all generators:
.PP
.RS 4
systemctl daemon-reload
.RE
.PP
2018-05-11 22:44:14 +03:00
.sp
2018-04-07 00:11:09 +03:00
.SH SEE ALSO
.BR zfs (5)
.BR zfs-events (5)
.BR zed (8)
.BR zpool (5)
.BR systemd (1)
.BR systemd.target (5)
.BR systemd.special (7)
.BR systemd.mount (7)