NFS broken with V8.2 upgrade (& ODS-5 system disk)

Hi gentle folks. Current details: HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1 on a Digital Personal WorkStation running OpenVMS V8.2 Before I upgraded to V8.2, I was serving an NFS disk from my Alpha. This is on the system disk, and during the upgrade I chose to change it to ODS-5. It now refuses to mount, with the following message: $ tCPIP mount dnfs1: "/alpha/" /host='node' /system/path="/alpha/000000" %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000] -SYSTEM-F-NOPRIV, insufficient privilege or object protection violation I changed absolutely nothing in the NFS configuration, and digging through the archives on this group, I see that it is set exactly as was before. Did anyone else find that NFS mounts broke with the 8.2 upgrade?

Paul Sture wrote: > HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1 > on a Digital Personal WorkStation running OpenVMS V8.2 .... > $ tCPIP mount dnfs1: "/alpha/" /host='node' /system/path="/alpha/000000" > %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000] > -SYSTEM-F-NOPRIV, insufficient privilege or object protection violation What's happening over on NFS server over on host 'node'? You can try commands such as TCPIP> SHOW EXPORT or such, or whatever command for whatever stack is in use on 'node', and the proxy mapping. Anything in the NFS server logs? (If you enable OPCOMs over in the NFS server -- assuming this is the OpenVMS TCP/IP Services NFS server, quite obviously -- does anything interesting show up?) These client errors are often triggered by errors on the server and its file system, or errors with the UID/GID mapping or the associated proxies. I've also seen cases where a configuration file has been overwritten or replaced somewhere along the way.

In article <HXOEg.59$kw4.36@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> wrote: > Paul Sture wrote: > > > HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1 > > on a Digital Personal WorkStation running OpenVMS V8.2 > ... > > $ tCPIP mount dnfs1: "/alpha/" /host='node' /system/path="/alpha/000000" > > %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000] > > -SYSTEM-F-NOPRIV, insufficient privilege or object protection violation > > What's happening over on NFS server over on host 'node'? Proof that every cloud has a silver lining :-) The cloud: Last night we had a power cut. The silver lining: While watching my VMS system come back up, in amongst the message flying past, I spotted errors with proxies not being loaded due to duplicate entries. These did *not* appear in operator.log. Reproducer: (quite long) ------------------------------------------------------------------------ S$ ! Let's start with new proxy and export databases $ $ $ show log tcpip$proxy "TCPIP$PROXY" = "SYS$COMMON:[SYSEXE]TCPIP$PROXY.DAT;1" (LNM$SYSTEM_TABLE) $ del tcpip$proxy $ show log tcpip$export "TCPIP$EXPORT" = "SYS$COMMON:[SYSEXE]TCPIP$EXPORT.DAT" (LNM$SYSTEM_TABLE) $ del SYS$COMMON:[SYSEXE]TCPIP$EXPORT.DAT; $ tcpip create proxy $ tcpip create export $ tcpip add proxy TCPIP$NFS /uid=0 /gid=0 /host=* $ tcpip add proxy TCPIP$NOBODY /uid=-2 / gid=-2 /host=* $ tcpip show map Dynamic Filesystem Map Pathname Logical File System /alpha $1$DKA0: $ tcpip show config map Filesystem Map Configuration Pathname Logical File System /alpha SYS$SYSDEVICE: $ tcpip add export "/alpha/xfer" /host=* $ tcpip show export File System Host name /alpha/xfer * $ @sys$startup:tcpip$proxy_shutdown %TCPIP-S-SHUTDONE, TCPIP$PROXY shutdown completed $ $ @sys$startup:tcpip$nfs_shutdown %TCPIP-I-INFO, mount service disabled %TCPIP-I-INFO, nfs service disabled %TCPIP-I-INFO, process TCPIP$MOUNTD_1 (pid=2020047B) stopped %TCPIP-I-INFO, filesystems unmapped %TCPIP-I-INFO, vfs subsystem unloaded %TCPIP-I-INFO, nfs subsystem unloaded %TCPIP-I-INFO, logical names deleted %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$MOUNTD.EXE deinstalled %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$NFS_SERVER.EXE deinstalled %TCPIP-S-SHUTDONE, TCPIP$NFS shutdown completed $ $ $ @sys$startup:tcpip$proxy_startup %TCPIP-E-DYNPROXERR, cannot add record to proxy database (TCPIP$PROXY) in dynamic memory -TCPIP-I-PROXYINFO, User: TCPIP$NFS, UID: 0, HOST: * -SYSTEM-F-DUPLNAM, duplicate name %TCPIP-E-DYNPROXERR, cannot add record to proxy database (TCPIP$PROXY) in dynamic memory -TCPIP-I-PROXYINFO, User: TCPIP$NOBODY, UID: -2, HOST: * -SYSTEM-F-DUPLNAM, duplicate name %TCPIP-I-PROXYLOADED, loaded 0 NFS proxy records %TCPIP-I-INFO, nfs proxies loaded %TCPIP-I-LOADSERV, loading TCPIP server proxy information %TCPIP-I-SERVLOADED, auxiliary server loaded with 0 proxy records -TCPIP-I-SERVSKIP, skipped 0 communication proxy records -TCPIP-I-SERVTOTAL, total of 2 proxy records read %TCPIP-I-INFO, communication proxies loaded %TCPIP-S-STARTDONE, TCPIP$PROXY startup completed $ $ @sys$startup:tcpip$nfs_startup %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$MOUNTD.EXE installed %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$NFS_SERVER.EXE installed %TCPIP-I-INFO, logical names created %TCPIP-I-INFO, subsystem nfs loaded %TCPIP-I-INFO, subsystem vfs loaded %TCPIP-I-INFO, filesystems mapped %TCPIP-I-INFO, nfs service enabled %TCPIP-I-INFO, mount service enabled %TCPIP-S-STARTDONE, TCPIP$NFS startup completed $ sh dev d Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt $1$DKA0: (DINA) Mounted 0 ALPHASYS 922284 918 1 $1$DKB400: (DINA) Online wrtlck 0 $1$DVA0: (DINA) Online 0 DNFS0: (DINA) Online 0 ------------------------------------------------------------------------ Taking this further, I then deleted the proxies, and tried the suggestion as detailed in the latest TCP/IP Services Management Manual, section "22.1.5 Mapping the Default User", to add sysconfig entries to TCPIP$NFS_SYSTARTUP.COM thus: $ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS $ SYSCONFIG -r nfs_server noproxy_uid=-2 noproxy_gid=-2 NOTE: this is wrong, as the tcpip$nfs_startup complains that sub-system "nfs_server" doesn't exist. Changing that to "nfs" results in the following message during nfs_startup: noproxy_uid: reconfigured noproxy_gid: reconfigured Still no joy, as no DNFS1: device appears. -- Paul Sture

In article <LemFg.173$Nx5.88@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> wrote: > Paul Sture wrote: > > Punt the proxy database, and recreate it? Already did that; still no joy. -- Paul Sture

Paul Sture wrote: > In article <LemFg.173$Nx5.88@news.cpqcorp.net>, > Hoff Hoffman <hoff-remove-this@hp.com> wrote: > >> Paul Sture wrote: >> >> Punt the proxy database, and recreate it? > > Already did that; still no joy. On the server, follow the SHOW EXPORT and SHOW PROXY and SHOW CONFIG MAP output, and take a look at the ownerships of the served directories associated with the server-local usernames "behind" the proxies. And does (what I have to assume is the nobody proxy mapping) have access into the $1$DKA0:[000000] area? Anything in the NFS server logs? And IIRC, there's a way to enable added diagnostics in the NFS server environment. Off the top, I don't recall exactly how to enable it... Any security alarms on the server, if these are enabled and tracking activity for file access failures? (And I'd tend to expect a couple of messages related to the connection and the connection failure somewhere in the NFS log file...) Failing such, this is likely going to involve contact with the folks at the regional support center.

Paul, Google sent me to this thread... Paul Sture <paul.sture.nospam@hispeed.ch> wrote: > In article <HXOEg.59$kw4.36@news.cpqcorp.net>, > Hoff Hoffman <hoff-remove-this@hp.com> wrote: > >> Paul Sture wrote: >> >> > HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1 >> > on a Digital Personal WorkStation running OpenVMS V8.2 >> ... >> > $ tCPIP mount dnfs1: "/alpha/" /host='node' >> > /system/path="/alpha/000000" %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error >> > mounting _DNFS1:[000000] -SYSTEM-F-NOPRIV, insufficient privilege >> > or object protection violation >> <snip> > > Aha. The problem lies further back, when NFS starts. Sorry for the > confusion: > > $ tcpip show map > Dynamic Filesystem Map > Pathname Logical File System > > /alpha $1$DKA0: > $ tcpip show export > > File System Host name > > /alpha/000000 * > <snip> > > Error messages from the last boot, in OPERATOR.LOG > > %%%%%%%%%%% OPCOM 13-AUG-2006 00:23:00.38 %%%%%%%%%%% > Message from user TCPIP$NFS on DINA > %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file > /alpha/000000 > > %%%%%%%%%%% OPCOM 13-AUG-2006 00:23:00.67 %%%%%%%%%%% > Message from user TCPIP$NFS on DINA > %TCPIP-E-MAPNOSYS, file system is not mapped > > and I get the same when I stop and restart the NFS server. Did you ever get this resolved? I have exactly the same problem, with many common points in the configuration. NFS server: OpenVMS Alpha V7.3-2, TCPIP V5.4 ECO 4, serving a directory on an ODS-5 disk NFS client: OpenVMS Alpha V8.2, TCPIP V5.5 ECO 1 When starting NFS on the server, I get the "operation MOUNT_POINT failed" and "fileystem not mapped" errors. When issuing a "TCPIP MOUNT", I get the "insufficient privilege" error. The mountd logfile only says ERROR: stat: no such file or directory, Cannot stat /data2/nfs The user used by the proxy has access to directory [nfs] and the files in it. I'm running out of clue :-) Thanks for any hint, Hans.

In article <el7hcm.71.1@usenet.bachner.priv.at>, Hans Bachner <Hans@Bachner.priv.at> wrote: > Paul, > > Google sent me to this thread... > <snip> > > %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file > > /alpha/000000 > > > <snip> > Did you ever get this resolved? I have exactly the same problem, with many > common points in the configuration. > No I didn't get it resolved. It wasn't a show stopper for me. It happened to me after upgrading to 8.2, but I can't say that it was only 8.2, because I upgraded TCP/IP at the same time. Earlier on in the startup, TCP/IP was failing to load the proxies - a duplicate error was reported. But, and I cannot swear to this because my Alpha is currently dead, I am sure that after upgrading to 8.3, I was getting INSFMEM on loading the proxies. Malcolm Dunnett reported a similar situation here last week, but thought it was an Itanium only thing. Here's Malcolm's summary of what he found: "After much poking around I determined the culprit to be the system parameter GH_EXEC_DATA. The default value is 1024 and this was not adequate in my situation. AUTOGEN does not appear to touch this parameter. It seems that if the setting is too low you can get the INSFMEM error in lots of places, typically when loading a device driver but also when loading the TCP/IP services proxy database." -- Paul Sture

Paul Sture <paul.sture.nospam@hispeed.ch> wrote: > In article <el7hcm.71.1@usenet.bachner.priv.at>, > Hans Bachner <Hans@Bachner.priv.at> wrote: > >> Paul, >> >> Google sent me to this thread... > > <snip> >> > %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file >> > /alpha/000000 >> > > > <snip> >> Did you ever get this resolved? I have exactly the same problem, with >> many common points in the configuration. > > No I didn't get it resolved. :-( > It wasn't a show stopper for me. :-) > It happened to me after upgrading to 8.2, but I can't say that it was > only 8.2, because I upgraded TCP/IP at the same time. In the meantime, I found I get the same error with a V7.3-2 client. I then changed the configuration to export just the mapped device (without a directory specification appended to it) and this worked! > Earlier on in the startup, TCP/IP was failing to load the proxies - a > duplicate error was reported. My proxy database contains only two or three entries which load fine. > But, and I cannot swear to this because my Alpha is currently dead, I > am sure that after upgrading to 8.3, I was getting INSFMEM on loading > the proxies. Malcolm Dunnett reported a similar situation here last > week, but thought it was an Itanium only thing. <snip> I didn't observe anything related to this problem. Hans.

In article <elfv57.7n.1@usenet.bachner.priv.at>, Hans Bachner <Hans@Bachner.priv.at> wrote: > Paul Sture <paul.sture.nospam@hispeed.ch> wrote: > > > In article <el7hcm.71.1@usenet.bachner.priv.at>, > > Hans Bachner <Hans@Bachner.priv.at> wrote: > > > >> Paul, > >> > >> Google sent me to this thread... > > > > <snip> > >> > %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file > >> > /alpha/000000 > >> > > > > > <snip> > >> Did you ever get this resolved? I have exactly the same problem, with > >> many common points in the configuration. > > > > No I didn't get it resolved. > > :-( I was hoping that someone had seen similar, but no. > > It wasn't a show stopper for me. > > :-) Only in the sense that I don't absolutely need NFS for a Hobbyist system. It would still be nice to have. > > > It happened to me after upgrading to 8.2, but I can't say that it was > > only 8.2, because I upgraded TCP/IP at the same time. > > In the meantime, I found I get the same error with a V7.3-2 client. I > then changed the configuration to export just the mapped device (without > a directory specification appended to it) and this worked! > > > Earlier on in the startup, TCP/IP was failing to load the proxies - a > > duplicate error was reported. > > My proxy database contains only two or three entries which load fine. > Even with only 2 or 3 I was getting the error. > > But, and I cannot swear to this because my Alpha is currently dead, I > > am sure that after upgrading to 8.3, I was getting INSFMEM on loading > > the proxies. Malcolm Dunnett reported a similar situation here last > > week, but thought it was an Itanium only thing. > <snip> > > I didn't observe anything related to this problem. > It was just a thought. -- Paul Sture

Paul Sture <paul.sture.nospam@hispeed.ch> wrote: > In article <el7hcm.71.1@usenet.bachner.priv.at>, > Hans Bachner <Hans@Bachner.priv.at> wrote: > > <snip> > >> > %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file >> > /alpha/000000 >> > > > <snip> > >> Did you ever get this resolved? I have exactly the same problem, with >> many common points in the configuration. >> > > No I didn't get it resolved. It wasn't a show stopper for me. Well, it seems I could solve it - mostly. If you export a directory of a mapped device the required syntax depends on whether you use /OPTION=TYPELESS_DIRECTORIES or not. $ TCPIP ADD EXPORT "/nfs_test/mydir.dir" /HOST=* works like a charm. On the other hand, $ TCPIP ADD EXPORT "/nfs_test/mydir" /HOST=* /OPTION=TYPELESS still gives the "%TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed" message, but the directory is mounted and usable. The question remains whether this is intended behaviour or not. Hans.