Solaris 10 NFS caching problems with custom NFS server

Question

I'm facing a very strange problem with a pure java standalone application providing NFS server v2 service. This same application, targeted for JVM 1.4.2 is running on different environment (see below) without any problem.
On Solaris 10 we try any kind of mount parameters, system services up/down configuration, but cannot solve the problem.
We're in big trouble 'cause the app is a mandatory component for a product to be in production stage in a while.
Details follows
System description
Sunsparc U4 with SunOS 5.10, patch level: Generic_118833-33, 64bit
List of active NFS services
disabled   svc:/network/nfs/cbd:default
disabled   svc:/network/nfs/mapid:default
disabled   svc:/network/nfs/client:default
disabled   svc:/network/nfs/server:default
disabled   svc:/network/nfs/rquota:default
online       svc:/network/nfs/status:default
online       svc:/network/nfs/nlockmgr:default
NFS mount params (from /etc/vfstab)
localhost:/VDD_Server  - /users/vdd/mnt nfs - vers=2,proto=tcp,timeo=600,wsize=8192,rsize=8192,port=1579,noxattr,soft,intr,noac
Anomaly description
The server side of NFS is provided by a java standalone application enabled only for NFS v2 and tested on different environments like: MS Windows 2000, 2003, XP, Linux RedHat 10 32bit, Linux Debian 2.6.x 64bit, SunOS 5.9. The java application is distributed with a test program (java standalone application) to validate main installation and configuration.
The test program simply reads a file from the NFS file-system exported by our main application (called VDD) and writes the same file with a different name on the VDD exported file-system. At end of test, the written file have different contents from the read one. Indeep investigation shows following behaviuor:
_ The read phase behaves correctly on both server (VDD) and client (test app) sides, trasporting the file with correct contents.
_ The write phase produces a zero filled file for 90% of resulting VDD file-system file but ending correctly with the same sequence of bytes as the original read file.
_ Detailed write phase behaviour:
1_ Test app wites first 512 bytes => VDD receive NFS command with offset 0, count 512 and correct bytes contents;
2_ Test app writes next 512 bytes => VDD receive NFS command with offset 0, count 1024 and WRONG bytes contents: the first 512 bytes are zero filled (previous write) and last 512 bytes with correct bytes contents (current write).
3_ Test app writes next 512 bytes => VDD receive NFS command with offset 0, count 1536 and WRONG bytes contents: the first 1024 bytes are zero filled (previous writes) and last 512 bytes with correct bytes contents (current write).
4_ and so on...
Further tests
We tested our VDD application on the same Solaris 10 system but with our test application on another (Linux) machine, contacting VDD via Linux NFS client, and we don�t see the wrong behaviour: our test program performed ok and written file has same contents as read one.
Has anyone faced a similar problem?
We are Sun ISV partner: do you think we have enough info to open a bug request to SDN?
Any suggestions?
Many thanks in advance,
Maurizio.

Answer 1

I finally got it working. I think my problem was that I was coping and pasting the /etc/pam.conf from Gary's guide into the pam.conf file.
There was unseen carriage returns mucking things up. So following a combination of the two docs worked. Starting with:
http://web.singnet.com.sg/~garyttt/Configuring%20Solaris%20Native%20LDAP%20Client%20for%20Fedora%20Directory%20Server.htm
Then following the steps at "Authentication Option #1: LDAP PAM configuration " from this doc:
http://docs.lucidinteractive.ca/index.php/Solaris_LDAP_client_with_OpenLDAP_server
for the pam.conf, got things working.
Note: ensure that your user has the shadowAccount value set in the objectClass