[Samba] old ACL on member server

[Nicolas Canonne]

Hi Rowland,

Sorry for the very long feed-back and thanks for your answers

Issue was well with permissions on shares.

New shares folders have be created with "SMB\Administrator":"SMB\domain 
users" permissions

Then, old shared files have been copied to the new shares via Windows 
client running Administrator account.

Permissions on new shares are then valid.

The trick is well to copy files, hoping this will help others.

Nicolas

Electronico
NEW-CALEDONIA (South Pacific)

Le 01/10/2022 à 18:17, Rowland Penny via samba a écrit :
>
>
> On 30/09/2022 22:59, electronico via samba wrote:
>
>>
>>
>>
>> FS
>> [global]
>>          security = ADS
>>          workgroup = SMB
>>          realm = SMB.RDK.NC
>>
>>          log file = /var/log/samba/%m.log
>>          log level = 1
>>
>>          # Default ID mapping configuration using the autorid
>>          # idmap backend. This will work out of the box for simple 
>> setups
>>          # as well as complex setups with trusted domains.
>>          idmap config * : backend = autorid
>>          idmap config * : range = 10000-9999999
>>
>>          vfs objects = acl_xattr
>>          map acl inherit = yes
>>          # the next line is only required on Samba versions less than 
>> 4.9.0
>>          # store dos attributes = yes
>>
>>          bind interfaces only = yes
>>          interfaces = lo br0
>>
>>          winbind enum users = yes
>>          winbind enum groups = yes
>
> I suggest that once you get everything working correctly, you remove 
> the two 'winbind enum' lines, you do not need them.
>
>>
>> [Profiles]
>>          path = /media/data/Profiles/
>>          read only = no
>>          #browseable = No
>>          read only = No
>>          csc policy = disable
>>          vfs objects = acl_xattr
>
> You do not need the 'vfs objects' line, it is in 'global'
>
>>
>>
>>>
>>> How did you copy the files to the new Unix domain member ?
>>
>> The old all-in-one DC+FS had shares on physical drives, so they 
>> haven't been moved.
>> (DC+FS) became FS only
>>>
>>>
>>
>> Oops : it is 3 000 000 range, sorry.
>>
>> FS
>> getent passwd
>> SMB\regie:*:111115:110513:regie:/home/SMB/regie:/bin/false
>> SMB\serveur:*:111108:110513::/home/SMB/serveur:/bin/false
>> SMB\guest:*:110501:110513::/home/SMB/guest:/bin/false
>> SMB\krbtgt:*:110502:110513::/home/SMB/krbtgt:/bin/false
>> SMB\administrator:*:110500:110513::/home/SMB/administrator:/bin/false
>>
>> getent group
>> SMB\read-only domain controllers:x:110521:
>> SMB\dnsupdateproxy:x:111102:
>> SMB\unix admins:x:111116:
>> SMB\domain users:x:110513:
>> SMB\enterprise admins:x:110519:
>> SMB\enterprise read-only domain controllers:x:110498:
>> SMB\dnsadmins:x:111101:
>> SMB\denied rodc password replication group:x:110572:
>> SMB\domain admins:x:110512:
>> SMB\schema admins:x:110518:
>> SMB\group policy creator owners:x:110520:
>> SMB\allowed rodc password replication group:x:110571:
>> SMB\ras and ias servers:x:110553:
>> SMB\domain controllers:x:110516:
>> SMB\domain guests:x:110514:
>> SMB\domain computers:x:110515:
>> SMB\cert publishers:x:110517:
>>
>> reading ACLs on an touched folder (previousely shared by the 
>> all-in-one DC+FS
>> getfacl /media/data/jingles
>> getfacl : suppression du premier « / » des noms de chemins absolus
>> # file: media/data/jingles
>> # owner: root
>> # group: users
>> user::rwx
>> user:root:rwx
>> user:3000040:rwx
>> user:3000041:r-x
>> group::rwx
>> group:users:rwx
>> group:3000040:rwx
>> group:3000041:r-x
>> mask::rwx
>> other::---
>> default:user::rwx
>> default:user:root:rwx
>> default:user:3000040:rwx
>> default:user:3000041:r-x
>> default:group::rwx
>> default:group:users:r-x
>> default:group:3000040:rwx
>> default:group:3000041:r-x
>> default:mask::rwx
>> default:other::---
>>
>
> As I said, the numbers in the 3000000 range are only used on a DC and 
> Are stored in idmap.ldb, but there is a bit of a gotcha, they are 
> allocated on a 'first come' basis, a user cannot expect to get the 
> same ID number on a different Samba AD DC, which is why you have to 
> sync idmap.ldb from the first DC to all other DC's when syncing Sysvol.
>
> So, whilst your files haven't moved, the owners have and on your new 
> fileserver, they have a different ID number in the 110000 range. 
> Luckily you appear to have very few users, you will need to identify 
> who '3000040' and '3000041' etc are and 'chown' the files and 
> directories, but you cannot rely on your new DC giving the right answers.
>
> Rowland
>