[Samba] Share access error

[Luis Peromarta]

Folks,

I have a contingency server (member server) in an installation. All the data is daily replicated via rsync -AXa.

The member server is a KVM guest with shared folders from host (/home and /home2), online only for testing. Usually the contingency server is shut down. The rsync replication is done by the host. The contingency server is properly joint to the domain, everything seems to be fine from the configuration point of view.

There’s basically 2 shares. One named “personales” that holds home folders, and another share called “shares” that hold group shares.

Both shares have a “every one - full control” setting on the computer management share permissions for both servers.

Both servers (main and contingency) have the exact same smb.conf (except for the netbios name)



smb.conf is:

[global]
       security = ADS
       workgroup = MAD
       realm = MAD.MATER.INT
       netbios name = SERVER	*** The other server has a different name***
       log file = /var/log/samba/%m.log

# To enable Group Policy application in winbind,
	apply group policies = yes

# Configure Samba to Work Better with Mac OS X
	min protocol = SMB2
	ea support = yes
	vfs objects = fruit streams_xattr
	fruit:aapl = yes
	fruit:metadata = stream
	fruit:model = RackMac
	fruit:posix_rename = yes
	fruit:veto_appledouble = yes
	fruit:wipe_intentionally_left_blank_rfork = yes
	fruit:delete_empty_adfiles = yes

       # Default ID mapping configuration for local BUILTIN accounts

	idmap config * : backend = tdb
	idmap config * : range = 3000-7999

	# idmap config for the MAD domain

	idmap config MAD:backend = ad
	idmap config MAD:schema_mode = rfc2307
	idmap config MAD:range = 10000-999999

	# winbind config:

	winbind nss info = rfc2307
	winbind use default domain = yes
#	winbind enum users = yes
#	winbind enum groups = yes

	# renew the kerberos ticket

	winbind refresh tickets = Yes
	dedicated keytab file = /etc/krb5.keytab
	kerberos method = secrets and keytab
#	username map = /etc/samba/user.map

	# To configure shares using extended access control lists (ACL)
	vfs objects = acl_xattr
	map acl inherit = yes
	store dos attributes = yes

	# Veto Files
        veto files = /Thumbs.db/.DS_Store/._.DS_Store/.com.apple*/.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/. at __thumb/. at __desc/:2e*/$
        delete veto files = yes

[personales]
	path = /home/users/
	read only = no
	hide unreadable = yes
	hide unwriteable files = yes
#	browseable = no

[shares]
	path = /home2/shares/
	read only = no
	hide unreadable = yes
	hide unwriteable files = yes


I use one non admin user for testing. This user has his own home folder, and then permissions to access several group folders. This user has no problem accessing all files relevant to him in the main server.

When I try to access the contingency server, the user has no problem accessing his home folder via “personales” share, but can not access the “shares” share, and thus he can not access any group folder.

Another domain admin user can access this “shares” share.

The error reported by the contingency server is:

[2022/12/10 11:33:47.149660,  0] ../../source3/smbd/service.c:166(chdir_current_service)
  chdir_current_service: vfs_ChDir(/home2/shares) failed: Permission denied. Current token: uid=11252, gid=10000, 15 groups: 10000 10008 10003 10005 10030 10024 10021 10022 10001 10018 10014 3003 3004 3006 3001

I have checked with the Domain Admin user, and windows  ACLs and they are exact same in both servers.

I have checked the linux XATTRs and this is what I get:

server:/home2# getfattr -n user.SAMBA_PAI shares
# file: shares
user.SAMBA_PAI=0sAgScBgAFAAABFycAAAAAFScAAAAC/////wAAFScAAAABFycAAAIBECcAAAAAFScAAAAC/////wABFycAAAAAFScAAAMBFycAAA==

root at servercont:/home2# getfattr -n user.SAMBA_PAI shares
# file: shares
user.SAMBA_PAI=0sAgScBgAFAAABFycAAAAAFScAAAAC/////wAAFScAAAABFycAAAIBECcAAAAAFScAAAAC/////wABFycAAAAAFScAAAMBFycAAA==

They also look the same. I have no idea where to start looking for clues. Any hint appreciated.

All the best,

LP