Dfstab entries get invalidated on reboot in S10u6

Question

Hello,
I have installed a Sparc workstation with the lastest Solaris release (Solaris 10 update 6: 10/2008) and with ZFS on all filesystems.
To share directories via NFS, I use the traditional way, i.e. the /etc/dfs/dfstab file.
In this file, I added entries similar to the following:
share -F nfs -d "home directories" /export/home
Enabling the NFS server service with:
svcadm enable nfs/server
works fine. The "share" command effectively displays the shared directories.
However, when rebooting the machine, the NFS server service becomes disabled and the /etc/dfs/dfstab file automatically gets modified with:
# Error: Syntax: share -F nfs -d "home directories" /export/home
By the way, this happens for every share and whether the NFS server service was previously enabled or not.
The modification date of the dfstab file indicates that the modification takes place during Solaris stop, not after the reboot.
Also, in Solaris 10 10/2008, the dfstab file starts with the following warning:
# Do not modify this file directly.
# Use the sharemgr(1m) command for all share management
# This file is reconstructed and only maintained for backward
# compatibility. Configuration lines could be lost.
However, the sharemgr utility is not present in this release.
So how does one enable persitent NFS shares in Solaris 10 10/2008, apart from using "zfs set sharenfs=..." ?

Answer 1

After performing some testing I have found the following: On a clean Solaris install the dfstab file works properly for sharing file systems over NFS. If you set any of the zfs file systems to “sharenfs=on” then the new file sharing system is “activated” and the dfstab file no longer functions in the traditional manner. The following message is prepended at the top of the /etc/dfs/dfstab file:
# Do not modify this file directly.
# Use the sharemgr(1m) command for all share management
# This file is reconstructed and only maintained for backward
# compatibility. Configuration lines could be lost.
If you see this message at the top of you dfstab file you know the “new” method of sharing is now in effect and your dfstab will no longer function in the traditional sense. It appears that several OS operations automatically generate and overwrite the dfstab file for backward compatibility. If you had entries in the dfstab file BEFORE your system “switched” to using the new file sharing system, those shares will remain in the dfstab file and will continue to work properly. If you add new shares to the dfstab file AFTER the system has “switched” to the new file sharing system then those entries will be commented out and the following text will prepend the entry:
# Error: Syntax:
An example would be:
# Error: Syntax: share -F nfs -o rw=bs1.sun.com /export/somefs
You can manually remove the comment and error message and save the changes to the dfstab file and then run shareall and it will work in the traditional sense. However, the lines will be commented out again the next time any OS operation is performed that overwrites the dfstab file.
I have found that rebooting the system overwrites the dfstab file. I was also told that creating or deleting a new pool or file system causes the dfstab to be overwritten also. I have not verified this but it seems logical that anytime an operation is performed that changes the configuration of the zfs pool that the dfstab file would be updated.
This document explains the changes to NFS file sharing and why they were made. After reading this it makes sense that the dfstab file no longer functions in the traditional sense. I only wish I would have been familiar with this before installing a new NFS server. We would like to go back to using old NFS sharing technology but I cannot find any way to go back after the OS “switched” to the new system. We have our reasons for wanting to use the traditional methods for NFS sharing, although they may not be as efficient as the new method.
http://developers.sun.com/solaris/articles/nfs_zfs.html