× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We use the NFS client in OS/400 V5R2 to mount a file system that resides on
a SunOS 5.8 box.

Normally this works just fine. We have the mount command in our startup job,
we IPL every week, and normally don't have any problems and the NFS mounted
data is available when we need it.

But once in a while, we start getting permission denied errors when we try
to access the data. I don't see anything suspicious in QSYSOPR. Any attempt
to execute the mount command gets:

Message ID . . . . . . :   CPFA09C       Severity . . . . . . . :   40

Message type . . . . . :   Diagnostic

Date sent  . . . . . . :   03/04/04      Time sent  . . . . . . :   13:11:13

 

Message . . . . :   Not authorized to object.  Object is *N.

Cause . . . . . :   Authority is not sufficient to access object *N.

Recovery  . . . :   Obtain permission to use the object *N and try the

  operation again. Permission must be granted by the owner or other
authorized
  person. If the object name is *N, it could not be determined which of the

  objects authority was not sufficient.  The iSeries Security Reference,

  SC41-5302, contains authority information for the operation.


Any attempt to unmount the file system appears to succeed, with:

Message ID . . . . . . :   CPCA1B1       Severity . . . . . . . :   00      
Message type . . . . . :   Completion                                       
Date sent  . . . . . . :   03/04/04      Time sent  . . . . . . :   13:12:17
                                                                            
Message . . . . :   File system or directory unmounted.                     
Cause . . . . . :   /QOpenSys/mydir/mysubdir was successfully unmounted.   


When this happens, I usually mess around from the OS/400 side for quite a
while, including IPL, to no avail, then contact the UNIX admins. They always
say they can find nothing wrong from their side, then they mess around for a
while, to no avail. Then at some point, usually several to many hours later,
the mount command works again and everything is fine, and both sides deny
having done anything to fix it.

During the time that the mount is not working, I always verify TCP/IP
connectivity with ping, telnet, FTP, and everything is fine except NFS.

I do not believe the "authority" error is legitimate, because like I said,
most of the time this works, I also try doing themount with a variety of
user profiles including QSECOFR (what usrprf would the QSTRUPPGM run under,
QSYS?) and anyway, at some point, the mount will just start working again.
The problem is I never know when it is going to start working again and
sometimes we can't wait.

I have been all over IBMlink, midrange archives, and Google but I haven't
found anything to help me out.

I looked at TRCTCPAPP but I don't see an option for NFS. Would I just have
to trace the whole line?

I am not vey UNIX savvy, but our UNIX guys are pretty good and I trust them
that they aren't fixing anything from their side. Furthermore, I admit I am
prejudiced against the iSeries when it comes to TCP/IP applications. I just
figure the UNIX boxes have been doing it longer so they should be less
likely to have an error than OS/400.

Anybody else have this problem, or have any ideas what I might try? I don't
have any authority on the UNIX side but they are pretty cooperative. Really,
this problem only occurs once every several months, so it works >99% of the
time, but when it doesn't work it is totally unacceptable because neither
side knows how to fix it reliably.

Thanks all,
-Marty

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.