NFS setup with TCPIP services, what causes share to not mount? - VMS

This is a discussion on NFS setup with TCPIP services, what causes share to not mount? - VMS ; Seems like every time I have to play with NFS server on TCPIP services we run into inane problems. We're setting up a new system, replacing one that had been running TCPware (which worked perfectly but was badly out of ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: NFS setup with TCPIP services, what causes share to not mount?

  1. NFS setup with TCPIP services, what causes share to not mount?

    Seems like every time I have to play with NFS server on TCPIP services
    we run into inane problems.

    We're setting up a new system, replacing one that had been running
    TCPware (which worked perfectly but was badly out of date); this one
    has TCPIP services, VMS V8.3, TCPIP V5.6, all current ECOs because
    thats what came with the new system...

    The client is XP running the current Hummingbird client though we
    never get to the point of actually trying to use it.

    We're following the cookbook on setting up NFS shares that we used
    before:

    TCPIP> SHOW MAP (yes these are also in the permanent config)

    /ds1 DSA1:
    /ds3 DSA3:

    TCPIP> SHOW EXPORT

    File system Host Name

    /ds1/user/dave *
    /ds3/files/ups *

    TCPIP> SHOW PROXY

    VMS Username Type User_ID Group_ID Host_name

    MAINT OND 121 120 *


    The MAINT account UIC is [120,121] and is the owner of the actual
    files and directories being shared.

    Only the 'ups' share is being produced and showing up on the client.
    On NFS startup we get the following error (via OPCOM, excess verbiage
    clipped); I do not know if the NFS memory message is problematic or
    not so included it:

    Message from user TCPIP$NFS on NODE
    NFS memory (000B4000) at system virtual FFFFFFFF67456000, user virtual
    00000000003EE000
    ....
    %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file /ds1/user/
    dave
    ....
    %TCPIP-E-MAPNOSYS, file system is not mapped

    The log file TCPIP$MOUNTD_node.LOG shows the following error:

    28-Aug-2008 17:47:52 ERROR: stat: no such file or directory, Cannot
    stat /DS1/USER/DAVE

    The case of the export in this logfile matches the case of our map and
    export names, however they were set in testing.

    DSA1 and DSA3 are shadow disks mounted clusterwide on a 2 node
    cluster. They are identical in all aspects except that DSA1 is ODS5
    and DSA3 is still ODS2. Drive names and the paths to the exports have
    been verified ad nauseum. The directory DSA1:[USER.DAVE] exists, as
    does DSA3:[OE3.FILES.UPS]

    There are no logicals of the same name or form as 'ds1' and 'ds3' map
    names.

    The directory path on the ODS5 disk is all upper case. We tried
    setting the export path to upper case, and also with the /
    opt=case_sensitive, both with a lowercase '/ds1' and uppercase '/DS1',
    and any other variant we could think of. We also set protections on
    that directory to W:RWE temporarily just in case.

    We've cleaned the config and rebuilt from scratch twice. Other than
    having two exports instead of one this is identical to a location
    where we currently have TCPIP Services V5.4 on an older VMS version
    running, with Hummingbird client, with no problem for years.

    Any thoughts? We just gave up getting Samba to work on these systems;
    the customer's third party programs (no source) were unable to
    properly handle files shared via Samba (but had worked with the older
    TCPware NFS shares for years).

    Thanks

    Rich


  2. Re: NFS setup with TCPIP services, what causes share to not mount?

    Rich Jordan wrote:

    > /ds1/user/dave *
    > /ds3/files/ups *


    > Any thoughts?


    Start by enabling read-write for world on ds1:[000000]000000.dir as well
    as ds1:[000000]user.dir

    See if it makes a difference. (then set it back to what it was before).

    Also, make sure that the protection of the mount point file on the
    client system is setup properly.

    If I remember correctly, the NFS server on VMS doesn't honour ACLs. Not
    100% sure of it though.

    I was told that file protections are often the cause of NFS headaches,
    and it was by fixing them that I got my setup between a mac and VMS working.

  3. Re: NFS setup with TCPIP services, what causes share to not mount?

    On Aug 28, 9:06*pm, JF Mezei wrote:
    > Rich Jordan wrote:
    > > /ds1/user/dave * * * * * * * * * * * * * *
    > > /ds3/files/ups * * * * * * * * * * * * * * *
    > > Any thoughts? *

    >
    > Start by enabling read-write for world on ds1:[000000]000000.dir as well
    > as ds1:[000000]user.dir
    >
    > See if it makes a difference. (then set it back to what it was before).
    >
    > Also, make sure that the protection of the mount point file on the
    > client system is setup properly.
    >
    > If I remember correctly, the NFS server on VMS doesn't honour ACLs. *Not
    > 100% sure of it though.
    >
    > I was told that file protections are often the cause of NFS headaches,
    > and it was by fixing them that I got my setup between a mac and VMS working.


    No go. Tried various settings all the way up to G:RWED W:RWED, but
    the nfs server continues to fail to map the export, with the same
    error in the log.

    Also tried redoing the map and the export in uppercase, matching the
    actual directory names.

    Also tried mapping several other shared directories on DSA1, using
    both all lowercase and 'exactly as shown' for export, with protections
    back up to the root directory of W:RWE, no go, same error.

    So nothing I've tried is able to get anything on drive DSA1 to map or
    generate a more useful error.

    Rich


  4. Re: NFS setup with TCPIP services, what causes share to not mount?

    On Aug 29, 9:54*am, Rich Jordan wrote:
    > On Aug 28, 9:06*pm, JF Mezei wrote:
    >
    >
    >
    > > Rich Jordan wrote:
    > > > /ds1/user/dave * * * * * * * * * * * * * *
    > > > /ds3/files/ups * * * * * * * * * * * * * * *
    > > > Any thoughts? *

    >
    > > Start by enabling read-write for world on ds1:[000000]000000.dir as well
    > > as ds1:[000000]user.dir

    >
    > > See if it makes a difference. (then set it back to what it was before).

    >
    > > Also, make sure that the protection of the mount point file on the
    > > client system is setup properly.

    >
    > > If I remember correctly, the NFS server on VMS doesn't honour ACLs. *Not
    > > 100% sure of it though.

    >
    > > I was told that file protections are often the cause of NFS headaches,
    > > and it was by fixing them that I got my setup between a mac and VMS working.

    >
    > No go. *Tried various settings all the way up to G:RWED W:RWED, but
    > the nfs server continues to fail to map the export, with the same
    > error in the log.
    >
    > Also tried redoing the map and the export in uppercase, matching the
    > actual directory names.
    >
    > Also tried mapping several other shared directories on DSA1, using
    > both all lowercase and 'exactly as shown' for export, with protections
    > back up to the root directory of W:RWE, no go, same error.
    >
    > So nothing I've tried is able to get anything on drive DSA1 to map or
    > generate a more useful error.
    >
    > Rich


    Tried other variants of the drive map in case it didn't like /ds1 or /
    DS1. Also tried aiming at a logical instead of the device name, with
    variation on the logical definition. Nothing works.

    Blew away the NFS config completely and rebuilt. Created test
    directories on DSA1 and DSA3. Any directory on DSA3 exports fine,
    even with the path leading to it protected. Any directory on DSA1
    cannot be shared with the same error, regardless of the UIC
    protections leading up the path.

    I'm stumped. I will be turning on access auditing on the directories
    making up the export path and see if there's any way to increase the
    NFS logging level (not documented in the manual, but maybe elsewhere).

    If anyone has a suggestion on correcting, or at least narrowing down
    the reason for this behavior I'd love to hear it.

    Thanks and have a great weekend.

    Rich

  5. Re: NFS setup with TCPIP services, what causes share to not mount?

    On Aug 29, 2:56*pm, Rich Jordan wrote:
    > On Aug 29, 9:54*am, Rich Jordan wrote:
    >
    >
    >
    > > On Aug 28, 9:06*pm, JF Mezei wrote:

    >
    > > > Rich Jordan wrote:
    > > > > /ds1/user/dave * * * * * * * * * * * * * *
    > > > > /ds3/files/ups * * * * * * * * * * * * * * *
    > > > > Any thoughts? *

    >
    > > > Start by enabling read-write for world on ds1:[000000]000000.dir as well
    > > > as ds1:[000000]user.dir

    >
    > > > See if it makes a difference. (then set it back to what it was before).

    >
    > > > Also, make sure that the protection of the mount point file on the
    > > > client system is setup properly.

    >
    > > > If I remember correctly, the NFS server on VMS doesn't honour ACLs. *Not
    > > > 100% sure of it though.

    >
    > > > I was told that file protections are often the cause of NFS headaches,
    > > > and it was by fixing them that I got my setup between a mac and VMS working.

    >
    > > No go. *Tried various settings all the way up to G:RWED W:RWED, but
    > > the nfs server continues to fail to map the export, with the same
    > > error in the log.

    >
    > > Also tried redoing the map and the export in uppercase, matching the
    > > actual directory names.

    >
    > > Also tried mapping several other shared directories on DSA1, using
    > > both all lowercase and 'exactly as shown' for export, with protections
    > > back up to the root directory of W:RWE, no go, same error.

    >
    > > So nothing I've tried is able to get anything on drive DSA1 to map or
    > > generate a more useful error.

    >
    > > Rich

    >
    > Tried other variants of the drive map in case it didn't like /ds1 or /
    > DS1. *Also tried aiming at a logical instead of the device name, with
    > variation on the logical definition. *Nothing works.
    >
    > Blew away the NFS config completely and rebuilt. *Created test
    > directories on DSA1 and DSA3. *Any directory on DSA3 exports fine,
    > even with the path leading to it protected. *Any directory on DSA1
    > cannot be shared with the same error, regardless of the UIC
    > protections leading up the path.
    >
    > I'm stumped. *I will be turning on access auditing on the directories
    > making up the export path and see if there's any way to increase the
    > NFS logging level (not documented in the manual, but maybe elsewhere).
    >
    > If anyone has a suggestion on correcting, or at least narrowing down
    > the reason for this behavior I'd love to hear it.
    >
    > Thanks and have a great weekend.
    >
    > Rich


    Now I will have a great weekend too.

    When you export a share on a mapped ODS5 volume you apparently have to
    specify the /OPT=NAME_CONVERSION on the ADD EXPORT command line.

    This is in contradiction to the info in the TCPIP management guide
    which states:

    "If and ODS-5 volume is mapped and exported, the NFS server
    automatically
    supports EFS features and ignores the NAME_CONVERSION option of the
    EXPORT command, if it is specified in the export record"

    I'll send a note to the docs people.

    Rich

  6. Re: NFS setup with TCPIP services, what causes share to not mount?

    Rich Jordan wrote:

    > Tried other variants of the drive map in case it didn't like /ds1 or /
    > DS1. Also tried aiming at a logical instead of the device name, with
    > variation on the logical definition. Nothing works.


    Here is some of the exports I have:

    /disk2/users/jfmezei BRAKES, 10.0.0.20
    Options: Purge Typeless Name_cvt

    /disk2/www_main 10.0.0.20, BRAKES
    Options: Purge Typeless

    /disk2/www_wap 10.0.0.20, BRAKES
    Options: Purge Typeless Name_cvt


    This is on an ODS5 disk. I guess I should also have the Name_conversion
    in the www_main options.

    help add export gives you the list of options.

    NFS doesn't give out much in terms of debugging, yet it is picky to the
    extreme. And this isn't just for VMS.

    I guess I could be using wireshark to see if it can parse NFS packets
    and give me more info on how it works.

    Also, remember WHO mounts the drive on the client side. On a mac, if the
    drive is mounted by automount, then "root" is the one that mounts, and
    you then have to make sure the protection of the file that is the mount
    point on the client works correctly for the actual user.

+ Reply to Thread