NFS client accessing Windows acting badly (long) - VMS

This is a discussion on NFS client accessing Windows acting badly (long) - VMS ; Hi Experts!! Using OpenVMS 8.2 with HP TCP/IP showing: [SYSMGR] > TCPIP SHO VER HP TCP/IP Services for OpenVMS Alpha Version V5.5 on a DEC 3000 Model 400 running OpenVMS V8.2 I have created an NFS share on a Windows2003 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: NFS client accessing Windows acting badly (long)

  1. NFS client accessing Windows acting badly (long)

    Hi Experts!!


    Using OpenVMS 8.2 with HP TCP/IP showing:
    [SYSMGR] > TCPIP SHO VER

    HP TCP/IP Services for OpenVMS Alpha Version V5.5
    on a DEC 3000 Model 400 running OpenVMS V8.2

    I have created an NFS share on a Windows2003 server using MS Windows
    Services for UNIX V3.5 (latest I can find) and it is configured and
    running happily. All my accesses are logged in Windows and none are
    creating any type of error. The Windows NFS share name is NFSDATA.

    From VMS, I can mount and unmount the NFS share successfully and the
    Windows log file shows the activity as being successful. The command I
    use from VMS is:

    > tcpip mount dnfs1:[data] /system/host=dl380/path=nfsdata/struc=5


    and I get

    %TCPIP$DNFSMOUNT-S-MOUNTED, NFSDATA mounted on _DNFS1:[DATA]

    When I check the created device (DNSF1, I see:

    [SYSMGR] > SHO DEV DNFS1 /FU

    Disk DNFS1:, device type Foreign disk type 7, is online, mounted,
    file-oriented
    device, shareable, accessed via DFS or NFS.

    Error count 0 Operations completed
    9
    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 426766656 Sectors per track
    0
    Total cylinders 0 Tracks per cylinder
    0

    Volume label "DL380$NFSDAT" 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.

    When I access the "root" that I created, I get:

    > DIR DNFS1:[000000]


    Directory DNFS1:[000000]

    DATA.DIR;1

    Total of 1 file.

    Now, the problem is that if I try to access any files in any of the
    directories in/under that share, I get:

    > DIR DNFS1:[FILES]

    %DIRECT-E-OPENIN, error opening DNFS1:[FILES]*.*;* as input
    -RMS-E-DNF, directory not found
    -SYSTEM-F-TIMEOUT, device timeout

    and

    > DIR DNFS1:[DATA.FILES]

    %DIRECT-E-OPENIN, error opening DNFS1:[DATA.FILES]*.*;* as input
    -RMS-E-DNF, directory not found
    -SYSTEM-F-TIMEOUT, device timeout

    I get no error showing in the Windows log files. I have tried
    increasing the timeout on the mount, but it just takes longer to return
    the error!!

    I have also tried the following mount commands (notice the alternate or
    no use of leading / for the path):
    > tcpip mount dnfs1:[data] /system/host="dl380"/path="nfsdata"/struc=5
    > tcpip mount dnfs1:[data] /system/host="dl380"/path="/nfsdata"/struc=5
    > tcpip mount dnfs1:[data] /system/host="dl380"/path="\nfsdata"/struc=5


    also trying

    > tcpip mount dnfs1: /system/host=dl380/path=nfsdata/struc=5
    > tcpip mount dnfs1:[000000] /system/host=dl380/path=nfsdata/struc=5


    and various combinations with/without the quotes.

    All result in successful mounts but no ability to access any
    directories/files. No error on Windows and only the timeout in VMS.

    I have tried this from two different OpenVMS servers, running the same
    version of VMS and TCP/IP and get the same results. I don't have any
    other OS handy to test NFS connectivity.

    Any thoughts would be appreciated.

  2. Re: NFS client accessing Windows acting badly (long)

    In article <13h3p7779620690@corp.supernews.com>,
    Gremlin wrote:

    > I have also tried the following mount commands (notice the alternate or
    > no use of leading / for the path):
    > > tcpip mount dnfs1:[data] /system/host="dl380"/path="nfsdata"/struc=5
    > > tcpip mount dnfs1:[data] /system/host="dl380"/path="/nfsdata"/struc=5
    > > tcpip mount dnfs1:[data] /system/host="dl380"/path="\nfsdata"/struc=5

    >
    > also trying
    >
    > > tcpip mount dnfs1: /system/host=dl380/path=nfsdata/struc=5
    > > tcpip mount dnfs1:[000000] /system/host=dl380/path=nfsdata/struc=5

    >
    > and various combinations with/without the quotes.


    No Windoes box here, but here's the flavour that works to access the NFS
    server on my Mac:

    $ tcpip mount dnfs2:[paul] /host="mac" -
    /path="/Volumes/VMS_Backup"/system/structure=5

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  3. Re: NFS client accessing Windows acting badly (long)

    Gremlin wrote:
    > Hi Experts!!
    >
    >
    > Using OpenVMS 8.2 with HP TCP/IP showing:
    > [SYSMGR] > TCPIP SHO VER
    >
    > HP TCP/IP Services for OpenVMS Alpha Version V5.5
    > on a DEC 3000 Model 400 running OpenVMS V8.2
    >
    > I have created an NFS share on a Windows2003 server using MS Windows
    > Services for UNIX V3.5 (latest I can find) and it is configured and
    > running happily. All my accesses are logged in Windows and none are
    > creating any type of error. The Windows NFS share name is NFSDATA.


    Be aware that Windows Services for Unix is no longer supported for
    Vista. The replacement product is only available in the Ultimate and
    Enterprise editions, and at this time does not include an NFS server.
    It is unknown if that will change.

    > From VMS, I can mount and unmount the NFS share successfully and the
    > Windows log file shows the activity as being successful. The command I
    > use from VMS is:
    >



    > Now, the problem is that if I try to access any files in any of the
    > directories in/under that share, I get:
    >
    > > DIR DNFS1:[FILES]

    > %DIRECT-E-OPENIN, error opening DNFS1:[FILES]*.*;* as input
    > -RMS-E-DNF, directory not found
    > -SYSTEM-F-TIMEOUT, device timeout


    I do not know about the timeout, however you need to make sure that you
    are mapping the VMS UICs to the Windows GUIDs properly, so that Windows
    uses the proper account permissions to access the file.

    I was going to look into how to do this, but a hardware failure forced
    me to move to Vista, and the home editions of Vista do not allow this.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  4. Re: NFS client accessing Windows acting badly (long)

    Hi Paul

    That is one of the combinations that I tried and, although it maps, it
    won't allow me to "see" any of the folders/files.....sigh
    P. Sture wrote:
    > In article <13h3p7779620690@corp.supernews.com>,
    > Gremlin wrote:
    >
    >> I have also tried the following mount commands (notice the alternate or
    >> no use of leading / for the path):
    >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="nfsdata"/struc=5
    >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="/nfsdata"/struc=5
    >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="\nfsdata"/struc=5

    >>
    >> also trying
    >>
    >> > tcpip mount dnfs1: /system/host=dl380/path=nfsdata/struc=5
    >> > tcpip mount dnfs1:[000000] /system/host=dl380/path=nfsdata/struc=5

    >>
    >> and various combinations with/without the quotes.

    >
    > No Windoes box here, but here's the flavour that works to access the NFS
    > server on my Mac:
    >
    > $ tcpip mount dnfs2:[paul] /host="mac" -
    > /path="/Volumes/VMS_Backup"/system/structure=5
    >


  5. Re: NFS client accessing Windows acting badly (long)

    Hi John

    I am using the services on a Windows2003R2 server and they seem to work
    OK. I have also (intentionally) mis-mapped the permissions so that I
    could see the error generated in a log file on Windows. When they are
    mapped OK (VMS username to Windows Administrator) - the error message
    goes away.

    So, on the VMS side the username is SYSTEM and that maps to the Windows
    Domain Administrator account, I can't do much better than that!

    John E. Malmberg wrote:
    > Gremlin wrote:
    >> Hi Experts!!
    >>
    >>
    >> Using OpenVMS 8.2 with HP TCP/IP showing:
    >> [SYSMGR] > TCPIP SHO VER
    >>
    >> HP TCP/IP Services for OpenVMS Alpha Version V5.5
    >> on a DEC 3000 Model 400 running OpenVMS V8.2
    >>
    >> I have created an NFS share on a Windows2003 server using MS Windows
    >> Services for UNIX V3.5 (latest I can find) and it is configured and
    >> running happily. All my accesses are logged in Windows and none are
    >> creating any type of error. The Windows NFS share name is NFSDATA.

    >
    > Be aware that Windows Services for Unix is no longer supported for
    > Vista. The replacement product is only available in the Ultimate and
    > Enterprise editions, and at this time does not include an NFS server. It
    > is unknown if that will change.
    >
    >> From VMS, I can mount and unmount the NFS share successfully and the
    >> Windows log file shows the activity as being successful. The command
    >> I use from VMS is:
    >>

    >
    >
    >> Now, the problem is that if I try to access any files in any of the
    >> directories in/under that share, I get:
    >>
    >> > DIR DNFS1:[FILES]

    >> %DIRECT-E-OPENIN, error opening DNFS1:[FILES]*.*;* as input
    >> -RMS-E-DNF, directory not found
    >> -SYSTEM-F-TIMEOUT, device timeout

    >
    > I do not know about the timeout, however you need to make sure that you
    > are mapping the VMS UICs to the Windows GUIDs properly, so that Windows
    > uses the proper account permissions to access the file.
    >
    > I was going to look into how to do this, but a hardware failure forced
    > me to move to Vista, and the home editions of Vista do not allow this.
    >
    > -John
    > wb8tyw@qsl.network
    > Personal Opinion Only


  6. Re: NFS client accessing Windows acting badly (long)

    In article <13h57rffd9oip1e@corp.supernews.com>,
    Gremlin wrote:

    > So, on the VMS side the username is SYSTEM and that maps to the Windows
    > Domain Administrator account, I can't do much better than that!


    Hi Gremlin,

    Please don't be fooled by thinking that SYSTEM gives you extra where NFS
    is concerned - it doesn't. You need to get the UID/GID to UIC mapping
    correct.

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  7. Re: NFS client accessing Windows acting badly (long)

    In article <13h57masm788hec@corp.supernews.com>,
    Gremlin wrote:

    > Hi Paul
    >
    > That is one of the combinations that I tried and, although it maps, it
    > won't allow me to "see" any of the folders/files.....sigh


    It was worth a try. At least you now know that you aren't fighting
    incorrect syntax. With TCP/IP services, the general rule is that if you
    need to force lowercase, put it in double quotes.

    > P. Sture wrote:
    > > In article <13h3p7779620690@corp.supernews.com>,
    > > Gremlin wrote:
    > >
    > >> I have also tried the following mount commands (notice the alternate or
    > >> no use of leading / for the path):
    > >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="nfsdata"/struc=5
    > >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="/nfsdata"/struc=5
    > >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="\nfsdata"/struc=5
    > >>
    > >> also trying
    > >>
    > >> > tcpip mount dnfs1: /system/host=dl380/path=nfsdata/struc=5
    > >> > tcpip mount dnfs1:[000000] /system/host=dl380/path=nfsdata/struc=5
    > >>
    > >> and various combinations with/without the quotes.

    > >
    > > No Windoes box here, but here's the flavour that works to access the NFS
    > > server on my Mac:
    > >
    > > $ tcpip mount dnfs2:[paul] /host="mac" -
    > > /path="/Volumes/VMS_Backup"/system/structure=5
    > >


    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  8. Re: NFS client accessing Windows acting badly (long)

    Hi Paul

    The mapping may be a problem, but I have no idead if it is "real" or how
    to get around it. I have intentionally mis-mapped accounts and I am
    rewarded with a "mapping error" in the Windows log file, so I know what
    I "should" see if I have a mapping problem - I hope

    On the other hand, I am using an identical username on the Alpha and on
    the Windows server and they are mapped using the SFU tool - the proxy on
    the Alpha also uses the same names and UID/GID of 0, which is also used
    on Windows. I even have Anonymous (-2) configured and allowed - still
    not happening.

    There must be an easier way.......

    P. Sture wrote:
    > In article <13h57masm788hec@corp.supernews.com>,
    > Gremlin wrote:
    >
    >> Hi Paul
    >>
    >> That is one of the combinations that I tried and, although it maps, it
    >> won't allow me to "see" any of the folders/files.....sigh

    >
    > It was worth a try. At least you now know that you aren't fighting
    > incorrect syntax. With TCP/IP services, the general rule is that if you
    > need to force lowercase, put it in double quotes.
    >
    >> P. Sture wrote:
    >>> In article <13h3p7779620690@corp.supernews.com>,
    >>> Gremlin wrote:
    >>>
    >>>> I have also tried the following mount commands (notice the alternate or
    >>>> no use of leading / for the path):
    >>>> > tcpip mount dnfs1:[data] /system/host="dl380"/path="nfsdata"/struc=5
    >>>> > tcpip mount dnfs1:[data] /system/host="dl380"/path="/nfsdata"/struc=5
    >>>> > tcpip mount dnfs1:[data] /system/host="dl380"/path="\nfsdata"/struc=5
    >>>>
    >>>> also trying
    >>>>
    >>>> > tcpip mount dnfs1: /system/host=dl380/path=nfsdata/struc=5
    >>>> > tcpip mount dnfs1:[000000] /system/host=dl380/path=nfsdata/struc=5
    >>>>
    >>>> and various combinations with/without the quotes.
    >>> No Windoes box here, but here's the flavour that works to access the NFS
    >>> server on my Mac:
    >>>
    >>> $ tcpip mount dnfs2:[paul] /host="mac" -
    >>> /path="/Volumes/VMS_Backup"/system/structure=5
    >>>

    >


  9. Re: NFS client accessing Windows acting badly (long)

    On Oct 14, 5:44 am, Gremlin wrote:
    > Hi Experts!!
    >
    > Using OpenVMS 8.2 with HP TCP/IP showing:
    > [SYSMGR] > TCPIP SHO VER
    >
    > HP TCP/IP Services for OpenVMS Alpha Version V5.5
    > on a DEC 3000 Model 400 running OpenVMS V8.2
    >
    > I have created an NFS share on a Windows2003 server using MS Windows
    > Services for UNIX V3.5 (latest I can find) and it is configured and
    > running happily. All my accesses are logged in Windows and none are
    > creating any type of error. The Windows NFS share name is NFSDATA.
    >
    > From VMS, I can mount and unmount the NFS share successfully and the
    > Windows log file shows the activity as being successful. The command I
    > use from VMS is:
    >
    > > tcpip mount dnfs1:[data] /system/host=dl380/path=nfsdata/struc=5

    >
    > and I get
    >
    > %TCPIP$DNFSMOUNT-S-MOUNTED, NFSDATA mounted on _DNFS1:[DATA]
    >
    > When I check the created device (DNSF1, I see:
    >
    > [SYSMGR] > SHO DEV DNFS1 /FU
    >
    > Disk DNFS1:, device type Foreign disk type 7, is online, mounted,
    > file-oriented
    > device, shareable, accessed via DFS or NFS.
    >
    > Error count 0 Operations completed
    > 9
    > 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 426766656 Sectors per track
    > 0
    > Total cylinders 0 Tracks per cylinder
    > 0
    >
    > Volume label "DL380$NFSDAT" 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.
    >
    > When I access the "root" that I created, I get:
    >
    > > DIR DNFS1:[000000]

    >
    > Directory DNFS1:[000000]
    >
    > DATA.DIR;1
    >
    > Total of 1 file.
    >
    > Now, the problem is that if I try to access any files in any of the
    > directories in/under that share, I get:
    >
    > > DIR DNFS1:[FILES]

    > %DIRECT-E-OPENIN, error opening DNFS1:[FILES]*.*;* as input
    > -RMS-E-DNF, directory not found
    > -SYSTEM-F-TIMEOUT, device timeout
    >
    > and
    >
    > > DIR DNFS1:[DATA.FILES]

    > %DIRECT-E-OPENIN, error opening DNFS1:[DATA.FILES]*.*;* as input
    > -RMS-E-DNF, directory not found
    > -SYSTEM-F-TIMEOUT, device timeout
    >
    > I get no error showing in the Windows log files. I have tried
    > increasing the timeout on the mount, but it just takes longer to return
    > the error!!
    >
    > I have also tried the following mount commands (notice the alternate or
    > no use of leading / for the path):
    > > tcpip mount dnfs1:[data] /system/host="dl380"/path="nfsdata"/struc=5
    > > tcpip mount dnfs1:[data] /system/host="dl380"/path="/nfsdata"/struc=5
    > > tcpip mount dnfs1:[data] /system/host="dl380"/path="\nfsdata"/struc=5

    >
    > also trying
    >
    > > tcpip mount dnfs1: /system/host=dl380/path=nfsdata/struc=5
    > > tcpip mount dnfs1:[000000] /system/host=dl380/path=nfsdata/struc=5

    >
    > and various combinations with/without the quotes.
    >
    > All result in successful mounts but no ability to access any
    > directories/files. No error on Windows and only the timeout in VMS.
    >
    > I have tried this from two different OpenVMS servers, running the same
    > version of VMS and TCP/IP and get the same results. I don't have any
    > other OS handy to test NFS connectivity.
    >
    > Any thoughts would be appreciated.



    I don't know i fthis helps but here is an article on it which might:

    http://www.davidstclair.co.uk/networ...or-uni-15.html

  10. Re: NFS client accessing Windows acting badly (long)

    I'll keep this short and simple - According to VMS Support, it's a Windows
    problem. According to M$, they don't support the VMS NFS Client so they
    won't help you. I went with Hummingbird.

    Mike.


    wrote in message
    news:b0556769-afd0-4ec0-b90d-03400d5bfba3@y20g2000hsy.googlegroups.com...
    > On Oct 14, 5:44 am, Gremlin wrote:
    >> Hi Experts!!
    >>
    >> Using OpenVMS 8.2 with HP TCP/IP showing:
    >> [SYSMGR] > TCPIP SHO VER
    >>
    >> HP TCP/IP Services for OpenVMS Alpha Version V5.5
    >> on a DEC 3000 Model 400 running OpenVMS V8.2
    >>
    >> I have created an NFS share on a Windows2003 server using MS Windows
    >> Services for UNIX V3.5 (latest I can find) and it is configured and
    >> running happily. All my accesses are logged in Windows and none are
    >> creating any type of error. The Windows NFS share name is NFSDATA.
    >>
    >> From VMS, I can mount and unmount the NFS share successfully and the
    >> Windows log file shows the activity as being successful. The command I
    >> use from VMS is:
    >>
    >> > tcpip mount dnfs1:[data] /system/host=dl380/path=nfsdata/struc=5

    >>
    >> and I get
    >>
    >> %TCPIP$DNFSMOUNT-S-MOUNTED, NFSDATA mounted on _DNFS1:[DATA]
    >>
    >> When I check the created device (DNSF1, I see:
    >>
    >> [SYSMGR] > SHO DEV DNFS1 /FU
    >>
    >> Disk DNFS1:, device type Foreign disk type 7, is online, mounted,
    >> file-oriented
    >> device, shareable, accessed via DFS or NFS.
    >>
    >> Error count 0 Operations completed
    >> 9
    >> 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 426766656 Sectors per track
    >> 0
    >> Total cylinders 0 Tracks per cylinder
    >> 0
    >>
    >> Volume label "DL380$NFSDAT" 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.
    >>
    >> When I access the "root" that I created, I get:
    >>
    >> > DIR DNFS1:[000000]

    >>
    >> Directory DNFS1:[000000]
    >>
    >> DATA.DIR;1
    >>
    >> Total of 1 file.
    >>
    >> Now, the problem is that if I try to access any files in any of the
    >> directories in/under that share, I get:
    >>
    >> > DIR DNFS1:[FILES]

    >> %DIRECT-E-OPENIN, error opening DNFS1:[FILES]*.*;* as input
    >> -RMS-E-DNF, directory not found
    >> -SYSTEM-F-TIMEOUT, device timeout
    >>
    >> and
    >>
    >> > DIR DNFS1:[DATA.FILES]

    >> %DIRECT-E-OPENIN, error opening DNFS1:[DATA.FILES]*.*;* as input
    >> -RMS-E-DNF, directory not found
    >> -SYSTEM-F-TIMEOUT, device timeout
    >>
    >> I get no error showing in the Windows log files. I have tried
    >> increasing the timeout on the mount, but it just takes longer to return
    >> the error!!
    >>
    >> I have also tried the following mount commands (notice the alternate or
    >> no use of leading / for the path):
    >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="nfsdata"/struc=5
    >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="/nfsdata"/struc=5
    >> > tcpip mount dnfs1:[data] /system/host="dl380"/path="\nfsdata"/struc=5

    >>
    >> also trying
    >>
    >> > tcpip mount dnfs1: /system/host=dl380/path=nfsdata/struc=5
    >> > tcpip mount dnfs1:[000000] /system/host=dl380/path=nfsdata/struc=5

    >>
    >> and various combinations with/without the quotes.
    >>
    >> All result in successful mounts but no ability to access any
    >> directories/files. No error on Windows and only the timeout in VMS.
    >>
    >> I have tried this from two different OpenVMS servers, running the same
    >> version of VMS and TCP/IP and get the same results. I don't have any
    >> other OS handy to test NFS connectivity.
    >>
    >> Any thoughts would be appreciated.

    >
    >
    > I don't know i fthis helps but here is an article on it which might:
    >
    > http://www.davidstclair.co.uk/networ...or-uni-15.html
    >





  11. Re: NFS client accessing Windows acting badly (long)

    Michael D. Ober wrote:
    > I'll keep this short and simple - According to VMS Support, it's a Windows
    > problem. According to M$, they don't support the VMS NFS Client so they
    > won't help you. I went with Hummingbird.
    >
    > Mike.


    Also, the MS unix tools NFS stuff is utter and total garbage. It's worse
    than those horrible NFS clients for windows that look like they're made in
    turbo pascal.

+ Reply to Thread