Your link below is to documentation that predates the introduction of the ZFS filesystem under Solaris 10.
Back in those days, the /etc/dfs/dfstab file was used by file server startup scripts to automatically export the listed filesystems during system boot. It describes
what is intended. (Note: It is typically used for NFS, but is written for any file services)
The /etc/dfs/sharetab file is updated by the operating system, and thus represents what actually is.
I’m assuming that the NFS exports plugin was written to monitor what was intended, so if a file system failed to export, it would be flagged as such.
With the introduction of ZFS, a new mechanism was introduced to manage exported file systems. For mixed file system environments like Solaris 10, this is in
addition to, rather than in replacement of the /etc/dfs/dfstab file.
If you run ‘zfs get all | grep share’ you will see all the ZFS variables used to define exported file systems. Since we are only interested in NFS file systems,
we can stick to the ‘sharenfs’ entries, and ignore the ‘sharecifs’ and ‘shareiscsi’ entries.
You will need to update the plugin to read both /etc/dfs/dfstab and the output of ‘zfs get sharenfs’ and make choices based on them.
On Behalf Of David Chapman
···
I am going through a check_mk deployment on a heavily Solaris shop (10 and 11). I went to implement the nfsexports.solaris plugin and noticed it is checking for dfstab but that file is typically empty on our installation and its the sharetab
that contains the shares. I am wondering if anyone has some expertise on this as to why the default plugin uses dfstab.
I found this article describing the differences between the files and it seems that sharetab is probably more correct.
https://nnc3.com/mags/Networking2/nfs/ch06_02.htm
Thanks!