I've seen the man page for share_nfs, tried a couple of different
things it suggests, and, yet, it still doesn't work the way I need it
to. I'm able to mount a filesystem from "server" on "gold2," and
create files, etc, but the files I create on the NFS partition are all
owned by "nobody" - no surprise there - and I can't "chown" them.
That's what's confusing: why can I create them in the first place, but
can't chown them?

Both systems are Solaris 10 Sparc hosts. No special PAM or other
security configuration; they're pretty much straight out of the box.

Here's the latest "share" incantation:

share -F nfs -o root=gold2 -d "backup volume" /backup_vol

I've also tried:

share -F nfs -o anon=0,root=gold2 -d "backup volume" /backup_vol
share -F nfs -o rw,root=gold2 -d "backup volume" /backup_vol
share -F nfs -o root=gold2,rw -d "backup volume" /backup_vol

And probably a couple others.

I'm not doing anything special in the "mount" command:

mount server:/backup_vol /backup_1tb

I umount & mount after each change in the share command on the server,
so it should be getting the correct parameters from the server each
time.

Like I said, I can create files & directories on the server just fine,
but they're all owned by nobody - at least as I look at the file
ownerships and permissions from "gold2"; they're owned by "root" when
I look at them on "server" - and I can't do much more than create and
delete them. I need to be able to set ownership & permissions.

If I had any hair, I'd be pulling it out about now, so I'd be much
obliged for any assistance.

Thanks,

Aaron

On Fri, 8 Feb 2008 18:27:02 -0800 (PST), aaron@mcs-partners.com <aaron@mcs-partners.com> wrote:
| I've seen the man page for share_nfs, tried a couple of different
| things it suggests, and, yet, it still doesn't work the way I need it
| to. I'm able to mount a filesystem from "server" on "gold2," and
| create files, etc, but the files I create on the NFS partition are all
| owned by "nobody" - no surprise there - and I can't "chown" them.
| That's what's confusing: why can I create them in the first place, but
| can't chown them?
|
| Both systems are Solaris 10 Sparc hosts. No special PAM or other
| security configuration; they're pretty much straight out of the box.
|
| Here's the latest "share" incantation:
|
| share -F nfs -o root=gold2 -d "backup volume" /backup_vol
|
| I've also tried:
|
| share -F nfs -o anon=0,root=gold2 -d "backup volume" /backup_vol
| share -F nfs -o rw,root=gold2 -d "backup volume" /backup_vol
| share -F nfs -o root=gold2,rw -d "backup volume" /backup_vol
|
| And probably a couple others.
|
| I'm not doing anything special in the "mount" command:
|
| mount server:/backup_vol /backup_1tb
|
| I umount & mount after each change in the share command on the server,
| so it should be getting the correct parameters from the server each
| time.
|
| Like I said, I can create files & directories on the server just fine,
| but they're all owned by nobody - at least as I look at the file
| ownerships and permissions from "gold2"; they're owned by "root" when
| I look at them on "server" - and I can't do much more than create and
| delete them. I need to be able to set ownership & permissions.
|
| If I had any hair, I'd be pulling it out about now, so I'd be much
| obliged for any assistance.


I think Solaris 10 defaults to NFSv4 for mounts. This uses TCP, and also
uses text username and group information, rather than numeric UID/GID.

This means that the machine 'server' needs a copy of the /etc/passwd &
/etc/group file so it can translate ownership correctly.

To test this, try explicitly using NFSv3 in the mount command on
'gold2'. Giving option '-o proto=udp' (I think) should do it.


--
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

On Sat, 09 Feb 2008 06:49:04 GMT Paul Colquhoun <postmaster@andor.dropbear.id.au> wrote:
> I think Solaris 10 defaults to NFSv4 for mounts.

It does.

> This uses TCP,

Yes, it does.

> and also uses text username and group information, rather than
> numeric UID/GID.

No. Where did you get that from?

-frank