Hi,

you can compare the mapping between the 2 clusters:

/usr/lpp/mmfs/bin/net idmap dump | grep RANGE | sort

We had an issue when migrating from Samba to CES, our domain had to be first 
(before ALLOC) to have the same uid mappings. We changed the order by deleting 
them and adding them in the correct order:

/usr/lpp/mmfs/bin/net idmap delete range 0
/usr/lpp/mmfs/bin/net idmap delete range 1
/usr/lpp/mmfs/bin/net idmap delete range 2

/usr/lpp/mmfs/bin/net idmap set range 0 S-1-5-.........
/usr/lpp/mmfs/bin/net idmap set range 1 ALLOC
/usr/lpp/mmfs/bin/net idmap set range 2 S-1-.........

kind regards
Pieter Adams


On 20/03/2023 13:52, Laurence Horrocks-Barlow wrote:

U ontvangt niet vaak e-mail van 
[email protected]<mailto:[email protected]>. Meer informatie over waarom 
dit belangrijk is<https://aka.ms/LearnAboutSenderIdentification>

Just to confirm, is it just the mapping? Or the actual UID/GID’s being 
different?

Could you provide an example for a file on both sites?

— Lauz

Get BlueMail<https://bluemail.me> for Mobile
Christoph Martin wrote:


Hi list,

we have a cluster running with SMB and NFS service and winbind
userid/groupid mappings. The primary domain takes the userid/groupid
mapping from AD:

ENABLE_NFS_KERBEROS      true
SERVERS                  "*"
USER_NAME                ISS$
NETBIOS_NAME            ISS
IDMAP_ROLE              master
IDMAP_RANGE              10000000-299999999
IDMAP_RANGE_SIZE        10000000<tel:10000000>
UNIXMAP_DOMAINS          UNI-MAINZ(1000-9999999:unix)
LDAPMAP_DOMAINS          none

All trusted domains get automatically mapped to regions over 
10000000<tel:10000000>.

Now we are setting up a second cluster as AFM DR site and want to be
able to use SMB and NFS with the same user mapping. For the primary
domain UNI-MAINZ this is working because of the explicit entries of
uid/gid in AD. But he trusted domains get mapped to different regions of
uids. So we have userid/groupid missmatch between these two clusters.

I think this is because winbind will assign the regions depending on a
first come first serve rule.

Is there a way to get the same mapping on these two clustered?
Can we e.g. copy a smb/binbind tdb database to get the same mapping?

Regards
Christoph

--
Christoph Martin
Zentrum für Datenverarbeitung (ZDV)
Leiter Unix & Cloud

Johannes Gutenberg-Universität Mainz
Anselm Franz von Bentzel-Weg 12, 55128 Mainz<x-apple-data-detectors://4/0>
Tel: +49 6131 39 26337<tel:+49%206131%2039%2026337>
[email protected]<mailto:[email protected]>
www.zdv.uni-mainz.de<http://www.zdv.uni-mainz.de>
Hi list,

we have a cluster running with SMB and NFS service and winbind
userid/groupid mappings. The primary domain takes the userid/groupid
mapping from AD:

ENABLE_NFS_KERBEROS      true
SERVERS                  "*"
USER_NAME                ISS$
NETBIOS_NAME            ISS
IDMAP_ROLE              master
IDMAP_RANGE              10000000-299999999
IDMAP_RANGE_SIZE        10000000<tel:10000000>
UNIXMAP_DOMAINS          UNI-MAINZ(1000-9999999:unix)
LDAPMAP_DOMAINS          none

All trusted domains get automatically mapped to regions over 
10000000<tel:10000000>.

Now we are setting up a second cluster as AFM DR site and want to be
able to use SMB and NFS with the same user mapping. For the primary
domain UNI-MAINZ this is working because of the explicit entries of
uid/gid in AD. But he trusted domains get mapped to different regions of
uids. So we have userid/groupid missmatch between these two clusters.

I think this is because winbind will assign the regions depending on a
first come first serve rule.

Is there a way to get the same mapping on these two clustered?
Can we e.g. copy a smb/binbind tdb database to get the same mapping?

Regards
Christoph

--
Christoph Martin
Zentrum für Datenverarbeitung (ZDV)
Leiter Unix & Cloud

Johannes Gutenberg-Universität Mainz
Anselm Franz von Bentzel-Weg 12, 55128 Mainz<x-apple-data-detectors://9/0>
Tel: +49 6131 39 26337<tel:+49%206131%2039%2026337>
[email protected]<mailto:[email protected]>
www.zdv.uni-mainz.de<http://www.zdv.uni-mainz.de>



_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org



-- Disclaimer --
Vlaamse Radio- en Televisieomroeporganisatie
Auguste Reyerslaan 52
1043 Brussel

nv van publiek recht
BTW BE 0244.142.664
RPR Brussel
VRT Gebruikersvoorwaarden <http://www.vrt.be/gebruiksvoorwaarden>

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org

Reply via email to