[Samba] Share access permission errors after upgrade from 4.12.14

[Rowland Penny]

On Wed, 24 Jan 2024 17:31:46 +0000
unraidster via samba <samba at lists.samba.org> wrote:


> Hi,
> 
> I assumed that the rearranged config you provided was for feedback,

Yes, they were just comments, but unraid should really fix their Samba
setup.

> I
> haven't made any changes to the configuration based on those
> comments. I'll send a message to the Unraid support team with a link
> to this post when I get to an output with the issue.

Based on the time this has being going on, I wouldn't hold your breath
whilst waiting for a response.

> 
> I have been including outputs from testparm. I assumed that the
> command's output is the configuration that is used by smbd after the
> smb.conf and all included .conf files have been processed, like a
> resultant configuration. Is that correct? (wanted to validate that,
> that is the configuration that I should expect is used by the system
> and there isn't anything in the .conf files that could be modifying
> the configuration). I noticed that if I set a property to the default
> value (as specified in the man pages) that it would disappear from
> the testparm output, I assumed this is because testparm will "filter"
> out any properties with system default value.

Yes, testparm will not print parameters with the 'default' setting, if
you want to see these, use 'testparm -sv'

>
> Output from Testparm:
> 	root at Tower:~# testparm
> 	Load smb config files from /etc/samba/smb.conf
> 	lpcfg_do_global_parameter: WARNING: The "null passwords"
> option is deprecated Loaded services file OK.
> 	Weak crypto is allowed by GnuTLS (e.g. NTLM as a
> compatibility fallback)
> 
> 	Server role: ROLE_DOMAIN_MEMBER
> 
> 	Press enter to see a dump of your service definitions
> 
> 	# Global parameters
> 	[global]
> 		bind interfaces only = Yes
> 		disable netbios = Yes
> 		disable spoolss = Yes
> 		host msdfs = No
> 		interfaces = 192.168.66.10/24 127.0.0.1
> 		ldap ssl = no
> 		load printers = No
> 		logging = syslog at 0
> 		max open files = 40960
> 		multicast dns register = No
> 		ntlm auth = ntlmv1-permitted
> 		null passwords = Yes
> 		printcap name = /dev/null
> 		realm = TESTLAB.COM
> 		security = ADS
> 		server min protocol = SMB2
> 		server multi channel support = No
> 		server string = Media server
> 		show add printer wizard = No
> 		smb1 unix extensions = No
> 		winbind use default domain = Yes
> 		workgroup = TESTLAB
> 		fruit:nfs_aces = No
> 		idmap config * : range = 10000-4000000000
> 		idmap config * : backend = hash

That is what I was looking for, the default 'idmap config' is set to
'hash', which shouldn't be used. Especially as it says 'idmap_hash - DO
NOT USE THIS BACKEND' at the top of 'man idmap_hash'. I can understand
using it for existing systems, but not for new ones.

Lets get this right (and I got it wrong last time, what do you expect,
I would never use idmap_hash, it has problems and the rid backend works
better), the idmap hash backend is used for the default '*' domain and
the main DOMAIN (in your case 'TESTLAB') domain. 

This is a shortened version of 'man idmap_hash':
It uses an hashing algorithm to map SIDs to 31-bit uids and gids. The
module needs the complete UID and GID range to be able to map all SIDs.
The lowest value for the range should be the smallest ID available in the system.
This is normally 1000. The highest ID should be set to 2147483647.
Any range smaller than 0 - 2147483647 will filter some SIDs. As we can
normally only start with 1000, we are not able to map 1000 SIDs. This
already can lead to issues. The smaller the range the less SIDs can ID
= RID - BASE_RID + LOW_RANGE_IDbe mapped.

So, it looks like any users or groups that have a RID less than 10000 are ignored and the '4000000000' high number is pointless. This is on top of the fact that the idmap_hash backend should not be used. 

A better method would be to use the idmap_rid backend:

  idmap config * : backend = tdb
  idmap config * : range = 3000-7999
  idmap config TESTLAB : backend  = rid
  idmap config TESTLAB : range = 10000-999999

This would use an allocating backend for the default '*' domain and set
IDs in the '3000-7999' range (starting from 3000). The default domain
is used for the Well Known SIDs and anything not in the main 'TESTLAB'
domain (which should really mean 0)

The main domain 'TESTLAB' would use the 'rid' idmap backend. This
backend works by calculating the Unix ID from the AD RID and the low
range set in smb.conf:

ID = RID + LOW_RANGE_ID

From the example above and the RID '1000':

ID = 1000 + 10000

ID = 11000

Provide you use the same idmap config on all Unix domain members in the
AD domain, you will always get the same IDs for the 'TESTLAB' domain.

Rowland