Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Networking
cancel
Showing results for 
Search instead for 
Did you mean: 

nouser, nobody with SFU3.5 although using explicit mapping

Frank Zumkeller
Occasional Visitor

nouser, nobody with SFU3.5 although using explicit mapping

On a HP ProLiant DL380 G5 Storage Server with a preconfigured Windows Storageserver 2003 we have an installation of „Services for UNIX 3.5“ (SFU) including all components.
On the site there is a Windows 2003 Domain and HP UX servers with NIS.
We have configured an explicit mapping of users: each user out of the Active Directory is mapped to the appropriate UID of the user in NIS.
However, the access rights to files and directories in the windows environment are represented on the UNIX side as such, that “ls –l” shows “nobody” for the particular user and “nogroup” for the group with rights “755”, i.e. the explicit mapping has no effect in that direction.
On the other side, if the access right to a file/directory is configured from Unix, it is represented correctly in the windows environment.

A further problem:
If I try to open a file with vi with a useraccount that does not have the correctly assigned rights (nobody/nogroup, see above), the process hangs on the HP UX server and the is no way to kill it. Furthermore the HP Proliant DL380 G5 Storage Server enters a bluescreen with errorcode 0x0000007E in nfssrv.exe. Since the UNIX process hangs, the storage server is in a loop and reboots every few minutes. Only remedy is a separation of the server from the network.
For this errorcode I have found a knowledgebase article KB918245 from Microsoft and requested a hotfix, but unfortunately it does not put things right. We had to open a call within the scope of a SA, nevertheless Microsoft recommitted us to the OEM HP.
Since also HP did not announce a solution as yet, I herewith ask for a recommendation, if the problem is known or if there is a solution.