Matyt problema turiu kita, nes panasu, kad nuo 3.0.23 versijos grupiu 
mapinimas yra nebutinas. Is tikro VIDAS prisijunge be mapinimo, kuri as 
buvau isdeletines. Cia pridedu ilga teksta:

User and Group changes
======================

The user and group internal management routines have been
rewritten to prevent overlaps of assigned Relative Identifiers
(RIDs). In the past the has been a potential problem when either
manually mapping Unix groups with the 'net groupmap' command or
when migrating a Windows domain to a Samba domain using 'net rpc
vampire'.

Unmapped users are now assigned a SID in the S-1-22-1 domain and
unmapped groups are assigned a SID in the S-1-22-2 domain.
Previously they were assign a RID within the SAM on the Samba
server. For a DC this would have been under the authority of the
domain SID where as on a member server or standalone host, this
would have been under the authority of the local SAM (hint: net
getlocalsid).

The result is that any unmapped users or groups on an upgraded
Samba domain controller may be assigned a new SID. Because the
SID rather than a name is stored in Windows security descriptors,
this can cause a user to no longer have access to a resource for
example if a file was copied from a Samba file server to a local
NTFS partition. Any files stored on the Samba server itself will
continue to be accessible because Unix stores the Unix gid and not
the SID for authorization checks.

A further example will help illustrate the change. Assume that a
group named 'developers' exists with a Unix gid of 782 but this
user does not exist in Samba's group mapping table. it would be
perfectly normal for this group to be appear in an ACL editor.
Prior to 3.0.23, the group SID might appear as
S-1-5-21-647511796-4126122067-3123570092-2565. With 3.0.23, the
group SID would be reported as S-1-22-2-782. Any security
descriptors associated with files stored on an NTFS disk partition
would not allow access based on the group permissions if the user
was not a member of the
S-1-5-21-647511796-4126122067-3123570092-2565 group. Because this
group SID not reported in a user's token is S-1-22-2-782, Windows
would fail the authorization check even though both SIDs in some
respect referred to the same Unix group.

The current workaround is to create a manual domain group mapping
entry for the group 'developers' to point at the
S-1-5-21-647511796-4126122067-3123570092-2565 SID.