I'm trying to mount a NetApp share containing users home directories on
a new Solaris 10 (sparc) server.

If we do the mount using the system defaults (i.e. v4,proto=tcp) all the
files end up owned by UID & GID 60001.

On the other hand, if we mount using "-o proto=udp" the file ownership
is correct, but we run into file locking issues.

Has anybody encountered this problem before?  Is there a known fix?

So far, google has given me some similar issues, but nothing recent, and
nothing with a solution.

To make matters more interesting, we have had no problems with Solaris
8, and a Solaris 10 instance running in a zone on another server can
also mount the share correctly.

Debugging is ongoing, unless some kind soul can point us to a solution.


-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
     Asking for technical help in newsgroups?  Read this first:
        http://catb.org/~esr/faqs/smart-questions.html#intro

In article <slrnfq2nna.jvm.postmaster@andor.dropbear.id.au>,
 Paul Colquhoun <postmaster@andor.dropbear.id.au> wrote:

> I'm trying to mount a NetApp share containing users home directories on
> a new Solaris 10 (sparc) server.
> 
> If we do the mount using the system defaults (i.e. v4,proto=tcp) all the
> files end up owned by UID & GID 60001.
> 
> On the other hand, if we mount using "-o proto=udp" the file ownership
> is correct, but we run into file locking issues.
> 
> Has anybody encountered this problem before?  Is there a known fix?
> 
> So far, google has given me some similar issues, but nothing recent, and
> nothing with a solution.
> 
> To make matters more interesting, we have had no problems with Solaris
> 8, and a Solaris 10 instance running in a zone on another server can
> also mount the share correctly.
> 
> Debugging is ongoing, unless some kind soul can point us to a solution.

Have you talked to Network Appliance about this?  Their network filers 
are not without problems and can take some very sophisticated talent to 
debug just where the problem might be.  Case in point, I was a 
contractor at Synopsis and a fellow contractor who'd worked at NetApp 
found that their filers incorrectly sent /device files which made using 
a NetApp for Jumpstart a problem (it would hang with some versions but 
not with others).  I watched in awe as he debugged the truss and network 
traffic to figure out there was a byte swap in the device major and 
minor number for the mounted /device files.

Just for kicks, what happens if you use V3 protocol rather than V4?

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

In <slrnfq2nna.jvm.postmaster@andor.dropbear.id.au> Paul Colquhoun <postmaster@andor.dropbear.id.au> writes:

>I'm trying to mount a NetApp share containing users home directories on
>a new Solaris 10 (sparc) server.

>If we do the mount using the system defaults (i.e. v4,proto=tcp) all the
>files end up owned by UID & GID 60001.

>On the other hand, if we mount using "-o proto=udp" the file ownership
>is correct, but we run into file locking issues.

We've been experiencing similar problems.  It seems to be the result
of a NFSV4 domain mismatch.  At the moment, we've fixed it by
disabling NFSV4 on the Netapp.  We do have the NFSV4 domain set on the
Netapp to what we believe is the same one chosen by Solaris clients.
By default, it's set to the NIS domain, which is incorrect in our
case.  However, I haven't found a way to display the domain chosen by
Solaris 10.  I do know how Solaris is supposed to determine it, but
I need a way to verify this.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

Gary Mills wrote:
> case.  However, I haven't found a way to display the domain chosen by
> Solaris 10.  I do know how Solaris is supposed to determine it, but
> I need a way to verify this.
> 

The default is to use the DNS domain of the server; however, you can override 
this by setting an explicit domain name in /etc/default/nfs with the directive:

NFSMAPID_DOMAIN=yourdomain.whatever

I'm not actually sure how the determination process works or how to display the 
domain name currently being used, which is why I always explicitly set it on all 
OSs and devices.

Neal

In <fnt3c7$sqq$1@mailhub227.itcs.purdue.edu> "Neal A. Lucier" <nlucier@math.purdue.edu> writes:

>Gary Mills wrote:
>> case.  However, I haven't found a way to display the domain chosen by
>> Solaris 10.  I do know how Solaris is supposed to determine it, but
>> I need a way to verify this.
>> 

>The default is to use the DNS domain of the server; however, you can override 
>this by setting an explicit domain name in /etc/default/nfs with the directive:

>NFSMAPID_DOMAIN=yourdomain.whatever

>I'm not actually sure how the determination process works or how to display the 
>domain name currently being used, which is why I always explicitly set it on all 
>OSs and devices.

Yes, that's the part I need to know so I can verify that the names
match.  I also need Jumpstart installs to work, before I've set that
parameter.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

On Thu, 31 Jan 2008 13:50:07 +0000 (UTC), Gary Mills <mills@cc.umanitoba.ca> wrote:
| In <slrnfq2nna.jvm.postmaster@andor.dropbear.id.au> Paul Colquhoun <postmaster@andor.dropbear.id.au> writes:
|
|>I'm trying to mount a NetApp share containing users home directories on
|>a new Solaris 10 (sparc) server.
|
|>If we do the mount using the system defaults (i.e. v4,proto=tcp) all the
|>files end up owned by UID & GID 60001.
|
|>On the other hand, if we mount using "-o proto=udp" the file ownership
|>is correct, but we run into file locking issues.
|
| We've been experiencing similar problems.  It seems to be the result
| of a NFSV4 domain mismatch.  At the moment, we've fixed it by
| disabling NFSV4 on the Netapp.  We do have the NFSV4 domain set on the
| Netapp to what we believe is the same one chosen by Solaris clients.
| By default, it's set to the NIS domain, which is incorrect in our
| case.  However, I haven't found a way to display the domain chosen by
| Solaris 10.  I do know how Solaris is supposed to determine it, but
| I need a way to verify this.


We found the fix.

As it was explained to me, NFSv4 uses actual usernames instead of UID
values, so we had to put a copy of /etc/password & /etc/group onto the
NetApp, so it could do the translations properly.


-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
     Asking for technical help in newsgroups?  Read this first:
        http://catb.org/~esr/faqs/smart-questions.html#intro