HELP: VMS as an NFS client to Windows or Linux - primer please

[Gremlin]

OK, so perhaps we can start and do a primer for VMS8.2 as a client to
NFS on Windows2003 and/or Linux.

Starting point:
- I have an NFS server on Windows2003R2 and SuSE Linux and Solaris10 and
Reh Hat EL5 and can connect any client OS to them using anonymous access
rights - except VMS (which I can't even connect when I specify
username/GID/UID). I feel it is safe to say the NFS servers are working
OK on all the OSes.

- I can ping the server names from VMS
- the files in the NFS share area are full access to anyone, including
anonymous - the directory is the same
- tcpip sho proxy shows my VMS username with UID 0 GID 0 outbound to all
the NFS servers
- Windows mapping shows the "unix" username the same as my VMS username
and it is mapped to a Windows domain administrator account
- The Windows domain administrator account has full access to all files
(I checked) and also the share and all the directories.

- I can issue the following commands to any OS noted above and the
command(s)complete OK:
-tcpip mount DNSF0: data /host="servername" /path="NFSshareName"
/system /struct=5 /noadf
-tcpip mount DNSF0: data /host="servername" /path="NFSshareName"
/struct=5 /noadf /gid=0 /uid=0
-tcpip mount DNSF0: data /host="servername" /path="NFSshareName"
/struct=5 /noadf /gid=-2 /uid=-2
where DNSF0: can also be DNSF1: or any other integer to give it the
same mount point each time
where NFSshareName has been the NFS share as exported by the OS, or the
actual path (/f/data/nfs/)

- I cannot successfully do dir dnsf0:[000000] - I typically get device
timeout....however, thanks to a reply on a similar post a couple of days
ago, I added to /NOADF flag and now I get -RMS-E-PRV, insufficient
privilege or file protection violation, AND now Windows is logging
mapping errors - still works fine with Solaris, SuSE etc....

So, the /NOADF flag got rid of the timeout but exposed a mapping
flaw(?). On the Windows side, anonymous access is allowed on the share
and my VMS username is mapped to a Windows Domain Administrator account
with full access to everything - so why the mapping error......

[JF Mezei]

I don't recall how I succeeded this yet.

But this is what SHOW MOUNT/FULL shows:
> $ tcpip show mount/full
> _DNFS1:[000000] mounted
> BRAKES.vixenation.ca:/
> Transport TCPIP-UDP Writing Enabled
> Read/write size 8192/8192 Write conversion Enabled
> RPC timeout 0 00:00:01.00 ADF usage USE,UPDATE,CREATE
> RPC retry limit 4 Fileids Unique
> Attribute time 0 00:00:15.00 Server type UNIX
> Directory time 0 00:00:30.00 Advisory Locking Disabled
> Cache Validation MODIFY TIME Default user [DECNET]
> Superuser No Default UID,GID 501,501


501,501 is the uid/gid of my account on the mac. So by default, the mac
lets the vms machine act as me in terms of file accesses.

But I also have a proxy for both incoming and outgoing mapping my VMS
username to 501,501, and mapping SYSTEM to 0,0

To get ODS5 capabilities, you need to specify the server type of UNIX,
even if the doc says it is there by default.

[Gremlin]

JF Mezei wrote:
> I don't recall how I succeeded this yet.
>
> But this is what SHOW MOUNT/FULL shows:
>> $ tcpip show mount/full
>> _DNFS1:[000000] mounted
>> BRAKES.vixenation.ca:/
>> Transport TCPIP-UDP Writing Enabled
>> Read/write size 8192/8192 Write conversion Enabled
>> RPC timeout 0 00:00:01.00 ADF usage USE,UPDATE,CREATE
>> RPC retry limit 4 Fileids Unique
>> Attribute time 0 00:00:15.00 Server type UNIX
>> Directory time 0 00:00:30.00 Advisory Locking Disabled
>> Cache Validation MODIFY TIME Default user [DECNET]
>> Superuser No Default UID,GID 501,501
>
>
> 501,501 is the uid/gid of my account on the mac. So by default, the mac
> lets the vms machine act as me in terms of file accesses.
>
> But I also have a proxy for both incoming and outgoing mapping my VMS
> username to 501,501, and mapping SYSTEM to 0,0
>
> To get ODS5 capabilities, you need to specify the server type of UNIX,
> even if the doc says it is there by default.

Hi JF

What is your mount command, as I can't see a path in the listing above?

If I use tcpip mou/host="x.y.z"/path="NFSdata" etc...(which is the NFS
share exported name ) I get:
$ tcpip sho mou/fu
_DNFS1:[000000] mounted
monitorserver.x.y.z:nfsdata
Transport TCPIP-UDP Writing Enabled
Read/write size 8192/8192 Write conversion Enabled
RPC timeout 0 00:00:01.00 ADF usage NOUSE,NOUPDATE,NOCREATE
RPC retry limit 4 Fileids Unique
Attribute time 0 00:00:15.00 Server type UNIX
Directory time 0 00:00:30.00 Advisory Locking Disabled
Cache Validation MODIFY TIME Default user [DEFAULT]
Superuser No Default UID,GID 0,0

If I use tcpip mou/host="x.y.z"/path="/d/nfsdata/" etc...(which is the
disk/directory structure location on the windows server) I get:
$ tcpip sho mou/fu
_DNFS1:[000000] mounted
monitorserver.x.y.z:/d/nfsdata
Transport TCPIP-UDP Writing Enabled
Read/write size 8192/8192 Write conversion Enabled
RPC timeout 0 00:00:01.00 ADF usage NOUSE,NOUPDATE,NOCREATE
RPC retry limit 4 Fileids Unique
Attribute time 0 00:00:15.00 Server type UNIX
Directory time 0 00:00:30.00 Advisory Locking Disabled
Cache Validation MODIFY TIME Default user [DEFAULT]
Superuser No Default UID,GID 0,0

0,0 doesn't exist - so I deleted the mappings in Windows and started by
creating a group mapping of 4 for system and 100 for users. I then
mapped users with 1 for domain admins and also 1 for my windows username.

So, when I issue the mount command I have now tried it with /UID=1/GID=4
(VMS system account UIC) and /UID=1/GID=100 (my vms UIC). Both mount
fine but neither will not allow me to list the files - I still get a
user mapping error - only on Windows, the others still work fine
*without* any of the crazy flags.......

So, using a /UID/GID that matches a VMS UIC still gives me the
RMS-E-PRV, but *doesn't* give a windows mapping failure!!!!! By
default, the anonymous UID/GID on windows is -2,-2. If I change that to
1,4 (ie VMS system), then I again get windows mapping failures even if I
mount with /UID=1/GID=4.

In summary, on VMS using a "real" UIC to map to a windows UID/GID makes
no difference to the mount result, but *does* stop the windows mapping
errors in the log file. However, I still get the RMS-E-PRV, so VMS
still doesn't like something.....

[Gorazd Kikelj]

When mapping UID/GID from VMS to Windows and vice versa
you need to have hostnames in local database and also proxies defined
correctly.

And most important, also need the right mapping on windows.

So here are steps:

1. Add host into TCPIP local host database
2. Define proxies for VMS users
TCPIP ADD PROXY user /UID=uid /GID=gid /HOST=winhost
3. Create passwd file
winuser:x:uid:gid::::user - VMSUSER
...
here you'll create translation betwen VMS users and Windows
users via uid/gid pairs.

4. Define username mapping server on windows .
5. List mapping servers in .maphosts file.
6. Use simple maps and passwd file as source in "User Name Mapping" for
users.
7. now you should be ready to mount nfs drive via
MOUNT DNFSx: vol_label log_name /path="unix_path" /host=host
/structure=ods5/noadf

If mappings is working, then now you should have working access to NFS
drive.

Most problems arise due to nonworking username mappings.

Best, Gorazd

[Gremlin]

Gorazd Kikelj wrote:
> When mapping UID/GID from VMS to Windows and vice versa
> you need to have hostnames in local database and also proxies defined
> correctly.
>
> And most important, also need the right mapping on windows.
>
> So here are steps:
>
> 1. Add host into TCPIP local host database
> 2. Define proxies for VMS users
> TCPIP ADD PROXY user /UID=uid /GID=gid /HOST=winhost
> 3. Create passwd file
> winuser:x:uid:gid::::user - VMSUSER
> ...
> here you'll create translation betwen VMS users and Windows
> users via uid/gid pairs.
>
> 4. Define username mapping server on windows .
> 5. List mapping servers in .maphosts file.
> 6. Use simple maps and passwd file as source in "User Name Mapping" for
> users.
> 7. now you should be ready to mount nfs drive via
> MOUNT DNFSx: vol_label log_name /path="unix_path" /host=host
> /structure=ods5/noadf
>
> If mappings is working, then now you should have working access to NFS
> drive.
>
> Most problems arise due to nonworking username mappings.
>
> Best, Gorazd
>
>
>
>
Hi All (and thanks for taking the time to think about this....)

So, on the VMS side...

TCPIP> sho prox/fu

VMS User_name Type User_ID Group_ID Host_name

Me OND 1 100 *

In windows, passwd file:
root:x:1:4:root::::/root:/bin/sh
Me:x:1:100::::Me:/Me:/bin/sh
system:x:1:4::::system:/system:/bin/sh

Mapping in windows is:
- Windows Me to "unix" me
- Windows Administrator to "unix" system

On Windows2003R2 there is no .maphosts file

Mount works fine, listing directory contents fails with mapping error...

[Gorazd Kikelj]

"Gremlin" <***@all.com> wrote in message
news:***@corp.supernews.com...
> Hi All (and thanks for taking the time to think about this....)
>
> So, on the VMS side...
>
> TCPIP> sho prox/fu
>
> VMS User_name Type User_ID Group_ID Host_name
>
> Me OND 1 100 *
>
> In windows, passwd file:
> root:x:1:4:root::::/root:/bin/sh
> Me:x:1:100::::Me:/Me:/bin/sh
> system:x:1:4::::system:/system:/bin/sh

You should have only Windows usernames in first column. So if you don't
have root or system users on windows, don't put it there. Use only windows
names.
And don't use more than one user->UID/GID mapping. It will scrue mappings
completly.

So use passwd file like this:
Administrator:x:10:4:root::::/root:/bin/sh
Me:x:1:100::::Me:/Me:/bin/sh

UID MUST BE UNIQUE!!!!!!!


>
> Mapping in windows is:
> - Windows Me to "unix" me
> - Windows Administrator to "unix" system


>
> On Windows2003R2 there is no .maphosts file
>
> Mount works fine, listing directory contents fails with mapping error...

If .maphosts file doesn't exist, you should create one :-)
At least on SFU it is located at \msnfs\mapper\.maphosts
and it should have localhost in it.

As I write before, most probably reason that you can't access files is
in username mappings. Try resync it. Also there was a fameous problem
with windows authorization if you have more than one DC on network. And
if NFS server is not DC, then DC need to have Authorization Service for NFS
installed (at least for SFU to work)

Best, Gorazd

[Gremlin]

Gorazd Kikelj wrote:
> "Gremlin" <***@all.com> wrote in message
> news:***@corp.supernews.com...
>> Hi All (and thanks for taking the time to think about this....)
>>
>> So, on the VMS side...
>>
>> TCPIP> sho prox/fu
>>
>> VMS User_name Type User_ID Group_ID Host_name
>>
>> Me OND 1 100 *
>>
>> In windows, passwd file:
>> root:x:1:4:root::::/root:/bin/sh
>> Me:x:1:100::::Me:/Me:/bin/sh
>> system:x:1:4::::system:/system:/bin/sh
>
> You should have only Windows usernames in first column. So if you don't
> have root or system users on windows, don't put it there. Use only windows
> names.
> And don't use more than one user->UID/GID mapping. It will scrue mappings
> completly.
>
> So use passwd file like this:
> Administrator:x:10:4:root::::/root:/bin/sh
> Me:x:1:100::::Me:/Me:/bin/sh
>
> UID MUST BE UNIQUE!!!!!!!
>
>
>> Mapping in windows is:
>> - Windows Me to "unix" me
>> - Windows Administrator to "unix" system
>
>
>> On Windows2003R2 there is no .maphosts file
>>
>> Mount works fine, listing directory contents fails with mapping error...
>
> If .maphosts file doesn't exist, you should create one :-)
> At least on SFU it is located at \msnfs\mapper\.maphosts
> and it should have localhost in it.
>
> As I write before, most probably reason that you can't access files is
> in username mappings. Try resync it. Also there was a fameous problem
> with windows authorization if you have more than one DC on network. And
> if NFS server is not DC, then DC need to have Authorization Service for NFS
> installed (at least for SFU to work)
>
> Best, Gorazd
>
>
>
Hi

Yes, realised the problem with the passwd file, so it is now changed to be:
WindowsName:x:1001:100::::

Also changed UID to 1001 to get past any special account/UID problems...

.maphosts does exist in Windows2003R2, in c:\windows\msnfs, it now has a
single entry of +, meaning anything can access mapping services.

From Windows2003R2 server running NFS server....

D:\NFSdata>showmount -e localhost
Exports list on localhost:
/nfsdata All Machines

So the NFS export is there OK

D:\NFSdata>showmount -a localhost
All mount points on localhost:
192.168.100.205 : D:\NFSdata <- VMS client
192.168.100.58 : D:\NFSdata <- Solaris 10 client
192.168.100.61 : D:\NFSdata <- SuSE client

Solaris 10 and SuSE client work right out of the box, so the windows
mapping must be OK on the windows side - the Solaris and SuSE boxen are
accessing anonymously, which VMS can't/won't

From VMS

$ tcpip sho proxy/full

VMS User_name Type User_ID Group_ID Host_name

VMSusername OND 1001 100 *

Mount statement from VMS is:

$ tcpip mou dnfs1: data1 /host="x.y.z" /system /structure=5
/noadf /path="/nfsdata"/uid=1001/gid=100/user=VMSusername
%TCPIP$DNFSMOUNT-S-MOUNTED, nfsdata mounted on _DNFS1:[000000]

$ tcpip sho mou/fu
_DNFS1:[000000] mounted
x.y.z:/nfsdata
Transport TCPIP-UDP Writing Enabled
Read/write size 8192/8192 Write conversion Enabled
RPC timeout 0 00:00:01.00 ADF usage NOUSE,NOUPDATE,NOCREATE
RPC retry limit 4 Fileids Unique
Attribute time 0 00:00:15.00 Server type UNIX
Directory time 0 00:00:30.00 Advisory Locking Disabled
Cache Validation MODIFY TIME Default user [VMSusername]
Superuser No Default UID,GID 1001,100

$ dir dnfs1:[000000]
%DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
-RMS-E-PRV, insufficient privilege or file protection violation

So.......any other suggestions?? I really do appreciate all the
mind-power going into this, but something on the VMS side is just
weird.....but what? The mounting is fine, the mapping seems broken -
but the password file is simple, the .maphosts allows anything and their
is only a single proxy entry on the VMS side.

[Gorazd Kikelj]

"Gremlin" <***@all.com> wrote in message
news:***@corp.supernews.com...
> From VMS
>
> $ tcpip sho proxy/full
>
> VMS User_name Type User_ID Group_ID Host_name
>
> VMSusername OND 1001 100 *
>
> Mount statement from VMS is:
>
> $ tcpip mou dnfs1: data1 /host="x.y.z" /system /structure=5
> /noadf /path="/nfsdata"/uid=1001/gid=100/user=VMSusername
> %TCPIP$DNFSMOUNT-S-MOUNTED, nfsdata mounted on _DNFS1:[000000]
>

Discard /UID /GID parameters from mount for start.
There can be problems with * in proxy. Try with hostname and
put hostname also in local tcpip database.

Best, Gorazd

[Gorazd Kikelj]

"Gremlin" <***@all.com> wrote in message
news:***@corp.supernews.com...
>
> From VMS
>
> $ tcpip sho proxy/full
>
> VMS User_name Type User_ID Group_ID Host_name
>
> VMSusername OND 1001 100 *
>
...
> $ dir dnfs1:[000000]
> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
> -RMS-E-PRV, insufficient privilege or file protection violation
>

and be logged as VMSusername when trying access.

Best, Gorazd

[Gremlin]

Gorazd Kikelj wrote:
> "Gremlin" <***@all.com> wrote in message
> news:***@corp.supernews.com...
>> From VMS
>>
>> $ tcpip sho proxy/full
>>
>> VMS User_name Type User_ID Group_ID Host_name
>>
>> VMSusername OND 1001 100 *
>>
> ...
>> $ dir dnfs1:[000000]
>> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
>> -RMS-E-PRV, insufficient privilege or file protection violation
>>
>
> and be logged as VMSusername when trying access.
>
> Best, Gorazd
>
>

OK, so now...
$ tcpip sho proxy/full

VMS User_name Type User_ID Group_ID Host_name

VMSusername OND 1001 100 WindowsHost

Logged in as VMSusername, which has lots of privs including sysprv etc.

Same problem.....

[Gorazd Kikelj]

"Gremlin" <***@all.com> wrote in message
news:***@corp.supernews.com...
> Gorazd Kikelj wrote:
>> "Gremlin" <***@all.com> wrote in message
>> news:***@corp.supernews.com...
>>> From VMS
>>>
>
> OK, so now...
> $ tcpip sho proxy/full
>
> VMS User_name Type User_ID Group_ID Host_name
>
> VMSusername OND 1001 100 WindowsHost
>
> Logged in as VMSusername, which has lots of privs including sysprv etc.
>
> Same problem.....
>

NFS server reject the connection. Can you get some TCPIP traces to see, what
UID/GID
you are getting on windows side.

Problem is on Windows side. No VMS privs will help with that :-(

Best, Gorazd

[Gremlin]

Gorazd Kikelj wrote:
> "Gremlin" <***@all.com> wrote in message
> news:***@corp.supernews.com...
>> Gorazd Kikelj wrote:
>>> "Gremlin" <***@all.com> wrote in message
>>> news:***@corp.supernews.com...
>>>> From VMS
>>>>
>> OK, so now...
>> $ tcpip sho proxy/full
>>
>> VMS User_name Type User_ID Group_ID Host_name
>>
>> VMSusername OND 1001 100 WindowsHost
>>
>> Logged in as VMSusername, which has lots of privs including sysprv etc.
>>
>> Same problem.....
>>
>
> NFS server reject the connection. Can you get some TCPIP traces to see, what
> UID/GID
> you are getting on windows side.
>
> Problem is on Windows side. No VMS privs will help with that :-(
>
> Best, Gorazd
>
>
I guess the problem is on the Windows side, but it must be because of
something the VMS side is sending. As I noted earlier, I can use any
Linux client to connect without specifying anything - it works in
anonymous mode!!

So there should be a "dummy" mode in VMS that works the same...

[JF Mezei]

Gremlin wrote:

> $ tcpip mou dnfs1: data1 /host="x.y.z" /system /structure=5
> /noadf /path="/nfsdata"/uid=1001/gid=100/user=VMSusername
> %TCPIP$DNFSMOUNT-S-MOUNTED, nfsdata mounted on _DNFS1:[000000]

you need to specify /SERVER=UNIX for the /structure=5 to be effective.
But this isn't related to your cuirrent problem.


> $ dir dnfs1:[000000]
> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
> -RMS-E-PRV, insufficient privilege or file protection violation


Which username is being used to do the mount, and which username is used
to do the DIR ? You would need outgoing proxies for both.

You might also want do do a SHOW DEV DNFSx: /FULL

Mine gives:

> show dev dnfs1/full
>
> Disk DNFS1: (CHAIN), device type Foreign disk type 7, is online, mounted, file-
> oriented device, shareable, accessed via DFS or NFS.
>
> Error count 0 Operations completed 13852
> Owner process "" Owner UIC [SYSTEM]
> Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL
> Reference count 1 Default buffer size 512
> Total blocks 38835000 Sectors per track 0
> Total cylinders 0 Tracks per cylinder 0
> Allocation class 11
>
> Volume label "BRAKES$/" Relative volume number 0
> Cluster size 0 Transaction count 1
> Free blocks unknown Maximum files allowed 0
> Extend quantity 0 Mount count 1
> Mount status System ACP process name "DNFS1ACP"
>
> Volume Status: ODS-5, access dates enabled.



Remember that MOUNT deals with the MOUNTD deamon at the other end,
whereas the DIR deals with the NFS deamon. Does Windows offer any tools
to monitor the NFS mounting ?

[Gremlin]

JF Mezei wrote:
> Gremlin wrote:
>
>> $ tcpip mou dnfs1: data1 /host="x.y.z" /system /structure=5
>> /noadf /path="/nfsdata"/uid=1001/gid=100/user=VMSusername
>> %TCPIP$DNFSMOUNT-S-MOUNTED, nfsdata mounted on _DNFS1:[000000]
>
> you need to specify /SERVER=UNIX for the /structure=5 to be effective.
> But this isn't related to your cuirrent problem.
>
>
>> $ dir dnfs1:[000000]
>> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
>> -RMS-E-PRV, insufficient privilege or file protection violation
>
>
> Which username is being used to do the mount, and which username is used
> to do the DIR ? You would need outgoing proxies for both.
>
> You might also want do do a SHOW DEV DNFSx: /FULL
>
> Mine gives:
>
>> show dev dnfs1/full
>>
>> Disk DNFS1: (CHAIN), device type Foreign disk type 7, is online, mounted, file-
>> oriented device, shareable, accessed via DFS or NFS.
>>
>> Error count 0 Operations completed 13852
>> Owner process "" Owner UIC [SYSTEM]
>> Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL
>> Reference count 1 Default buffer size 512
>> Total blocks 38835000 Sectors per track 0
>> Total cylinders 0 Tracks per cylinder 0
>> Allocation class 11
>>
>> Volume label "BRAKES$/" Relative volume number 0
>> Cluster size 0 Transaction count 1
>> Free blocks unknown Maximum files allowed 0
>> Extend quantity 0 Mount count 1
>> Mount status System ACP process name "DNFS1ACP"
>>
>> Volume Status: ODS-5, access dates enabled.
>
>
>
> Remember that MOUNT deals with the MOUNTD deamon at the other end,
> whereas the DIR deals with the NFS deamon. Does Windows offer any tools
> to monitor the NFS mounting ?
Hi JF

Earlier posts showed that the server type was showing as UNIX when doing
a tcpip sho/mount. Also, the posts showed using Windows nfsstat showing
that the VMS had successfully mounted the share.

I am using the same username to mount/access the share and have done a
set proc/priv=all just to be sure.....it has outgoing proxies set...

[JF Mezei]

Gremlin wrote:

> I am using the same username to mount/access the share and have done a
> set proc/priv=all just to be sure.....it has outgoing proxies set...


The VMS privileges are absolutely , totally meaningless to grant you
access to the remote server. The remote server decides what you can and
cannot access and it has no idea nor concept of what your VMS privileges
are.

It was relatively easy for me to get the VMS client to mount the MAC
disk. But the other way around took a lot more trial and error, probably
because automount runs as root and the actual accesses are done by my
username. The fix ended up being with the proxies on VMS.

I would suggest you take a serious look at the windows setup to ensure
you have the right flags setup and that the exported directory belongs
to the user who will be accessing it.

aka: make sure that the VMS username is mapped to a UID/GID combination
which, on windows is mapped to a windows username that has read/write
access to the directory you are exporting.

[Gremlin]

JF Mezei wrote:
> Gremlin wrote:
>
>> I am using the same username to mount/access the share and have done a
>> set proc/priv=all just to be sure.....it has outgoing proxies set...
>
>
> The VMS privileges are absolutely , totally meaningless to grant you
> access to the remote server. The remote server decides what you can and
> cannot access and it has no idea nor concept of what your VMS privileges
> are.
>
> It was relatively easy for me to get the VMS client to mount the MAC
> disk. But the other way around took a lot more trial and error, probably
> because automount runs as root and the actual accesses are done by my
> username. The fix ended up being with the proxies on VMS.
>
> I would suggest you take a serious look at the windows setup to ensure
> you have the right flags setup and that the exported directory belongs
> to the user who will be accessing it.
>
> aka: make sure that the VMS username is mapped to a UID/GID combination
> which, on windows is mapped to a windows username that has read/write
> access to the directory you are exporting.
>
>
>
>
Hi JF

It is increasingly frustrating because it is *only* the VMS client that
show the mapping error when trying to access the NFS mount. All clients
can mount - including VMS. Only VMS can't read/list.

So, on the VMS side I use a single username and I am logged in as it.
That username and the NFS host is in the proxy with outgoing/incoming
access to the NFS server. So far, so good.

The Windows side has a single mapping entry for users with the identical
VMS username, UID and GID. It is mapped to a windows domain
administrator account which has full rights over everything on the
Windows environment. I checked the detailed permissions on the
directory/file area and it has full access for all files, subfolders
etc. And besides, any Linux client *can* list the files in anonymous mode.

The .maphosts file has a single entry, +

I cannot make it any simpler, but *something* the VMS client is doing is
broken - at the very least, with no proxy entry the access should appear
to be anonymous and then work like *all* the linux clients - but it
doesn't!!

[JF Mezei]

Mr (or Mrs) Gremlin,

I strongly suggest you take a good look at the TCPIP Services Management
manual. It can be consulted at http://www.hp.com/go/vms and follow the
links to the VMS documentation. Make sure you select the right TCPIP
Services version.

There is a significant section on NFS in that manual, and it discusses
the proxy issue. Don't rely on what the manual says is "default",
specify it in the command line.

It is also important to specify which version of TCPIP Services you have.

I just tried to setup NFS on my old VAX (7.3 VMS, 5.3 TCPIP Services)

> TCPIP> add proxy jfmezei/uid=501/gid=501/host=brakes
> TCPIP> add proxy system/uid=0/gid=0/host=brakes
> TCPIP> mount dnfs1:/host=brakes/path="/"/uid=501/gid=501/server=unix/system
> %TCPIP$DNFSMOUNT-S-MOUNTED, / mounted on _DNFS1:[000000]
> TCPIP> exit
> $ dir dnfs1:[000000]
>
> Directory DNFS1:[000000]
>
> $5N$S$POTLIGHT-$V100.DIR;1 $5N$T$RASHES.DIR;1 $5NVOL.DIR;1
> $A$PPLICATIONS$C$LASSIC.DIR;1 $A$PPLICATIONS.DIR;1
> $C$LEANUP$7A$A$T$7A$S$TARTUP.DIR;1 $D$ESKTOP$7A$DB.;1 $D$ESKTOP$7A$DF.;1
> $D$ESKTOP$7A$F$OLDER.DIR;1 $D$ESKTOP$P$RINTERS$7A$DB.;1
> $D$EVELOPER.DIR;1 $L$IBRARY.DIR;1 $N$ETWORK$7A$T$RASH$7A$F$OLDER.DIR;1
> $N$ETWORK.DIR;1 $NAVM$AC800$QSF$ILE.;1
> $O$PEN$F$OLDER$L$IST$DF$4M.;1 $R$AILROAD$7A$T$YCOON.DIR;1
> $S$OFTWARE.DIR;1 $S$YSTEM$7A$F$OLDER.DIR;1 $S$YSTEM.DIR;1
> $T$HE$V$OLUME$S$ETTINGS$F$OLDER.DIR;1 $U$SERS.DIR;1 $V$OLUMES.DIR;1
> .$DS_S$TORE;1 .HIDDEN;1 .HOTFILES$5NBTREE;1
> .SYM$S$CHED$S$CAN$L$OCKXZ;1 AUTOMOUNT.DIR;1 BIN.DIR;1
> CORES.DIR;1 DEV.DIR;1 DISK2.DIR;1 ETC.;1
> MACH.;1 MACH.SYM;1 MACH_KERNEL.;1 PRIVATE.DIR;1
> SBIN.DIR;1 TMP.;1 USR.DIR;1 VAR.;1
>
> Total of 41 files.

(weird file names is due to VAX-VMS not understanding modern filename).

> TCPIP> show mount/full
> _DNFS1:[000000] mounted
> BRAKES.vaxination.ca:/
> Transport TCPIP-UDP Writing Enabled
> Read/write size 8192/8192 Write conversion Enabled
> RPC timeout 0 00:00:01.00 ADF usage USE,UPDATE,CREATE
> RPC retry limit 4 Fileids Unique
> Attribute time 0 00:00:15.00 Server type UNIX
> Directory time 0 00:00:30.00 Advisory Locking Disabled
> Cache Validation MODIFY TIME Default user [DECNET]
> Superuser No Default UID,GID 501,501


OK, I have done a bit of testing. It appears that SYSTEM on VMS doesn't
really map to 0,0 on the remote system even if I have a proxy setup for
it. But of I git the /GID=501/UID=501, then SYSTEM has teh same access
as 501,501 on the remote system.


Set the /UID /GID in the mount command to the combo that is mapped to
the owner of the directory on the remote system. If that doesn't work,
then set all files in that directory (and the directory itself) to be
world readable and test again.

(These tests were done on the vax, not on the more recent TCOPIP 5.6 on
alpha)

[Gremlin]

JF Mezei wrote:
> Mr (or Mrs) Gremlin,
>
> I strongly suggest you take a good look at the TCPIP Services Management
> manual. It can be consulted at http://www.hp.com/go/vms and follow the
> links to the VMS documentation. Make sure you select the right TCPIP
> Services version.
>
> There is a significant section on NFS in that manual, and it discusses
> the proxy issue. Don't rely on what the manual says is "default",
> specify it in the command line.
>
> It is also important to specify which version of TCPIP Services you have.
>
> I just tried to setup NFS on my old VAX (7.3 VMS, 5.3 TCPIP Services)
>
>> TCPIP> add proxy jfmezei/uid=501/gid=501/host=brakes
>> TCPIP> add proxy system/uid=0/gid=0/host=brakes
>> TCPIP> mount dnfs1:/host=brakes/path="/"/uid=501/gid=501/server=unix/system
>> %TCPIP$DNFSMOUNT-S-MOUNTED, / mounted on _DNFS1:[000000]
>> TCPIP> exit
>> $ dir dnfs1:[000000]
>>
>> Directory DNFS1:[000000]
>>
>> $5N$S$POTLIGHT-$V100.DIR;1 $5N$T$RASHES.DIR;1 $5NVOL.DIR;1
>> $A$PPLICATIONS$C$LASSIC.DIR;1 $A$PPLICATIONS.DIR;1
>> $C$LEANUP$7A$A$T$7A$S$TARTUP.DIR;1 $D$ESKTOP$7A$DB.;1 $D$ESKTOP$7A$DF.;1
>> $D$ESKTOP$7A$F$OLDER.DIR;1 $D$ESKTOP$P$RINTERS$7A$DB.;1
>> $D$EVELOPER.DIR;1 $L$IBRARY.DIR;1 $N$ETWORK$7A$T$RASH$7A$F$OLDER.DIR;1
>> $N$ETWORK.DIR;1 $NAVM$AC800$QSF$ILE.;1
>> $O$PEN$F$OLDER$L$IST$DF$4M.;1 $R$AILROAD$7A$T$YCOON.DIR;1
>> $S$OFTWARE.DIR;1 $S$YSTEM$7A$F$OLDER.DIR;1 $S$YSTEM.DIR;1
>> $T$HE$V$OLUME$S$ETTINGS$F$OLDER.DIR;1 $U$SERS.DIR;1 $V$OLUMES.DIR;1
>> .$DS_S$TORE;1 .HIDDEN;1 .HOTFILES$5NBTREE;1
>> .SYM$S$CHED$S$CAN$L$OCKXZ;1 AUTOMOUNT.DIR;1 BIN.DIR;1
>> CORES.DIR;1 DEV.DIR;1 DISK2.DIR;1 ETC.;1
>> MACH.;1 MACH.SYM;1 MACH_KERNEL.;1
PRIVATE.DIR;1
>> SBIN.DIR;1 TMP.;1 USR.DIR;1 VAR.;1
>>
>> Total of 41 files.
>
> (weird file names is due to VAX-VMS not understanding modern filename).
>
>> TCPIP> show mount/full
>> _DNFS1:[000000] mounted
>> BRAKES.vaxination.ca:/
>> Transport TCPIP-UDP Writing Enabled
>> Read/write size 8192/8192 Write conversion Enabled
>> RPC timeout 0 00:00:01.00 ADF usage USE,UPDATE,CREATE
>> RPC retry limit 4 Fileids Unique
>> Attribute time 0 00:00:15.00 Server type UNIX
>> Directory time 0 00:00:30.00 Advisory Locking Disabled
>> Cache Validation MODIFY TIME Default user [DECNET]
>> Superuser No Default UID,GID 501,501
>
>
> OK, I have done a bit of testing. It appears that SYSTEM on VMS doesn't
> really map to 0,0 on the remote system even if I have a proxy setup for
> it. But of I git the /GID=501/UID=501, then SYSTEM has teh same access
> as 501,501 on the remote system.
>
>
> Set the /UID /GID in the mount command to the combo that is mapped to
> the owner of the directory on the remote system. If that doesn't work,
> then set all files in that directory (and the directory itself) to be
> world readable and test again.
>
> (These tests were done on the vax, not on the more recent TCOPIP 5.6 on
> alpha)
Hi JF

It is Mr Gremlin (are there any other types??)

I have trawled through that manual for months and, as lovely a document
as it is, it is no help.....

I have tried to go back to first principles - removed all mapping from
Windows, and all proxies etc from VMS. Linux client still connect
anonymously, so VMS should. Well, no....

Using no VMS proxy and making a mount command has Wireshark showing that
the value for UID/GID passed to Windows by VMS is....UID: 4294967294,
which is hex FEFFFFFF - this is clearly not -2!!! When I mount
explicitly passing /UID=-2,/GID=-2 or /UID="-2"/GID="-2" I get the same
result.

Now, I am thinking, that the UID/GID is being passed in a way that is OK
for positive integers, but is rooted (Australian for not performing to
specifications) for negative numbers, such as the default for anonymous
which works for every Linux client.

From Wireshark, I also know that whatever positive integer value I pass
using /UID/GID is passed to windows, so in Windows on the NFS share, I
set the anonymous value to be 100 rather than -2. I can mount from VMS
using this value in the /UID/GID flags.

Wireshark shows that the GETATTR call when trying to read the directory
returns that the file is a directory, mode is 040775 which means owner
and group have full permissions and the rest of the world has
read/execute. I am anonymous and allowed root access so I should be OK
- not.

If someone is interested and provides an email address, I can email the
complete Wireshark dump for perusal....

[JF Mezei]

Gremlin wrote:
>
> Using no VMS proxy and making a mount command has Wireshark showing that
> the value for UID/GID passed to Windows by VMS is....UID: 4294967294,
> which is hex FEFFFFFF - this is clearly not -2!!!

Humm...

-2 is FFFFFFFE (two's complement of 00000002 ) (flip bits,then add 1)


FEFFFFFF is reverse byte order.

When you access from Linux, what is the value your tracing software sees
for the UID ?


> Now, I am thinking, that the UID/GID is being passed in a way that is OK
> for positive integers, but is rooted (Australian for not performing to
> specifications) for negative numbers,

doesn't the australian verb "root" refer to a cardiovascular exercise
which may result in pregnancy if not careful ? Be careful, your VMS box
might make your windows machine pregnant :-) :-) ;-)


> From Wireshark, I also know that whatever positive integer value I pass
> using /UID/GID is passed to windows, so in Windows on the NFS share, I
> set the anonymous value to be 100 rather than -2. I can mount from VMS
> using this value in the /UID/GID flags.

OK, if you do that, does this then grant you proper access ?


If it is the case, you could trick VMS into sending a "proper" -2 by
giving it a /GID/UID value that "fakes" it.

$ a = %xFeFFFFFF
$ show symbol a
A = -16777217

This might get transmitted in the proper order and be seen by windows as
-2 ?

[Gremlin]

JF Mezei wrote:
> Gremlin wrote:
>> Using no VMS proxy and making a mount command has Wireshark showing that
>> the value for UID/GID passed to Windows by VMS is....UID: 4294967294,
>> which is hex FEFFFFFF - this is clearly not -2!!!
>
> Humm...
>
> -2 is FFFFFFFE (two's complement of 00000002 ) (flip bits,then add 1)
>
>
> FEFFFFFF is reverse byte order.
>
> When you access from Linux, what is the value your tracing software sees
> for the UID ?
>
>
>> Now, I am thinking, that the UID/GID is being passed in a way that is OK
>> for positive integers, but is rooted (Australian for not performing to
>> specifications) for negative numbers,
>
> doesn't the australian verb "root" refer to a cardiovascular exercise
> which may result in pregnancy if not careful ? Be careful, your VMS box
> might make your windows machine pregnant :-) :-) ;-)
>
>
>> From Wireshark, I also know that whatever positive integer value I pass
>> using /UID/GID is passed to windows, so in Windows on the NFS share, I
>> set the anonymous value to be 100 rather than -2. I can mount from VMS
>> using this value in the /UID/GID flags.
>
> OK, if you do that, does this then grant you proper access ?
>
>
> If it is the case, you could trick VMS into sending a "proper" -2 by
> giving it a /GID/UID value that "fakes" it.
>
> $ a = %xFeFFFFFF
> $ show symbol a
> A = -16777217
>
> This might get transmitted in the proper order and be seen by windows as
> -2 ?
>
In Australia, there are many uses for words, and your alternative is
also one of the more common!!

Anyway, back to the anonymous access, I set the UID/GID value for that
in Windows to 100, then I pass that via VMS - get's around the small
issue of byte ordering as the value is now a positive integer.

Anyway......still rejects it.

I am happy to email a Wireshark dump if that helps - I am now officially
at a loss - there is just "something" on the VMS side that Windows
doesn't like, but Linux is happy with - sigh.

[JF Mezei]

Gremlin wrote:

>
> I am happy to email a Wireshark dump if that helps - I am now officially
> at a loss - there is just "something" on the VMS side that Windows
> doesn't like, but Linux is happy with - sigh.

If both the directory and the files are public-read on your windows
machine, then any user should be able to access them.

If VMS still can't access them, it would then mean that you have
problems with mapping of uid/gid and the server refuses to honour those
requests.

You need to look at various options available on the windows server
(defaults, whether the client must make its call from a privileged ports
number etc etc).

[Gremlin]

JF Mezei wrote:
> Gremlin wrote:
>
>> I am happy to email a Wireshark dump if that helps - I am now officially
>> at a loss - there is just "something" on the VMS side that Windows
>> doesn't like, but Linux is happy with - sigh.
>
> If both the directory and the files are public-read on your windows
> machine, then any user should be able to access them.
>
> If VMS still can't access them, it would then mean that you have
> problems with mapping of uid/gid and the server refuses to honour those
> requests.
>
> You need to look at various options available on the windows server
> (defaults, whether the client must make its call from a privileged ports
> number etc etc).
>
Hi JF

I suppose that it *could* be a mapping problem - except that I am no
longer using mapping!! I removed the proxy entry from VMS, I removed
all users and groups from the Windows side. I rebooted the Windows
server. I re-shared the NFS area allowing everyine to access everything
(in Windows, Everyone full control on all files/folders/sub-folders
under the NFS share folder).

With absolutely no mapping whatsoever, Linux connects as anonymous - now
all I want is for VMS to do the same. No mappings, no problems with
mappings one would think!

[Gorazd Kikelj]

"Gremlin" <***@all.com> wrote in message
news:***@corp.supernews.com...

> Anyway, back to the anonymous access, I set the UID/GID value for that in
> Windows to 100, then I pass that via VMS - get's around the small issue of
> byte ordering as the value is now a positive integer.
>
> Anyway......still rejects it.
>
> I am happy to email a Wireshark dump if that helps - I am now officially
> at a loss - there is just "something" on the VMS side that Windows doesn't
> like, but Linux is happy with - sigh.

Hi,

it is a windows mapping issue. Did you try access from linux with specific
username
mappings or only anonymous?

Username mappings is VERY fragile. Have a lot of fun with it and have no
tool to
realy check it.

Did you also put your VMS server to NFS server allowed host list?
And also in NFS share, did you allow VMS server to access the share?

For NFS registry settings here is a link:
<http://groups.google.com/group/microsoft.public.servicesforunix.general/browse_thread/thread/8670ae9af6936ae0/20995e3dc953d1b7?q=sharing+violation&rnum=1#20995e3dc953d1b7>


Sometimes it help rebooting windows :-)

Best, Gorazd

[Gremlin]

Gorazd Kikelj wrote:
> "Gremlin" <***@all.com> wrote in message
> news:***@corp.supernews.com...
>
>> Anyway, back to the anonymous access, I set the UID/GID value for that in
>> Windows to 100, then I pass that via VMS - get's around the small issue of
>> byte ordering as the value is now a positive integer.
>>
>> Anyway......still rejects it.
>>
>> I am happy to email a Wireshark dump if that helps - I am now officially
>> at a loss - there is just "something" on the VMS side that Windows doesn't
>> like, but Linux is happy with - sigh.
>
> Hi,
>
> it is a windows mapping issue. Did you try access from linux with specific
> username
> mappings or only anonymous?
>
> Username mappings is VERY fragile. Have a lot of fun with it and have no
> tool to
> realy check it.
>
> Did you also put your VMS server to NFS server allowed host list?
> And also in NFS share, did you allow VMS server to access the share?
>
> For NFS registry settings here is a link:
> <http://groups.google.com/group/microsoft.public.servicesforunix.general/browse_thread/thread/8670ae9af6936ae0/20995e3dc953d1b7?q=sharing+violation&rnum=1#20995e3dc953d1b7>
>
>
> Sometimes it help rebooting windows :-)
>
> Best, Gorazd
>
>
Hi

I replied with this to JF...

"I suppose that it *could* be a mapping problem - except that I am no
longer using mapping!! I removed the proxy entry from VMS, I removed
all users and groups from the Windows side. I rebooted the Windows
server. I re-shared the NFS area allowing everyine to access everything
(in Windows, Everyone full control on all files/folders/sub-folders
under the NFS share folder).

With absolutely no mapping whatsoever, Linux connects as anonymous - now
all I want is for VMS to do the same. No mappings, no problems with
mappings one would think!"

The .maphosts file has a single entry which is + - this means all
machines can access the server. Again, I can mount/unmount successfully
so access to the server is OK.

With *no* mappings at all (all entries of any variety deleted), all
Linux clients connect as anonymous (UID=100/GID=100) - VMS won't. If it
was mappings, then without any mappings at all, shouldn't everyhting
fail, or everything work? And if only one doesn't work, wouldn't that
be the problem?

Also, with all the mapping entries removed, Windows no longer logs
"mapping failure" messages when VMS tries to read and fails!

[Gremlin]

JF Mezei wrote:
> Gremlin wrote:
>
>> I am using the same username to mount/access the share and have done a
>> set proc/priv=all just to be sure.....it has outgoing proxies set...
>
>
> The VMS privileges are absolutely , totally meaningless to grant you
> access to the remote server. The remote server decides what you can and
> cannot access and it has no idea nor concept of what your VMS privileges
> are.
>
> It was relatively easy for me to get the VMS client to mount the MAC
> disk. But the other way around took a lot more trial and error, probably
> because automount runs as root and the actual accesses are done by my
> username. The fix ended up being with the proxies on VMS.
>
> I would suggest you take a serious look at the windows setup to ensure
> you have the right flags setup and that the exported directory belongs
> to the user who will be accessing it.
>
> aka: make sure that the VMS username is mapped to a UID/GID combination
> which, on windows is mapped to a windows username that has read/write
> access to the directory you are exporting.
>
>
>
>
But wait, there's more!!!!

Pursuing how to make VMS connect anonymously, like all the Linux
clients.....I removed the proxy entry - that should make it appear
anonymous!

$ tcpip rem proxy VMSusername

VMS User_name Type User_ID Group_ID Host_name

VMSusername OND 1001 100 x.y.z
Remove? [N]:y

$ tcpip mou dnfs1: /host="x.y.z"/path="/nfsdata"/struc=5
%TCPIP$DNFSMOUNT-S-MOUNTED, /nfsdata mounted on _DNFS1:[000000]
$ dir dnfs1:[000000]
%DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-F-TIMEOUT, device timeout
$ tcpip dism/all
%TCPIP$DNFSDISMOUNT-S-DISMOUNTED, _DNFS1:[000000] dismounted


OK, back to our old friend the timeout. Repeated testing - no proxy
(anonymous access?) and it mounts OK just like before, but reading gets
a device timeout, *NOT* a mapping error.

Put the proxy in (see entry above) and it gets a mapping error - take it
out and VMS becomes confused about the device although Windows showmount
-a localhost shows it is mounted.

I still think something is broken on the VMS side - if the proxy is
removed then access should be anonymous - the device error/timeout
should't be there if anonymous mapping failed, there should be a mapping
error on the Windows side and an RMS-E-PRV on the VMS side.

Any thoughts?

[Michael D. Ober]

"Gremlin" <***@all.com> wrote in message
news:***@corp.supernews.com...
> JF Mezei wrote:
>> Gremlin wrote:
>>
>>> I am using the same username to mount/access the share and have done a
>>> set proc/priv=all just to be sure.....it has outgoing proxies set...
>>
>>
>> The VMS privileges are absolutely , totally meaningless to grant you
>> access to the remote server. The remote server decides what you can and
>> cannot access and it has no idea nor concept of what your VMS privileges
>> are.
>>
>> It was relatively easy for me to get the VMS client to mount the MAC
>> disk. But the other way around took a lot more trial and error, probably
>> because automount runs as root and the actual accesses are done by my
>> username. The fix ended up being with the proxies on VMS.
>>
>> I would suggest you take a serious look at the windows setup to ensure
>> you have the right flags setup and that the exported directory belongs
>> to the user who will be accessing it.
>>
>> aka: make sure that the VMS username is mapped to a UID/GID combination
>> which, on windows is mapped to a windows username that has read/write
>> access to the directory you are exporting.
>>
>>
>>
>>
> But wait, there's more!!!!
>
> Pursuing how to make VMS connect anonymously, like all the Linux
> clients.....I removed the proxy entry - that should make it appear
> anonymous!
>
> $ tcpip rem proxy VMSusername
>
> VMS User_name Type User_ID Group_ID Host_name
>
> VMSusername OND 1001 100 x.y.z
> Remove? [N]:y
>
> $ tcpip mou dnfs1: /host="x.y.z"/path="/nfsdata"/struc=5
> %TCPIP$DNFSMOUNT-S-MOUNTED, /nfsdata mounted on _DNFS1:[000000]
> $ dir dnfs1:[000000]
> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
> -RMS-E-DNF, directory not found
> -SYSTEM-F-TIMEOUT, device timeout
> $ tcpip dism/all
> %TCPIP$DNFSDISMOUNT-S-DISMOUNTED, _DNFS1:[000000] dismounted
>
>
> OK, back to our old friend the timeout. Repeated testing - no proxy
> (anonymous access?) and it mounts OK just like before, but reading gets a
> device timeout, *NOT* a mapping error.
>
> Put the proxy in (see entry above) and it gets a mapping error - take it
> out and VMS becomes confused about the device although Windows
> showmount -a localhost shows it is mounted.
>
> I still think something is broken on the VMS side - if the proxy is
> removed then access should be anonymous - the device error/timeout
> should't be there if anonymous mapping failed, there should be a mapping
> error on the Windows side and an RMS-E-PRV on the VMS side.
>
> Any thoughts?
>


When I was attempting the same thing last year, I finally determined that
the issue is that the VMS client appears to be a V3 client to Windows
Services for Unix (SFU), but that it is actually only a V2 client. This
apparently causes Windows SFU to send protocol information back to VMS that
the VMS client can't handle. The real solution is for HP to bring their VMS
NFS Client up to at least V3 standards.

What's interesting is that neither HP nor MS are willing to resolve this
issue - I called both. I gave up and called Hummingbird and had it working
inside a day.

Mike.

[Gremlin]

Michael D. Ober wrote:
> "Gremlin" <***@all.com> wrote in message
> news:***@corp.supernews.com...
>> JF Mezei wrote:
>>> Gremlin wrote:
>>>
>>>> I am using the same username to mount/access the share and have done
>>>> a set proc/priv=all just to be sure.....it has outgoing proxies set...
>>>
>>>
>>> The VMS privileges are absolutely , totally meaningless to grant you
>>> access to the remote server. The remote server decides what you can and
>>> cannot access and it has no idea nor concept of what your VMS privileges
>>> are.
>>>
>>> It was relatively easy for me to get the VMS client to mount the MAC
>>> disk. But the other way around took a lot more trial and error, probably
>>> because automount runs as root and the actual accesses are done by my
>>> username. The fix ended up being with the proxies on VMS.
>>>
>>> I would suggest you take a serious look at the windows setup to ensure
>>> you have the right flags setup and that the exported directory belongs
>>> to the user who will be accessing it.
>>>
>>> aka: make sure that the VMS username is mapped to a UID/GID combination
>>> which, on windows is mapped to a windows username that has read/write
>>> access to the directory you are exporting.
>>>
>>>
>>>
>>>
>> But wait, there's more!!!!
>>
>> Pursuing how to make VMS connect anonymously, like all the Linux
>> clients.....I removed the proxy entry - that should make it appear
>> anonymous!
>>
>> $ tcpip rem proxy VMSusername
>>
>> VMS User_name Type User_ID Group_ID Host_name
>>
>> VMSusername OND 1001 100 x.y.z
>> Remove? [N]:y
>>
>> $ tcpip mou dnfs1: /host="x.y.z"/path="/nfsdata"/struc=5
>> %TCPIP$DNFSMOUNT-S-MOUNTED, /nfsdata mounted on _DNFS1:[000000]
>> $ dir dnfs1:[000000]
>> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
>> -RMS-E-DNF, directory not found
>> -SYSTEM-F-TIMEOUT, device timeout
>> $ tcpip dism/all
>> %TCPIP$DNFSDISMOUNT-S-DISMOUNTED, _DNFS1:[000000] dismounted
>>
>>
>> OK, back to our old friend the timeout. Repeated testing - no proxy
>> (anonymous access?) and it mounts OK just like before, but reading
>> gets a device timeout, *NOT* a mapping error.
>>
>> Put the proxy in (see entry above) and it gets a mapping error - take
>> it out and VMS becomes confused about the device although Windows
>> showmount -a localhost shows it is mounted.
>>
>> I still think something is broken on the VMS side - if the proxy is
>> removed then access should be anonymous - the device error/timeout
>> should't be there if anonymous mapping failed, there should be a
>> mapping error on the Windows side and an RMS-E-PRV on the VMS side.
>>
>> Any thoughts?
>>
>
>
> When I was attempting the same thing last year, I finally determined
> that the issue is that the VMS client appears to be a V3 client to
> Windows Services for Unix (SFU), but that it is actually only a V2
> client. This apparently causes Windows SFU to send protocol information
> back to VMS that the VMS client can't handle. The real solution is for
> HP to bring their VMS NFS Client up to at least V3 standards.
>
> What's interesting is that neither HP nor MS are willing to resolve this
> issue - I called both. I gave up and called Hummingbird and had it
> working inside a day.
>
> Mike.
>
>
Hi

It is very sad - I am sure there is something broken, therefore a
solution - but JF has eloquently expressed his and other's frustration
at the HP "support", so I won't go there.

I switched on NFSv3 support within Windows, no difference.

BUT

If I put the proxy back, do the mount as described and use the /NOADF
switch, I get the RMS-E-PRV error almost immediately. If I exclude the
switch, it waits then times out.

[Bob Koehler]

In article <***@corp.supernews.com>, "Michael D. Ober" <***@.alum.mit.edu.nospam.> writes:
>
> When I was attempting the same thing last year, I finally determined that
> the issue is that the VMS client appears to be a V3 client to Windows
> Services for Unix (SFU), but that it is actually only a V2 client.

This is the same as what I ran across when using a Mac client with
Multinet's NFS server. I had to force the Mac client to use NFS V2.

[Mark Berryman]

Bob Koehler wrote:
> In article <***@corp.supernews.com>, "Michael D. Ober" <***@.alum.mit.edu.nospam.> writes:
>> When I was attempting the same thing last year, I finally determined that
>> the issue is that the VMS client appears to be a V3 client to Windows
>> Services for Unix (SFU), but that it is actually only a V2 client.
>
> This is the same as what I ran across when using a Mac client with
> Multinet's NFS server. I had to force the Mac client to use NFS V2.

Which versions were you using? I am using a Mac client (started at
10.4.9, now running 10.5.1) to talk to a Multinet V5.2 NFS server with
no problems at all, include the use of groups and ACLs.

Mark Berryman

[Bob Koehler]

In article <***@mvb.saic.com>, Mark Berryman <***@theberrymans.com> writes:
> Bob Koehler wrote:
>
> Which versions were you using? I am using a Mac client (started at
> 10.4.9, now running 10.5.1) to talk to a Multinet V5.2 NFS server with
> no problems at all, include the use of groups and ACLs.

Both my client and server were older than that. I haven't had the
need for quite some time.

[Gorazd Kikelj]

"Gremlin" <***@all.com> wrote in message
news:***@corp.supernews.com...
> $ tcpip mou dnfs1: /host="x.y.z"/path="/nfsdata"/struc=5
> %TCPIP$DNFSMOUNT-S-MOUNTED, /nfsdata mounted on _DNFS1:[000000]

You are missing /NOADF in mount command hence timeout in next IO access.


> $ dir dnfs1:[000000]
> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
> -RMS-E-DNF, directory not found
> -SYSTEM-F-TIMEOUT, device timeout
> $ tcpip dism/all
> %TCPIP$DNFSDISMOUNT-S-DISMOUNTED, _DNFS1:[000000] dismounted


As I propose, please try to gather some trace data with wireshark or tcpdump
and look,
what UID/GID is in the packets.

Also you can try with TCPIP$EXAMPLES:TCPIP$PROXY_RELOAD.COM to reload
proxies on VMS side.

Best, Gorazd

[Gremlin]

Gorazd Kikelj wrote:
> "Gremlin" <***@all.com> wrote in message
> news:***@corp.supernews.com...
>> $ tcpip mou dnfs1: /host="x.y.z"/path="/nfsdata"/struc=5
>> %TCPIP$DNFSMOUNT-S-MOUNTED, /nfsdata mounted on _DNFS1:[000000]
>
> You are missing /NOADF in mount command hence timeout in next IO access.
>
>
>> $ dir dnfs1:[000000]
>> %DIRECT-E-OPENIN, error opening DNFS1:[000000]*.*;* as input
>> -RMS-E-DNF, directory not found
>> -SYSTEM-F-TIMEOUT, device timeout
>> $ tcpip dism/all
>> %TCPIP$DNFSDISMOUNT-S-DISMOUNTED, _DNFS1:[000000] dismounted
>
>
> As I propose, please try to gather some trace data with wireshark or tcpdump
> and look,
> what UID/GID is in the packets.
>
> Also you can try with TCPIP$EXAMPLES:TCPIP$PROXY_RELOAD.COM to reload
> proxies on VMS side.
>
> Best, Gorazd
>
>
OK, lots of stuff.... 192.168.100.205 is VMS client, 192.168.100.6 is
NFS server

So, after mounting OK (with UID 1001 and GID 100) and with /NOADF flag,
wireshark shows this....

258 8.704398 192.168.100.205 192.168.100.6 NFS V2 READDIR Call,
FH:0x108ffdeb (showing UID 1001, GID 100)

263 8.722681 192.168.100.6 192.168.100.205 NFS V2 READDIR Reply (Call In
258) Error:NFSERR_ACCES (Ooops!!)

From the RFC: NFSERR_ACCES
Permission denied. The caller does not have the correct
permission to perform the requested operation.

So, VMS seems to pass the correct UID/GID - Windows rejects it....

Here is the hex of the read request (specifically the credentials)...
0000000100000020479ec7970000000567616d6d61000000000003e9000000640000000100000064
Here is the hex of the read request (specifically the NFS READDIR
request)...
1d000000000001001d0000000000010044c527fd520300000245fb3d040c31a40000000000002000

Here is the hex of the reject component...
3f2adb390000000100000000000000000000000000000000

So, Windows is set up to allow anonymous access which is also set (by
default) to a UID/GID of -2,-2 - when I issue the mount command with
either /UID="-2"/GID="-2" or /UID=-2/GID=-2, windows returns:

147 7.459808 192.168.100.6 192.168.100.205 MOUNT V1 UMNT Reply (Call In
146)[Malformed Packet]

So, no forcing VMS to use the anonymous UID/GID.

What seems to be left is that VMS is passing the correct UID/GID
information, but the windows mapping (which is just my windows username
to my VMS username with a UID of 1001 and my windows group to my VMS
froup with a GID of 100 is not correctly interpreted. Something else is
missing.....certainly VMS anonymous access won't happen!

[JF Mezei]

Gremlin wrote:

> What is your mount command, as I can't see a path in the listing above?


Had to use Google to find my previous post (and I'll need it for the
next power failure when half the stuff that appears to work now will
probably be broken :-)


$TCPIP MOUNT DNFS1:/HOST=BRAKES/PATH="/"-
/UID=501/GID=501/SERVER=UNIX/STRUCT=5


On the mac:

"name" = ( "exports" );
CHILDREN = (
{
"name" = ( "/" );
"clients" = ( "10.0.0.7", "10.0.0.10", "10.0.0.11" );
"opts" = ( "alldirs" );
}



> 0,0 doesn't exist - so I deleted the mappings in Windows and started by
> creating a group mapping of 4 for system and 100 for users. I then
> mapped users with 1 for domain admins and also 1 for my windows username.


My philosophy on this is to open the gates and get a mount to work, and
then narrow the security and other parameters down. Once you have a
repeatable working mount, you can work with the security and user
mappings etc.

> So, when I issue the mount command I have now tried it with /UID=1/GID=4
> (VMS system account UIC) and /UID=1/GID=100 (my vms UIC).

There is absolutely no , NONE, NADA corrolation between the VMS UIC and
the GID/UID.

You need to create a proxy entry in the TCPIP database that maps a VMS
*USERNAME* with a Unix UID/GID.

TCPIP> ADD PROXY vmsusername/UID=yy/GID=xx/NFS=(INCOMING,OUTGOING)

xx and yy are the UID/GD of the remote system.

So when user "vmsusername" does a "DIR DNFS1:[000000]" , the VMS system
will lookup the proxy database and then emit a NFS request coming from
user UID=yy GID=xx

In the TCPIP Services Management manual, there is a fairly big section
for NFS, as well as a section on NFS on Windows.

[Gremlin]

JF Mezei wrote:
> Gremlin wrote:
>
>> What is your mount command, as I can't see a path in the listing above?
>
>
> Had to use Google to find my previous post (and I'll need it for the
> next power failure when half the stuff that appears to work now will
> probably be broken :-)
>
>
> $TCPIP MOUNT DNFS1:/HOST=BRAKES/PATH="/"-
> /UID=501/GID=501/SERVER=UNIX/STRUCT=5
>
>
> On the mac:
>
> "name" = ( "exports" );
> CHILDREN = (
> {
> "name" = ( "/" );
> "clients" = ( "10.0.0.7", "10.0.0.10", "10.0.0.11" );
> "opts" = ( "alldirs" );
> }
>
>
>
>> 0,0 doesn't exist - so I deleted the mappings in Windows and started by
>> creating a group mapping of 4 for system and 100 for users. I then
>> mapped users with 1 for domain admins and also 1 for my windows username.
>
>
> My philosophy on this is to open the gates and get a mount to work, and
> then narrow the security and other parameters down. Once you have a
> repeatable working mount, you can work with the security and user
> mappings etc.
>
>> So, when I issue the mount command I have now tried it with /UID=1/GID=4
>> (VMS system account UIC) and /UID=1/GID=100 (my vms UIC).
>
> There is absolutely no , NONE, NADA corrolation between the VMS UIC and
> the GID/UID.
>
> You need to create a proxy entry in the TCPIP database that maps a VMS
> *USERNAME* with a Unix UID/GID.
>
> TCPIP> ADD PROXY vmsusername/UID=yy/GID=xx/NFS=(INCOMING,OUTGOING)
>
> xx and yy are the UID/GD of the remote system.
>
> So when user "vmsusername" does a "DIR DNFS1:[000000]" , the VMS system
> will lookup the proxy database and then emit a NFS request coming from
> user UID=yy GID=xx
>
> In the TCPIP Services Management manual, there is a fairly big section
> for NFS, as well as a section on NFS on Windows.
>
Hi JF

Using your path="/" gives me....

tcpip mou dnfs1: data1 /host="x.y.z" /system /structure=5
/noadf /path="/"
%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000]
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

Using path="/d/nfsdata" (physical location on the Windows server) or
path="nfsdata" (exported nfs share name) works fine.....