Making NFS shares permanent

[Use-Author-Suppli...@127.1]

Dear All,
Can anyone explain the following?

I wish to add another NFS client to the list of hosts a particular
share is is exported to, with RW access. I can see the export details
of the share I'm interested in from the 'share' command, copy it with
the new client's hostname appended and execute it. The modified
export list is then present in the O/P of 'share' and the new client
has RW access. So far so good.

However, the new client's added access is lost across a system reboot
and the O/P of the 'share' command reverts to its previous export list
for the share concerned. According to
http://www.tablespace.net/quicksheet/solaris-quicksheet.pdf to make it
permanent, the modified share command needs to be added to
/etc/dfs/dfstab, which I have just done.

The thing that bothers me is that, prior to adding my modified share
command to /etc/dfs/dfstab, that file was empty (bar a few comments)
but all the other hosts previously granted export access retain them
across reboots.

Another way of asking the same question is: Where does Solaris store
the share information across reboots and how can I edit it? There is
no /etc/exports file and /etc/dfs/sharetab is read-only. I have tried
grepping the files in /etc for evidence of local customisations
relating to NFS shares but found none.

Many thanks
Tom Crane


OS details;
$ uname -a
SunOS server5 5.10 Generic_147441-11 i86pc i386 i86pc


Ps. The email address in the header is just a spam-trap.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T.Crane at rhul dot ac dot uk
Fax: +44 (0) 1784 472794

[John D Groenveld]

In article <ji35un$7t3$1...@mklab.ph.rhul.ac.uk>,

<Use-Author-Supplied-Address-Header@[127.1]> wrote:
>Another way of asking the same question is: Where does Solaris store
>the share information across reboots and how can I edit it? There is
>no /etc/exports file and /etc/dfs/sharetab is read-only. I have tried
>grepping the files in /etc for evidence of local customisations
>relating to NFS shares but found none.

See the sharenfs property of zfs(1M).

John
groe...@acm.org

[ChrisQ]

On 02/22/12 16:43, Use-Author-Supplied-Address-Header@[127.1] wrote:

>
> The thing that bothers me is that, prior to adding my modified share
> command to /etc/dfs/dfstab, that file was empty (bar a few comments)
> but all the other hosts previously granted export access retain them
> across reboots.
>

I'm still using the dfstab approach and asked a similar question a few
days ago. What I found on initial testing was that if you already have
share enabled at zfs level, share gets confused if also defined at
dfstab level, so you need to choose one or the other. This probably
accounts for the disappearance during a reboot.

My initial question was partly due to lack of clue, but I do like the dfstab
approach since it separates the setup for what are separate functions.
If you want to share a mixture of zfs and ufs filesystems, dfstab style
share allows all the share definitions to be in one place.

The received wisdom is the opposite: share via zfs, but you don't have to
agree with it :-)...

Regards,

Chris

[Use-Author-Suppli...@127.1]

ChrisQ <me...@devnull.com> wrote:

John & Chris,
Thanks for that advice. It turns out the existing shares had
been made at the ZFS level. Removing the changes I made to dfstab and
modifying via zfs share fixed the problem and persisted the modified
share across a reboot.

Regards
Tom.