We had a problem with Samba and our Groupwise mail user agent, which we have now fixed. I am posting the fix in case others have the same problem. We run Samba on a number of SUN sparc servers (Solaris 2.6), each mounting the Groupwise directory from the remote Groupwise mailhost named hermes: /hermes/gwpo/empm_po on hermes:/gwpo/empm_po bg/actimeo=0/remote Clients used to connect to a service called Groupwis: [Groupwis] comment = Groupwise post office path = /hermes/gwpo/empm_po read only = no public = yes Using Samba 1.9.17.p4, we found that clients (Windows 3.x and NT) opening their mail using Groupwise could not update their mail boxes. If they opened mail, it would appear unopened, and deleted items would not go away. However, if clients disconnected and reconnected the Groupwis service, the changes they had tried to make to their mailboxes would be seen: opened mail would appear as opened, and deleted items would go away, etc. We solved this problem by setting "alternate permissions = yes" in the global area. Then when we upgraded to Samba 1.9.18, the same symptoms appeared. We solved them by disabling the oplocks (oplocks = no). This works either when the oplocks statement is placed in the in the global area or in the Groupwis service area. Interestingly, the fake oplocks = yes option also breaks Groupwise. In sum, we now run Samba 1.9.18.p4 successfully with alternate permissions = yes in the global area and the following for Groupwise service: [Groupwis] comment = Groupwise post office path = /hermes/gwpo/empm_po read only = no public = yes oplocks = no Peter Stoddard <stoddard@empm.cdpr.ca.gov> System Administrator Environmental Monitoring and Pest Management Branch California Department of Pesticide Regulation (916) 730-0490, (916) 324-4168 or (916) 324-4078