Assuming you have logging enabled (normally is by default), look in /var/log/messages for NFS server errors. It will have told you there what it did not like about the mount attempt from MVS (by addr or by name).
-- R; <>< Rick Troth Velocity Software http://www.velocitysoftware.com/ On Thu, Sep 22, 2011 at 14:33, Dazzo, Matt <[email protected]> wrote: > Rich, I updated the Linux (27.2.39.104) hosts file to contain a dns name, > same on the mvs side. So now I can use dns name which should be resolved. I > am going to cross post this on MVS-OE list and see if I get any responses. > > > Linux(lntest1) hosts file > 27.1.39.74 mvstech.li.pch.com > 27.1.39.104 lntest1.li.pch.com > > Linux exports file > /matt mvstech.li.pch.com(ro) > > MVS mount commands > MOUNT FILESYSTEM(LN.NFSTEST) TYPE(NFS) + > MOUNTPOINT('/u/st1mat/test/') + > PARM('lntest1.li.pch.com:/matt,XLAT(Y)') > > Errors received, > BPXF162E ASYNCHRONOUS MOUNT FAILED FOR FILE SYSTEM LN.NFSTEST. > BPXF028I FILE SYSTEM LN.NFSTEST WAS 592 > NOT MOUNTED. RETURN CODE = 0000046A, REASON CODE = 6E2A1003 > > > -----Original Message----- > From: Richard Troth [mailto:[email protected]] > Sent: Wednesday, September 21, 2011 3:16 PM > To: Dazzo, Matt > Cc: Linux on 390 Port > Subject: Re: RH NFS Server > > Hang in there. You will get this. Many of us can relate to the double > whammy. > > As you describe it, you have used "mvstech.li.pch.com" on both ends of > the equation. No can do. Presuming it is the MVS side, then the > Linux files look good. So you want to name your Linux box in the > mount job on the MVS side. Maybe something like ... > > PARM('lnxtech.li.pch.com:/matt,XLAT(Y)') > > -- R; <>< > Rick Troth > Velocity Software > http://www.velocitysoftware.com/ > > > > > > On Wed, Sep 21, 2011 at 14:41, Dazzo, Matt <[email protected]> wrote: >> Rich, I agree with you questioning the empty zfs file. I believe I was just >> grasping at straws to try something else. >> It does not make sense. New to Linux and nfs so I got a double whammie >> working. So now here is what I got; >> >> Updated /etc/hosts with, 27.1.39.74 mvstech.li.pch.com >> Updated /etc/exports with, /matt mvstech.li.pch.com(ro) >> Start nfs services with command, service nfs start >> Run batch job on mvs with below commands >> MOUNT FILESYSTEM(LN.NFSTEST) TYPE(NFS) + >> MOUNTPOINT('/u/st1mat/test/') + >> PARM('mvstech.li.pch.com:/matt,XLAT(Y)') >> >> Then get the following on the console >> BPXF028I FILE SYSTEM LN.NFSTEST WAS 351 >> NOT MOUNTED. RETURN CODE = 0000046A, REASON CODE = 6E2A1003 >> >> 046a= No route to host >> 6e2a= unable to find this, might mean ' Verify that the operation was >> performed on a physical file system that supports the operation' >> >> Any help is greatly appreciated, thanks Matt >> >> -----Original Message----- >> From: Richard Troth [mailto:[email protected]] >> Sent: Tuesday, September 20, 2011 3:55 PM >> To: Dazzo, Matt >> Cc: Linux on 390 Port >> Subject: Re: RH NFS Server >> >> I don't know z/OS well enough to say if >> "FILESYSTEM(SYS1.OMVS.NFSTEST)" is required. Does not make sense >> that you would need a local empty ZFS filesystem. The "filesystem" of >> interest is a sub-directory of a remote filesystem. (Or could be the >> entire remote filesystem.) So at first blush, I would think you have >> introduced a conflict. What is z/OS supposed to do with the local FS >> when you're trying to mount a remote FS? >> >>> 8B= operation not permitted >>> 6E05=ownership issue >> >> These errors *look* like the server rejecting you. But I am confused >> by your use of the local ZFS. >> >> The "MOUNTPOINT('/u/st1mat/test/')" makes perfect sense. The norm >> is that it be an empty directory. Most Unix systems require only that >> it exist. (If it has any content, the content is obscured by the NFS >> filesystem you mount over it.) You said it exists in USS. Good. >> Ownership of that (empty) directory may come into play. You might >> need to ask people on the MVS-OE discussion. (But some of them are >> probably on this list too.) >> >> So then ... "27.1.39.104" is the Linux system, yes? And "/matt" >> exists and has been listed in your /etc/exports file there, correct? >> What happens next is that 27.1.39.104 sees connections coming from >> z/OS. What is that IP address? The Linux NFS server will need to >> resolve that address to a hostname. That hostname must match what is >> allowed via /etc/exports. Personally, I find that I often must list >> these "clients" in /etc/hosts. (on the Linux NFS server side) There >> are changes to the Linux NFS server which I haven't kept up with, so >> there are probably a dozen ways to skin this cat. >> >> Say, for example, that MVS is at 27.1.39.101. Call it "mymvs". >> /etc/hosts would include ... >> >> 27.1.39.101 mymvs >> >> and /etc/exports would include ... >> >> /matt mymvs(ro) >> >> YOU MAY be able to export by address, but most of us will tell you >> "use hostnames". >> >> /matt 27.1.39.101(ro) >> >> -- R; <>< >> Rick Troth >> Velocity Software >> http://www.velocitysoftware.com/ >> >> >> >> >> >> >> >> >> On Tue, Sep 20, 2011 at 15:03, Dazzo, Matt <[email protected]> wrote: >>> Richard, are you saying I have update the /etc/hosts so that the NFS server >>> will allow the mount? Currently my mount job looks like this, >>> MOUNT FILESYSTEM(SYS1.OMVS.NFSTEST) TYPE(NFS) + >>> MOUNTPOINT('/u/st1mat/test/') PARM('27.1.39.104:/matt,XLAT(Y)') >>> >>> Where, >>> SYS1.OMVS.NFSTEST - is an empty zfs not currently mounted. >>> MOUNTPOINT('/u/st1mat/test/') - empty dir on mvs uss >>> PARM('27.1.39.104:/matt,XLAT(Y)') - RHEL 5.5 Linux server, /matt is the >>> directory I want to access from uss. >>> >>> Getting this error >>> BPXF028I FILE SYSTEM SYS1.OMVS.NFSTEST WAS 322 >>> NOT MOUNTED. RETURN CODE = 0000008B, REASON CODE = 6E050001 >>> >>> 8B= operation not permitted >>> 6E05=ownership issue >> > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
