[zfs-discuss] Fwd: Issues accessing ZFS-datasets with Samba on Debian
Gregor Kopka (@zfs-discuss)
zfs-discuss at kopka.net
Thu Jan 11 04:10:44 EST 2018
Am 11.01.2018 um 05:13 schrieb John Doe via zfs-discuss:
> I managed to work around this issue. This seems to only affect Samba
> when using it's systemd-unit. When using /usr/sbin/smbd -D, everything
> works fine. For some reason the unit is not aware of zfs-filesystems.
> Might this have something to do with my disks being encrypted with LUKS?
> The pool is not available before manually opened and imported after the
> system has booted. I am using a password to open my disks when the
> system has been fully booted. After that I issue zfs import. Before the
> latest ZoL available on Debian testing (0.7.4) this has never caused any
> issues. Is there a way to manage smbd with systemd like before?
In that scenario samba might have looked at (and cached) the directory
permissions of the mountpoint in the parent filesystem (which most
likely differs vastly from the permissions of '.' in the zfs filesystem
that gets mounted there). A full restart of samba will certainly fix
this, a reload /should/. How you restart/reload samba after mounting
your data is irrelevant (init scripts, systemd or even by manually
killing it and invoking a fresh smbd - all should do the trick), you
only have to do it.
For setups like yours (encrypted data) I use a custom runlevel
(inheriting from the normal multiuser one) containing all the daemons
that access the encrypted data (smb, nfs, iscsi-target, ftp, http, kvm)
which is activated after the pool is successfully unlocked&mounted. That
runlevel also contains a shutdown script that exports the pool, close
the LUKS containers and wipes what might have been left in memory after
the daemons have been stopped, so issuing 'init 3' will bring the system
cleanly back into a secure state.
Similar should be possible with systemd.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zfs-discuss