Good point, this is indeed a work-around for now. But if you forget to it to “noauto” after creation this will bite you after rebooting.
Using a key file instead of a passphrase will mount properly with canmount=on, given that the keyfile is available. Von: Nahum Shalman [mailto:[email protected]] Gesendet: Montag, 9. Januar 2017 16:01 An: [email protected] Betreff: Re: [smartos-discuss] fs-local is too rigorous On Fri, Jan 6, 2017 at 3:28 AM, Gernot Straßer <[email protected]> wrote: This is regarding ./proto/lib/svc/method/fs-local I was playing around with zfs crypto when I figured that script will fail if there is an encrypted dataset waiting for passphrase input. In line 90 it does a zfs mount -va and fails hard if there is an error, which causes all dependent services to fail . This includes sshd which renders the system unaccessible. My proposal would be to skip checking for mount errors, but there might be reasons I am not aware of. What if you alter the "canmount" property of all your encrypted filesystems to be "noauto"? Since they require interactivity to be mounted, that's probably pretty accurate, and I think should exclude them from "zfs mount -va" I could imagine making the argument that "canmount=noauto" should be the default for encrypted filesystems... -Nahum smartos-discuss | <https://www.listbox.com/member/archive/184463/=now> Archives <https://www.listbox.com/member/archive/rss/184463/28794496-332e6b48> | <https://www.listbox.com/member/?&;> Modify Your Subscription <http://www.listbox.com> ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
