user id of a nfs mount is -2 / 4294967294?

[Jan Wagner]

Hi,

for some reason after sucessfully mounting the SFU NFS share on the
linux side as user or root, for the mount owner the user id is -2.

I'm not using NIS on the server, but manual user name mapping
(although not Simple Mapping).

I tried Google Groups and saw this problem crops up a lot, but could
not find any solution posted...

In linux the nfs mount is in /etc/fstab as:

192.168.1.108:/viaepia /opt nfs defaults,retry=1,user 0 0

Mount result is below:

jwagner@mini:/opt$ ls -al
total 2
drwxrwxrwx 2 4294967294 root 64 2007-03-17 18:36 .
drwxr-xr-x 21 root root 1024 2007-03-01 19:39 ..
drwxr-xr-x 2 jwagner jwagner 64 2007-03-17 18:36 tmp

4294967294 apparently is the "nobody" user. Any ideas why this is
not root, like the group?

This is my mapping on the SFU server:

[Version]
3
[Domain Maps]
\\$LOCALHOST~:
[Advanced Group Mappings]
*:\\$LOCALHOST\Gäste:0:PCNFS:PCNFS:<unmapped>:-2
*:\\$LOCALHOST\Hauptbenutzer:0:PCNFS:PCNFS:jwagner:1000
*:\\$LOCALHOST\Administratoren:0:PCNFS:PCNFS:root:0
[Advanced User Mappings]
*:<unmapped>:0:PCNFS:PCNFS:<unmapped>::-2:-2
*:\\$LOCALHOST\Administrator:0:PCNFS:PCNFS:root:***censored***:0:0
*:\\$LOCALHOST\jwagner:0:PCNFS:PCNFS:jwagner:***censored***:1000:1000
[Auth Type]
2
[Server Type]
0
[Passwd File]
jwagner:***censored***:1000:1000:jwagner::
root:***censored***:0:0:root::
[Group File]
jwagner::1000:
root::0:

(I post also on comp.os.linux.networking separately, msnews doesn't
allow to crosspost there...)

Many thanks!
- Jan

[Jan Wagner]

Jan Wagner wrote:
> This is my mapping on the SFU server:
>
> [Version]
> 3
> [Domain Maps]
> \\$LOCALHOST~:
> [Advanced Group Mappings]
> *:\\$LOCALHOST\Gäste:0:PCNFS:PCNFS:<unmapped>:-2
> *:\\$LOCALHOST\Hauptbenutzer:0:PCNFS:PCNFS:jwagner:1000
> *:\\$LOCALHOST\Administratoren:0:PCNFS:PCNFS:root:0
> [Advanced User Mappings]
> *:<unmapped>:0:PCNFS:PCNFS:<unmapped>::-2:-2
> *:\\$LOCALHOST\Administrator:0:PCNFS:PCNFS:root:***censored***:0:0
> *:\\$LOCALHOST\jwagner:0:PCNFS:PCNFS:jwagner:***censored***:1000:1000

<snip>

Ok, after removing the -2 group and -2 user mappings, and setting
the Windows Administrator password to be the same as the linux root
password, and in addition using mount options

$ mount
192.168.1.108:/viaepia on /opt type nfs
(rw,noexec,nosuid,nodev,retry=1,addr=192.168.1.108)

and in addition editing C:\SFU\Mapper\.maphosts to actually contain
some allowed hosts (why is it blank per default?? and no mention in
docs?), i.e.:

127.0.0.1+
192.168.1.108+
192.168.1.113+

and rebooting the SFU PC (mapper is not found in Services, plus
"Apply" button in SFU Administration console not quite working with
IE7), then now finally the user id's show up as either root or
jwagner, and not any longer as 4294967294.

It's quite poor of SFU 3.5 not to have any of the normal NFS export
options like no_root_squash. Anyway. A new problem is now if I try
to back up a linux directory onto the NFS mount e.g.

$ cp -arxv / /mnt/nfsbox/

then user and group IDs not yet known in the SFU PC, for example
wheel, haldaemon, messagebus etc, are all assigned by SFU to root in
the nfs mount.

So while permissions are copied intact, SFU apparently reassigns
owner and group (??) In normal NFS it would just set the user and
group ids of the files and directories even if they are not found on
the server side. SFU apparently does this different? Any ideas?

TIA,
- Jan

[Jan Wagner]

Jan Wagner wrote:

> Jan Wagner wrote:
> So while permissions are copied intact, SFU apparently reassigns owner
> and group (??) In normal NFS it would just set the user and group ids of
> the files and directories even if they are not found on the server side.
> SFU apparently does this different? Any ideas?

Anyone? Oh well. I'll probably end up having to add all umphteen
unix users and groups onto the SFU machine.

Strange that in 3.0 you apparently could map users and groups
many-to-one, but in 3.5 not any longer. So one can't map all unix
groups back onto one and the same Windows group (?)

- Jan