Environment
Novell GroupWise 6.5
Novell GroupWise 7
ConsoleOne with GroupWise snapins
Situation
Time-by-time there is a situation when GroupWise domain database is locked by a workstation running ConsoleOne so other administrators cannot connect to that domain.
Occasionally there can be a case when the domain database gets corrupted due to administration from a workstation by the ConsoleOne.
Resolution
Recommended settings for the Novell client:
- Right-click on red N letter in a right corner of the system tray and select "Novell Client properties ..."
- Click on Advance settings.
- Scroll down and find "File Caching" item -> set it to Off.
- Scroll down and find "File Caching on Exclusively opened files" -> set it to Off.
- Scroll down and find "File Commit" -> set it to On
- If asked, reboot the workstation.
When GroupWise is located on OES Linux server and volumes are NCP aware, then it is advisable to:
- type ncpcon inside a terminal window
- type set cross_protocol_locks = 1 ... this settings enables OES Linux to honor advisory locks across different protocols
- edit the ncpserv.conf file located in /etc/opt/novell directory and add similar statement like in following example for each NCP volume:
VOLUME MAIL /opt/novell/groupwise/mail Inherit_POSIX_Permissions
Additional Information
It has been found that the 3rd point of recommendations (Inherit_POSIX_Permissions) might cause problems in case of cluster enabled NSS volumes as described in the TID 7000228: Cluster volume does not mount due to "failure reason = 22" or "failure reason = 17". Shall you run into these problems, please follow steps bellow:
1. Comment this line out of the ncpserv.conf, if it exists.
2. Offline the cluster resource.
3. Do a "cluster leave" to exit the cluster.
4. Restart edirectory with "rcndsd restart". This will clear the NCP cache that holds the bad volume information.
5. Then join the cluster again with "cluster join".
6. Then online the cluster resource with "cluster online RESOURCENAME"
This error on a volume with the option enabled is most likely caused by a fact that the volume name is already in use in the NCP cache. This setting is not causing any problems on "ordinary" NSS volumes, only in case of cluster enabled ones.