Hello, boomer,
This is Eric in the HP CIFS Client software lab.
Let's be sure I understand the problem. You can mount, you can do 'ls' of the share, but when you 'cat' files on the share, that fails. Is that correct? That is a curious problem; I do not remember ever having seen it in the lab. Once you have successfully mounted and logged in, cat should work (using -U and -P with cifsmount effects a login, and your output from cifslist confirms the login succeeded).
I suggest the following troubleshooting steps to try to isolate the problem:
1. First verify that the files you are trying to cat are not binary files. A binary file might not contain printable characters, or could contain an escape sequence that causes a reset on the client.
2. If you have modified cifsclient.cfg, save it with another name, copy cifsclient.cfg.default to cifsclient.cfg, restart the cifsclient, and see if the problem goes away. My motivation for this suggestion is that you may have configured an invalid character mapping file for your system, or a Unicode setting that is incompatible with the server. If this does not fix it, look in cifsclient.cfg at the settings for caseConvertFile, clientCharMapFile, and serverCharMapFile, and ensure those files exist on your system. You could also run 'swverify B8724AA' to ensure these map files have not been corrupted. If the files are missing or you get an error from swverify, download the latest CIFS Client bundle from software.hp.com and reinstall (you do not need to remove the existing installation before reinstalling). Reinstallation may cause a reboot.
3. I none of the previous steps work, try mounting a share on another server. If the cat succeeds, that could indicate a permission problem on the first server, or some other type of incompatibility between the client and server. If the cat fails, then the problem is most likely on the CIFS Client.
4. Try creating another share on the problem server, and see if cat works on that share. If it does, that would be an even stronger suggestion of a permission problem on the first share.
5. Post your results here. If you cannot isolate the problem using these steps (or maybe some better troubleshooting techniques you devise), then the best bet is to file a support call with HP. They can advise you on how to enable the appropriate log levels in the CIFS Client, and from the logs we should be able to deduce the problem. They may even be able to diagnose a server problem without going through CIFS Client logging procedures.
Finally, are you familiar with any LAN tracing utilities, such as nettl, tcpdump, or ethereal? If the CIFS Client log does not help us, we may need to see a network trace. Support can help you install and run one of these tools.
Keep in touch; I am really curious about this.
-Eric
P.S. SEP, it is unadvisable to create a user named "root" on a Windows server. I believe we have a warning about this somewhere in the Admin Guide for the CIFS Client. The problem is, if the Windows and HP-UX systems have different individuals as administrators, and PAM-NTLM is used such that the Windows system performs authentication for the HP-UX system, then the administrator of the Windows system can become root on the HP-UX system, and change the root password, or do any other misdeed that comes to mind.
