Gremlin wrote:
> On Windows, the UNIX (ie VMS) username SYSTEM is mapped to a domain
> administrator account, anonymous access is allowed and a NFS share is
> created. The Windows log shows no errors

"SYSTEM" doesn't really exist in NFS parlance. UID and GID values are
exchanged.

On VMS, when you issue a TCPIP MOUNT command, the GID/UID values are
either specified in the MOUNT command, or VMS looks at the proxy
database for a record with your username in it and uses UID/GID
associated with this, or of there is nothing available, it uses a
default value of -2 -2 .

On unix servers, you have options of mapping the incoming remote UID/GID
values to the local user database. You can't really do that on windows
or VMS since the UID/GID values have no meaning on their systems.

On all systems, you also have options to map incoming requests to
specific local usernames.

> From VMS, I can mount the NFS disk and unmount it, but I cannot do any
> file access at all.

It appears that just mounting doesn't do that much. (mountd deamon), but
when you then try to access files, it is a different process (nfsd)
which handles the requests.



> wasn't really happening - just timing out as the VMS message says.

Perhaps the mountd process is running, but the nfsd deamon isn't running ?

The fact that VMS is waiting for a response and timing out is an
indication that, instead of getting a bad status code from the server,
VMS isn't getting any responses. Remember that NFS is usually UDP
traffic, so there is no concept of a dropped connection. You can reboot
the server and the client can happily continue to access his files.

Hi JF

Well, in the proxy database on vms I mapped system and my username,
system to UID 0 and GID 0, my username to the same value specified in
the password file in Windows.

Then, using the MS tool on the server, I mapped the "unix" username
SYSTEM to the Windows username Domain Administrator and gave it UID 0
and GID 0. I then mapped my "unix" username to my Windows username and
gave it the same UID and GID as in the passwd file on Windows.
Anonymous access UID -2, GID -2 is allowed on the Windows NFS server as
a "catch all" in case mapping fails....

On Windows, the nfssvc service is running happily and logging
mount/unmounts, so I can only assume that it is really there - VMS also
is happy to see it. There don't appear to be any other bits on the
Windows side, expected or running.

The client is running on the VMS side (hence the mount/unmount).

On VMS, I have tried mounting using every combination of UID/GUI/path
etc - and apart from obvious errors (all logged), the mount/unmount
process works fine. The reads fail no matter what combination I have
tried on anything.....

So, just jumped onto a SuSE and Redhat client, used the linux NFS client
to map and browse - works like a charm. Therefore, Windows2003 is
serving it fine, something on VMS is broken.....stopped and restarted
the client on VMS - still won't do it.

JF Mezei wrote:
> Gremlin wrote:
>> On Windows, the UNIX (ie VMS) username SYSTEM is mapped to a domain
>> administrator account, anonymous access is allowed and a NFS share is
>> created. The Windows log shows no errors
>
> "SYSTEM" doesn't really exist in NFS parlance. UID and GID values are
> exchanged.
>
> On VMS, when you issue a TCPIP MOUNT command, the GID/UID values are
> either specified in the MOUNT command, or VMS looks at the proxy
> database for a record with your username in it and uses UID/GID
> associated with this, or of there is nothing available, it uses a
> default value of -2 -2 .
>
> On unix servers, you have options of mapping the incoming remote UID/GID
> values to the local user database. You can't really do that on windows
> or VMS since the UID/GID values have no meaning on their systems.
>
> On all systems, you also have options to map incoming requests to
> specific local usernames.
>
>> From VMS, I can mount the NFS disk and unmount it, but I cannot do
>> any file access at all.
>
> It appears that just mounting doesn't do that much. (mountd deamon), but
> when you then try to access files, it is a different process (nfsd)
> which handles the requests.
>
>
>
>> wasn't really happening - just timing out as the VMS message says.
>
> Perhaps the mountd process is running, but the nfsd deamon isn't running ?
>
> The fact that VMS is waiting for a response and timing out is an
> indication that, instead of getting a bad status code from the server,
> VMS isn't getting any responses. Remember that NFS is usually UDP
> traffic, so there is no concept of a dropped connection. You can reboot
> the server and the client can happily continue to access his files.

On 28 Oct, 07:59, Gremlin wrote:
> Hi JF
>
> Well, in the proxy database on vms I mapped system and my username,
> system to UID 0 and GID 0, my username to the same value specified in
> the password file in Windows.
>
> Then, using the MS tool on the server, I mapped the "unix" username
> SYSTEM to the Windows username Domain Administrator and gave it UID 0
> and GID 0. I then mapped my "unix" username to my Windows username and
> gave it the same UID and GID as in the passwd file on Windows.
> Anonymous access UID -2, GID -2 is allowed on the Windows NFS server as
> a "catch all" in case mapping fails....
>
> On Windows, the nfssvc service is running happily and logging
> mount/unmounts, so I can only assume that it is really there - VMS also
> is happy to see it. There don't appear to be any other bits on the
> Windows side, expected or running.
>
> The client is running on the VMS side (hence the mount/unmount).
>
> On VMS, I have tried mounting using every combination of UID/GUI/path
> etc - and apart from obvious errors (all logged), the mount/unmount
> process works fine. The reads fail no matter what combination I have
> tried on anything.....
>
> So, just jumped onto a SuSE and Redhat client, used the linux NFS client
> to map and browse - works like a charm. Therefore, Windows2003 is
> serving it fine, something on VMS is broken.....stopped and restarted
> the client on VMS - still won't do it.
>
>
>
> JF Mezei wrote:
> > Gremlin wrote:
> >> On Windows, the UNIX (ie VMS) username SYSTEM is mapped to a domain
> >> administrator account, anonymous access is allowed and a NFS share is
> >> created. The Windows log shows no errors
>
> > "SYSTEM" doesn't really exist in NFS parlance. UID and GID values are
> > exchanged.
>
> > On VMS, when you issue a TCPIP MOUNT command, the GID/UID values are
> > either specified in the MOUNT command, or VMS looks at the proxy
> > database for a record with your username in it and uses UID/GID
> > associated with this, or of there is nothing available, it uses a
> > default value of -2 -2 .
>
> > On unix servers, you have options of mapping the incoming remote UID/GID
> > values to the local user database. You can't really do that on windows
> > or VMS since the UID/GID values have no meaning on their systems.
>
> > On all systems, you also have options to map incoming requests to
> > specific local usernames.
>
> >> From VMS, I can mount the NFS disk and unmount it, but I cannot do
> >> any file access at all.
>
> > It appears that just mounting doesn't do that much. (mountd deamon), but
> > when you then try to access files, it is a different process (nfsd)
> > which handles the requests.
>
> >> wasn't really happening - just timing out as the VMS message says.
>
> > Perhaps the mountd process is running, but the nfsd deamon isn't running ?
>
> > The fact that VMS is waiting for a response and timing out is an
> > indication that, instead of getting a bad status code from the server,
> > VMS isn't getting any responses. Remember that NFS is usually UDP
> > traffic, so there is no concept of a dropped connection. You can reboot
> > the server and the client can happily continue to access his files.- Hide quoted text -
>
> - Show quoted text -

Is this a home environment or a production one?
If it's a home environment, why not try the field test of Samba
(a.k.a. CIFS) and see if that's any easier to work with?

Steve

Hi Steve

It is a hobby version - and CIFS won't really help as I want to access
Windows shares without loading port 139 etc vulnerabilities....but
thanks for the suggestion.

etmsreec@yahoo.co.uk wrote:
> On 28 Oct, 07:59, Gremlin wrote:
>> Hi JF
>>
>> Well, in the proxy database on vms I mapped system and my username,
>> system to UID 0 and GID 0, my username to the same value specified in
>> the password file in Windows.
>>
>> Then, using the MS tool on the server, I mapped the "unix" username
>> SYSTEM to the Windows username Domain Administrator and gave it UID 0
>> and GID 0. I then mapped my "unix" username to my Windows username and
>> gave it the same UID and GID as in the passwd file on Windows.
>> Anonymous access UID -2, GID -2 is allowed on the Windows NFS server as
>> a "catch all" in case mapping fails....
>>
>> On Windows, the nfssvc service is running happily and logging
>> mount/unmounts, so I can only assume that it is really there - VMS also
>> is happy to see it. There don't appear to be any other bits on the
>> Windows side, expected or running.
>>
>> The client is running on the VMS side (hence the mount/unmount).
>>
>> On VMS, I have tried mounting using every combination of UID/GUI/path
>> etc - and apart from obvious errors (all logged), the mount/unmount
>> process works fine. The reads fail no matter what combination I have
>> tried on anything.....
>>
>> So, just jumped onto a SuSE and Redhat client, used the linux NFS client
>> to map and browse - works like a charm. Therefore, Windows2003 is
>> serving it fine, something on VMS is broken.....stopped and restarted
>> the client on VMS - still won't do it.
>>
>>
>>
>> JF Mezei wrote:
>>> Gremlin wrote:
>>>> On Windows, the UNIX (ie VMS) username SYSTEM is mapped to a domain
>>>> administrator account, anonymous access is allowed and a NFS share is
>>>> created. The Windows log shows no errors
>>> "SYSTEM" doesn't really exist in NFS parlance. UID and GID values are
>>> exchanged.
>>> On VMS, when you issue a TCPIP MOUNT command, the GID/UID values are
>>> either specified in the MOUNT command, or VMS looks at the proxy
>>> database for a record with your username in it and uses UID/GID
>>> associated with this, or of there is nothing available, it uses a
>>> default value of -2 -2 .
>>> On unix servers, you have options of mapping the incoming remote UID/GID
>>> values to the local user database. You can't really do that on windows
>>> or VMS since the UID/GID values have no meaning on their systems.
>>> On all systems, you also have options to map incoming requests to
>>> specific local usernames.
>>>> From VMS, I can mount the NFS disk and unmount it, but I cannot do
>>>> any file access at all.
>>> It appears that just mounting doesn't do that much. (mountd deamon), but
>>> when you then try to access files, it is a different process (nfsd)
>>> which handles the requests.
>>>> wasn't really happening - just timing out as the VMS message says.
>>> Perhaps the mountd process is running, but the nfsd deamon isn't running ?
>>> The fact that VMS is waiting for a response and timing out is an
>>> indication that, instead of getting a bad status code from the server,
>>> VMS isn't getting any responses. Remember that NFS is usually UDP
>>> traffic, so there is no concept of a dropped connection. You can reboot
>>> the server and the client can happily continue to access his files.- Hide quoted text -
>> - Show quoted text -
>
> Is this a home environment or a production one?
> If it's a home environment, why not try the field test of Samba
> (a.k.a. CIFS) and see if that's any easier to work with?
>
> Steve
>