Still more NFS problems - and happy birthday VMS - VMS

This is a discussion on Still more NFS problems - and happy birthday VMS - VMS ; So, happy birthday VMS - a couple of dinners were held in Adelaide and Sydney, Australia to celebrate. Very few attended, but I suppose that is a reflection of the changing times. In Sydney we had a couple of attendees ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Still more NFS problems - and happy birthday VMS

  1. Still more NFS problems - and happy birthday VMS

    So, happy birthday VMS - a couple of dinners were held in Adelaide and
    Sydney, Australia to celebrate. Very few attended, but I suppose that
    is a reflection of the changing times. In Sydney we had a couple of
    attendees with VMS experience starting in 1979....and still using it.

    So now the bad news - NFS on OpenVMS 8.2.....still going with this.

    JF, I appreciate that you can get it to talk (with priv issues) to OSX
    and I have used the same commands to a Windows2003 server, but with no luck.

    I have now installed a new, fresh Windows2003R2 server with the "new" MS
    tools for UNIX - not the "old" SFU v3.5 - all error logging is enabled.
    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

    From VMS, I can mount the NFS disk and unmount it, but I cannot do any
    file access at all. I have tried every variation of a mount command and
    all those that work show up in the Windows log as successful.

    ANY atttempt to read the disk structure in any way fails on VMS but
    doesn't leave an error on Windows - it is as if the *actual* reading
    wasn't really happening - just timing out as the VMS message says.

    So, I am certain it is something on the VMS end but given that I can
    mount/unmount perfectly well, why does any type of read, such as $dir
    dnfs1:[000000] or $dir dnfs1:[000000.fred] or $dir dnfs1:[fred] not even
    seem to leave VMS?

    Is anyone using VMS as an NFS client to a Windows environment?

  2. Re: Still more NFS problems - and happy birthday VMS

    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.

  3. Re: Still more NFS problems - and happy birthday VMS

    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.


  4. Re: Still more NFS problems - and happy birthday VMS

    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


  5. Re: Still more NFS problems - and happy birthday VMS

    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
    >


+ Reply to Thread