Groupwise Problems Solved

[Peter Stoddard]

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 at 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