NFS creates 0 byte file on NT

[Francois Rabe]

I have a system running HP-TRU64 Unix V5.1B.

I mount some disks on an NT server with the following command in /etc/fstab:

alsex4:/rdm /rdm nfs rw 0 2

I use the command: cp /tmp/uxcDfCuI /rdm/DEMAND/IN/SPP/55001136.IN to copy a file to the NFS mounted disk on the NT server.

The file is created on the NT server but it is 0 bytes in size and the above command seems to hang. It never completes and I have to kill the command.

Does anybody know what causes this? Is it perhaps some problem with permissions? If so what side - NT or Unix?

Thanks in advance.

[Ravi_8]

You need to have samba as interop between unix and windows, do tou have samba running on Tru64 machine?

[Michael Schulte zur Sur]

Ravi,

Samba? The unix machine is the client!
What patch kit are you running, Francois?

greetings,

Michael

[Francois Rabe]

Samba is indeed running on the system. The patch kit is PK3. Maybe I should add that this is a cluster - 2 x GS80's and 3 x GS1280's. The GS1280's were added recently and it is on these systems that NFS does not work. On the 2 x GS80's it works fine. I did not set up NFS on the GS1280's (as I thought being in a cluster you dont have to do it for all the systems) but now seriously think that it needs to be set up on there as well. It was originally set up on the GS80's. Any Ideas? Maybe I am missing something small here.

[Michael Schulte zur Sur]

Francois,

the nfs server is the win2k machine, right? So I just wonder why you should need to setup nfs on the cluster.

hth,

Michael

[Ralf Puchner]

And I'm wondering how permission should work without an permission/owner mapping mode on NT side. But it seems the good old "slow" PC network problem because connection hang.

Try to mount it with a paketsize of 1024 or 2048 - because it is a PC so don't expect a fast RPC implementation ;-)

[Francois Rabe]

Hi guys, thanks for the replies so far. I will get the customer to re-mount with the bigger size and test. In the mean time I have discovered by using sysman and then looking at the NFS confiuration that NFS is NOT configured on ANY of the systems - It says "NFS not configured"...Although the NFS I/O daemon says "running", I believe it is reporting the server side of things. How it is working at all on 2 systems, I have no idea, but I have asked the customer to first configure the NFS properly as a CLIENT, on one of the systems that doesn't work and test. I believe this is the problem - NFS that is not configured.

[Ralf Puchner]

If you have mounted the filesystem without any problem, how should your answer match the "not configured" issue?

Btw. it is not a "bigger" size, the PC side is too slow so it must be lowered ;-)

[Francois Rabe]

The cluster was running V5.1A on 4 x GS80's. As the client had bought 3 x GS1280's the O/S had to be upgraded to 5.1B. The new systems were introduced to the cluster and the old ones removed. Since then the SAP application will only copy and create files on the old systems and NOT on the new systems. They stop the application on the GS80 and then restart it on one of the GS1280's. We have exstensively tested the nfs manually on ALL the members and it works fine from within Tru64 Unix - copy,create chmod, edit, etc to the server, which is an NT box.

Could anybody shed some light on this?
Could it be a SAP problem?
Does anybody know if there is a patch? Should something in SAP have been upgraded when they went from 5.1A to 5.1B?

Any suggestions will be welcome.

[Ralf Puchner]

It sound like a "overrun" problem. Is problem gone after lowering rsize,wsize parameter on Tru64 side?

Older windows-versions like NT do not support all RFC and are not multithreading capable.