OpenVMS - configuring NFS Server

[Stephanie LaRiviere]

I have read the TCPIP manual. the @sys$manager:tcpip$config shows NFS and Portmapper enabled and started.
TCPIP> show map displays
/nfs_dstore cntari$DRA1:

TCPIP> show export displays
/nfs_dstore/user1/dstore tkrb2nfs
note: tkrb2nfs is in the host table in both upper and lower case.

TCPIP> show proxy displays
UCX$NFS OND 0 1 *
UCX$NOBODY OND -2 -2 *
DSTORE OND 27530 125 tkrb2nfs


When I try to mount the cntari drive on tkrb2nfs, I receive the following error

tkrb2nfs(root) 60: mount cntari:/nfs_dstore/user1/dstore /nfs_dstore

nfs mount: cntari:/nfs_dstore/user1/dstore: Permission denied

What am I leaving out ?? I have searched every document referring to this without any luck.

[Joseph Huber_1]

I'm not sure if it's the only solution, but for a root mount I think a proxy from /gid=/uid=0 (root) to SYSTEM is needed.

I suppose a user mount (option user in fstab) will need a proxy for the user in question.

[Ian Miller.]

enable operator messages
$ REPL/ENABLE

as sometimes messages from NFS server will give more detail.

[Daniel Fernandez Illan]

Hi
who is the owner of cntari$DRA1:[user1.dstore]=?
For me you need add a proxy on VMS from Unix root to VMS owner of directory.
Saludos.
Daniel.

[Wim Van den Wyngaert]

Didn't you mix ucx and tcp ? Are the ucx users still declared ?

In any case, on the node on which you do the mount, the mount-user should be mapped with an tcpip proxy to 2 numbers. These 2 numbers (uid and gid) will be passed to the server that will look up the values in the server proxy table and the resulting user name will be used to do the mount. He/she/it must have read access to the directory to be mounted.

Wim

[Stephanie LaRiviere]

UCX users are still declared.

I also tried mapping a proxy for "system" to root, "ucx$nfs" to root, and "dstore" (owner of the directory) to root -- no difference.

Another piece of information -- if I do a
TCPIP> sho serv The NFS shows disabled (note: remember the sys$manager:tcpip$config shows enabled and started) When I try to TCPIP> enable serv NFS it doesn't change the status.

[Wim Van den Wyngaert]

May be the the upgrade didn't work correctly.
Check if the process tcpip$portm_1 and tcpip$nfs_1 are running.

I would disable them 2 again using the menu and enable them again.
Missing things will be created this way (I had the problem recently when going from 6.2 to 7.3).

And don't forget reply/ena.

Wim

[Wim Van den Wyngaert]

Root always comes in as 0,1 and on VMS you mapped it to ucx$nfs (unless some nfs logical mapps it elsewhere). Is that user having access and privs ?

Wim

[Daniel Fernandez Illan]

Stephanie
Are you upgrade TCP from 5.0 to 5.4?
In this case you must check if domain is defined.
When use TCP version 5.0 yo does not need to have a defined domain, but in 5.4 domain definition is necessary.

See
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=641987
Saludos.
Daniel.

[Stephanie LaRiviere]

When doing a "pipe show system|search sys$input tcp" -- I see the mountd and portmapper....but no NFS

20800122 TCPIP$INETACP HIB 8 9179 0 00:00:03.76 223 174
20800124 TCPIP$PORTM_1 LEF 10 398 0 00:00:00.30 239 237 N
20800125 TCPIP$FTP_1 LEF 8 60267 0 00:00:08.97 555 311 N
20800129 TCPIP$MOUNTD_1 LEF 10 399 0 00:00:00.28 507 426 N
20800130 TCPIP$TNS1 HIB 4 66 0 00:00:00.06 229 147
20800146 TCPIP$NTP_4 LEF 8 610665 0 00:02:25.10 313 266 N
20805180 TCPIP$FTPC0001C HIB 6 7607 0 00:00:05.05 431 221 N


Through @sys$manager:tcpip$config, I disabled NFS and then re-enabled it...no difference. Remember, as stated before, TCPIP> SHO SERV displays NFS and disabled but MOUNT as enabled -- I also can't seem to change the status of NFS in services, so maybe it's not necessary ?

I am currently running V5.1 ECO 3 of TCPIP

After enabling reply...I tried to mount again:
%%%%%%%%%%% OPCOM 5-OCT-2005 09:20:09.32 %%%%%%%%%%%
Message from user NFS Server on CNTARI
Accepted connection from host 144.115.65.140 port 62144
NOTE: this IP is the unix server tkrb2nfs

On the unix side, I get a :
"NFS server cntari not responding still trying"
NOTE: Yes, I can telnet and ping cntari

[Ian Miller.]

when you disabled/enabled NFS did you also
@SYS$STARTUP:TCPIP$NFS_STARTUP

?

[Wim Van den Wyngaert]

The NFS process is only present when someone mounted the fs, so it is normal.

Are NFS, MOUNT and PORTMAPPER in the output of :
ucx sho conf ena servi
ucx sho conf ena servi/common
?

Did you check startup error messages ? Also in operator.log ? Also check the log files in sys$sysdevice:[*tcp*], note that they are open, so check the previous versions. E.g. missing users, directories etc ?

Wim

[Stephanie LaRiviere]

$ ucx sho conf ena servi

Enable service
FTP, FTP_CLIENT, LPD, METRIC, NFS, NFS_CLIENT, NTP, PORTMAPPER, REXEC,
RLOGIN, RSH, SMBD, SMTP, SNMP, TELNET

I don't see MOUNT, but everything else is there.

When I run @sys$startup:tcpip$nfs_startup I receive the following:
$ @SYS$STARTUP:TCPIP$NFS_STARTUP
%TCPIP-E-STARTFAIL, failed to start TCPIP$NFS
-TCPIP-E-NOSTARTUP, startup procedure did not complete


I tried starting it up by using the following:
@sys$system:tcpip$nfs_startup.com
Unfortunately it doesn't background, so I have to interrupt the task to look at the log to see if it's doing anything. It mentions in the log that it started with 8 threads -- BUT, I still can't mount afterwards. Receive the following message from unix:
tkrb2nfs(root) 52: mount cntari:/nfs_dstore/user1/dstore /nfs_dstore
nfs mount: cntari: : RPC: Unable to receive
nfs mount: retrying: /nfs_dstore

I did find a log that is generated when I run a different nfs_startup =

$ type SYS$SYSDEVICE:[TCPIP$NFS]TCPIP$NFS_SERVER_STARTUP.LOG
$!------------------------------------------------------------------------------
$! SYS$MANAGER:SYLOGIN.COM - System-wide default login file
$! adapted from sdvax
$!------------------------------------------------------------------------------
$! This command procedure is always run when anybody on the entire system
$! logs in. It is equivalent to LOGIN.COM except that the instructions
$! contained herein are executed everytime anyone on the VMS system
$! logs in to their account.
$!
$ set noon
$ set noverify
%DCL-E-OPENOUT, error opening SYS$SYSDEVICE:[UCX$NFS]UCX$NFS_STARTUP.LOG; as output
-RMS-E-PRV, insufficient privilege or file protection violation
TCPIP$NFS job terminated at 3-OCT-2005 13:07:48.50


When I go check that log, it actually says:
$ type SYS$SYSDEVICE:[UCX$NFS]UCX$NFS_STARTUP.LOG
NFS Server started at 5-OCT-2005 11:26:04.50
Configured for 8 TCP threads and 8 UDP threads
note: Remember this doesn't background, so I have to Y to see the log.

[Stephanie LaRiviere]

ADDITIONAL INFO:

$ sho log tcpip$nfs*

(LNM$PROCESS_TABLE)

(LNM$JOB_81CE2D80)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

"TCPIP$NFS_SERVICES" = "SYS$LOADABLE_IMAGES:TCPIP$NFS_SERVICES.EXE"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
$

[Joseph Huber_1]

I have the impression, Your TCPIP installation/setup went wrong or was not completely finished, at least the NFS setup.

Did You do TCPIP$CONFIG for NFS after the update from UCX to TCPIP services ?
If authorize does not show user TCPIP$NFS, and if TCPIP show proxy does not show TCPIP$NOBODY, then this is the case.

Do the configuration again to see it changing.

There should be no sys$system:tcpip$nfs_startup.com, only in sys$startup. Somehow Your installation has been manipulated or the system disk is corrupted ?

In the worst case You may have to remove TCPIP and install it again, using
PRODUCT REMOVE TCPIP
PRODUCT INSTALL TCPIP
after a @SYS$STARTUP:TCPIP$SHUTDOWN.

[Joseph Huber_1]

"startup procedure did not complete" indicates a previous sys$startup:tcpip$nfs_startup ended already with an error.
Do a "set verify" before to see what fails (probably You need tcpip$shutdown before next attempt, since it will never go further when it detects an incomplete NFS startup).

If You have the TCPIP startup in systartup, then enable logging and verification of systartup by setting sysgen parameter STARTUP_P2 to e.g. "CDP".
Then You can examine STARTUP.LOG .

And the mysterious sys$system:tcpip$nfs_startup "hanging":
The correct startup file is doing only a few
TCPIP commands. See also with verification on where it is waiting.

What puzzles me most is the mixup of UCX and TCPIP names, therefore first check the configuration!

[Daniel Fernandez Illan]

Stephanie
what is the output of command

SHO SYS/PROC=TCPIP*

You need view the process TCPIP$MOUNTD_1. If does not have this, then you have a problem with the startup of MOUNT service.
Saludos.
Daniel.

[Ian Miller.]

Do
$ DIR/SEC SYS$SYSDEVICE:[000000]UCX$NFS.DIR
It should be
[UCX$AUX,UCX$NFS] (RWE,RWE,RE,E)

[Stephanie LaRiviere]

Ian, your request returns what was expected:
$ DIR/SEC SYS$SYSDEVICE:[000000]UCX$NFS.DIR

Directory SYS$SYSDEVICE:[000000]

UCX$NFS.DIR;1 [UCX$AUX,UCX$NFS] (RWE,RWE,RE,E)

Total of 1 file.
$


Daniel, the SHO SYS/PROC=TCPIP* originally showed that the TCPIP$MOUNTD was running...however, I had to shut NFS (whatever processes associated with it) down, because it caused my system to crash. Analysis of the crash pointed to an NFS process....even though I couldn't get the main NFS process to run (must have been something in background that kept running even though the logs said NFS failed to start).

Joseph, I would be extremely hesitant to reinstall TCPIP since there are other associated processes running and used daily. I did not do an upgrade, but it does show both UCX and TCPIP accounts on the system.

[Joseph Huber_1]

Even if YOU did not do the upgrade from UCX to TCPIP services, there was a previous UCX installation, otherwise the UCX$ logicals would not be used in TCPI$*startup.
Use AUTHORIZE to see if UCX$NFS is the same UIC as TCPIP$NFS, if not , then one of the reasons startup fails is accessability of [UCX$NFS] directory.
The fact that a startup fails early in the procedure with "startup procedure did not complete" is a check for a logical tcpip$nfs_started exists and does not have "completed" in the equivalence string . In this case tcpip$nfs_startup does nothing at all.

[Lawrence Czlapinski]

Stephanie: I had a similar problem with TCPIP funcitons having LOGIN.COM privilege problem. You also need to check the LOGIN.COM security.
$ DIR/SEC SYS$SYSDEVICE:[UCX$NFS]LOGIN.COM
It turns out that several different TCPIP function owned the wrong LOGIN.COM files so the requesting functions couldn't weren't the owner of the file. Since group doesn't have WRITE privilege, permission is denied and the TCPIP function failed.
I had to manually fix the ownership. Apparently the functions receive the individual UIC numbers in the order that they are installed the first time.
Lawrence

[Stephanie LaRiviere]

Joseph, I checked the UIC's and they are different:
UCX$NFS UCX$NFS [375,11] UCX$NFS
TCPIP$NFS TCPIP$NFS [3655,13] TCPIP
note: they do point to different directories.

One thing no one has responded to is the fact that I can not update the SERV for NFS in TCPIP (still shows disabled:
TCPIP>NFS 2049 UDP UCX$NFS Disabled
NOTE: remember @sys$manager:tcpip$config shows NFS as ENABLED and STARTED.

When I try to update the SERV, it excepts the input, but makes no changes (I've mentioned this in previous notes).

Lawrence, the UCX$NFS dir is owned by UCX$NFS AND UCX$AUX --- the same for TCPIP dir being owned by TCPIP$NFS, etc. I'll add the UCX to the TCP and vice-verse to see if this helps.

[Joseph Huber_1]

At least the different group-IDs between UCX$NFS and TCP$NFS explains one (the primary ?) error in TCPIP$NFS startup: in one of the replies You showed tcpip$nfs wants to write into [UCX$NFS], but can't because of the directory protection.

I can't follow what happened at TCPIP services installation over an existing UCX version. On my systems it correctly pointed all directory use to [TCPIP$NFS] rather than [UCX$NFS]. But as long as this is not fixed, it will not work.

Maybe as a first try (since You don't want to re-install), give TCPIP$NFS write access to the UCX$NFS directory using an ACL:
Set acl/acl=(ident=TCPIP$NFS,access=R+W+C) sys$sysdevice:[000000]tcpip$nfs.dir

Of course this just for trying out, not a permanent cure for the mess.

And note: as long as the logical tcpip$nfs_started in table tcpip$startup_table does not have the word "completed", tcpip$nfs_startup will do nothing !