Hello again... I have some more information as to the problem, but I still don't know the solution. Once I connect to the server, I seem to get stuck in the following NLM sequence. This repeats over and over again before finally giving up. Am I missing some permissions somewhere? No. Time Source Destination Protocol Info 1580 375.541821 172.16.14.45 172.16.12.19 NLM V4 SHARE Call (Reply In 1581) FH:0x05560804 Frame 1580 (186 bytes on wire, 186 bytes captured) Ethernet II, Src: DellPcba_76:2f:9d (00:0d:56:76:2f:9d), Dst: TyanComp_51:d3:a7 (00:e0:81:51:d3:a7) Internet Protocol, Src: 172.16.14.45 (172.16.14.45), Dst: 172.16.12.19 (172.16.12.19) User Datagram Protocol, Src Port: 1023 (1023), Dst Port: filenet-tms (32768) Remote Procedure Call, Type:Call XID:0x2606d945 Network Lock Manager Protocol Program Version: 4 V4 Procedure: SHARE (20) cookie: <DATA> length: 4 contents: <DATA> share caller_name: wtn1404515:05.554861000 length: 8 contents: wtn1404515:05.554861000 fh length: 12 hash: 0x05560804 type: Linux knfsd (new) version: 1 encoding: 0 0 0 authentication: none file system ID: 3,2 (inode 305793) major: 3 minor: 2 inode: 305793 file ID: root inode owner: <DATA> length: 4 contents: <DATA> mode: deny read/write (3) access: read/write (3) reclaim: No No. Time Source Destination Protocol Info 1581 375.541998 172.16.12.19 172.16.14.45 NLM V4 SHARE Reply (Call In 1580) NLM_DENIED Frame 1581 (82 bytes on wire, 82 bytes captured) Ethernet II, Src: TyanComp_51:d3:a7 (00:e0:81:51:d3:a7), Dst: DellPcba_76:2f:9d (00:0d:56:76:2f:9d) Internet Protocol, Src: 172.16.12.19 (172.16.12.19), Dst: 172.16.14.45 (172.16.14.45) User Datagram Protocol, Src Port: filenet-tms (32768), Dst Port: 1023 (1023) Remote Procedure Call, Type:Reply XID:0x2606d945 Network Lock Manager Protocol Program Version: 4 V4 Procedure: SHARE (20) cookie: <DATA> length: 4 contents: <DATA> stat: NLM_DENIED (1) sequence: 0 TIA, Dave At 08:26 PM 9/15/2005, you wrote:
Hi folks,
I'm trying to run pcnfsd on my server and I'm running into a couple of issues.
On a VMWare based client on the same machine, I get the error "AUTH_DES operation failed. Ensure client and server time clocks are synchronized." Considering it's the same machine, and the VMWare tools are set to synchronize the clocks, should I be getting this?
On a remote machine, it connects, but is extremely slow - on the order of 5 minutes from selecting a directory until its contents are displayed. By remote, I mean sitting right next to the server.
In both cases the client is Hummingbird NFS Maestro 7.0. They can also connect to a Solaris 8 server without issue.
Questions, comments, suggestions?
TIA, Dave
-- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help@suse.com