zfs does not mount non-empty parent directory on boot about pkg-zfs HOT 10 CLOSED

This glitch usually means that zfs mount -a is invoked during system start, which should not happen on Ubuntu. The mountall utility that is installed by ubuntu-zfs does not preserve Solaris behavior and will use non-empty mount points.

Double-check that:

• The /etc/init.d/zfs file does not exist. Leftovers from a make install cause problems like this.
• Similarly, /usr/local/sbin/zfs and /usr/local/lib/libzfs.so do not exit.
• The /etc/default/zfs file is unmodified. The ZFS_MOUNT option should be disabled.

Less frequently, this behavior can be caused by:

• Entries in the /etc/fstab file that conflict with mountpoint properties.
• A daemon running on /tank. (eg: famd)

If the problem persists after running zfs umount -a && rm -r /tank, then:

1. Manually check that /proc/mounts agrees with mount and zfs mount.
2. Report version numbers for Ubuntu, ZoL, and mountall.

from pkg-zfs.

I can confirm all the above is the case. The following though were exceptions -
there is no /etc/init.d/zfs however there is zfs-mount and zfs-share file. The zfs mount does contain an zfs mount -a command

• there is a /tank/smbroot folder that is used by the smbd daemon
• there is also a /tank/vicepa folder that is used by openafs

Could these point to where the issues are coming from?

hb

from pkg-zfs.

The following though were exceptions - there is no /etc/init.d/zfs however there is zfs-mount and zfs-share file.

This is proper if you are using the PPA.

• there is a /tank/smbroot folder that is used by the smbd daemon
• there is also a /tank/vicepa folder that is used by openafs

Could these point to where the issues are coming from?

Temporarily disabling both services, cleaning the mount point, and rebooting is an easy way to check.

Note that moving the service mounts up and out of the tank is a way to kludge the problem:

 # zfs set mountpoint=/smbroot tank/smbroot
 # zfs set mountpoint=/vicepaa tank/vicepaa
 # : dismount, clean the /tank, and remount
 # ln -s /smbroot /tank/smbroot
 # ln -s /vicepaa /tank/vicepaa

from pkg-zfs.

I am closing this ticket because it has gone two weeks without an update. If the problem persists, then please reopen the issue.

from pkg-zfs.

Hi, Just providing an update on this issue as I have had some time to work on it.

Basically - if /tank is non-empty mountall does not work.

Mounting all tank/ child fs in different rootdirs and leaving tank empty fixes the problem. Don't know why.

from pkg-zfs.

Okay, thanks for the update. This ticket is reopened so that other people can see it.

I suspect that the problem is caused by an unhandled corner case in the system shutdown logic, but I won't be able to properly diagnose it until I can get a reproducer.

from pkg-zfs.

I had the same problem. Apparently during reboot after upgrade from linux-image-3.2.0-55-generic to linux-image-3.2.0-56-generic. I unmounted everything, removed the empty directories under /tank that were apparently present on the ext4 root filesystem. After that zfs mount -a did the trick and /tank was mounted along with the child datasets.

from pkg-zfs.

Given that the systemd stack fully superseded upstart and mountall -- thereby mooting these issues -- I will close this ticket as stale.

from pkg-zfs.

I hope everyone on trusty will be able to upgrade to xenial

from pkg-zfs.

@ptman,

I hope everyone on trusty will be able to upgrade to xenial

Ubuntu doesn't have an officially supported upgrade path between Trusty and Xenial for ZoL features.

That said, simple in-pool configurations should migrate easily. Systems that use upstart events, /etc/fstab customizations, or a ZFS root filesystem will need attention.

Please bench test all upgrades.

from pkg-zfs.