[Samba] Share access permission errors after upgrade from 4.12.14
unraidster
unraidster at protonmail.com
Thu Jan 25 09:01:11 UTC 2024
On Wednesday, 24 January 2024 at 20:45, Rowland Penny via samba <samba at lists.samba.org> wrote:
> 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
Hi Rowland,
Thanks for the info on the idmap setting. My last lab configuration was using the broader RID range for the TESTLAB domain. Should I be able to change the default domain and add an AD Domain's idmap after initial configuration or should I "disjoin" the domain and rejoin with the updated configuration? I included a summary of my idmap change approach in the previous email in case the detail is required and have not disjoined the domain in that approach.
For my next test I used an earlier snapshot of my configuration in Unraid 6.9.2 and updated the IDMAP to use the range you recommended along with the additions to smb-extras.conf to that change the default smb.conf (that is configured by unraid) to match your recommended settings. Please find the contents of the smb-extras.conf file and the output from testparm below (captured using unraid 6.9.2):
=======================================================
Smb-extras.conf (an include within smb.conf)
root at UR-Lab:~# cat /boot/config/smb-extra.conf
ntlm auth = ntlmv2-only
server min protocol = SMB2_02
host msdfs = yes
ldap ssl = start tls
max open files = 16384
multicast dns register = yes
os level = 20
server multi channel support = yes
acl allow execute always = no
aio read size = 1
aio write size = 1
dos filemode = no
inherit acls = no
inherit permissions = no
null passwords = no
vfs objects = acl_xattr
acl group control = no
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config TESTLAB : backend = rid
idmap config TESTLAB : range = 10000-999999
Testparm (run in unraid 6.9.2):
root at UR-Lab:~# testparm
Load smb config files from /etc/samba/smb.conf
WARNING: The "null passwords" option is deprecated
WARNING: The "null passwords" option is deprecated
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
# Global parameters
[global]
disable spoolss = Yes
load printers = No
logging = syslog at 0
max open files = 16384
printcap name = /dev/null
realm = TESTLAB.COM
security = ADS
server multi channel support = Yes
server string = Media server
show add printer wizard = No
unix extensions = No
winbind use default domain = Yes
workgroup = TESTLAB
idmap config testlab : range = 10000-999999
idmap config testlab : backend = rid
idmap config * : range = 3000-7999
idmap config * : backend = tdb
hide dot files = No
include = /etc/samba/smb-shares.conf
invalid users = root
map acl inherit = Yes
map archive = No
use sendfile = Yes
vfs objects = acl_xattr
wide links = Yes
[flash]
comment = Unraid OS boot device
force user = root
guest ok = Yes
map readonly = yes
path = /boot
read only = No
[PrivateShare]
path = /mnt/user/PrivateShare
read only = No
[PrivateShare-A]
path = /mnt/user/PrivateShare-A
read only = No
[PrivateShare-B]
path = /mnt/user/PrivateShare-B
read only = No
[PublicShare]
path = /mnt/user/PublicShare
read only = No
=======================================================
Post idmap update, I followed the same process I did previously and took ownership of the share folder and set the ACL. This was all done on Unraid 6.9.2 and I confirmed shared access is functional. I then updated the system to Unraid 6.12.6 and share access stops with the same error. Note the uid and group ids reflect numbers from the lower range used in the idmap config.
Error:
Jan 25 00:01:22 UR-Lab smbd[9689]: [2024/01/25 00:01:22.344606, 0] ../../source3/smbd/smb2_service.c:168(chdir_current_service)
Jan 25 00:01:22 UR-Lab smbd[9689]: chdir_current_service: vfs_ChDir(/mnt/user/PrivateShare) failed: Permission denied. Current token: uid=11106, gid=10513, 11 groups: 11106 10513 11119 11111 11115 11113 11124 3003 3004 3006 3001
For consistency, I have included the output from testparm (run in Unraid 6.12.6) below:
=======================================================
root at UR-Lab:~# testparm
Load smb config files from /etc/samba/smb.conf
lpcfg_do_global_parameter: WARNING: The "null passwords" option is deprecated
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 spoolss = Yes
interfaces = 192.168.66.4 127.0.0.1
load printers = No
logging = syslog at 0
max open files = 16384
printcap name = /dev/null
realm = TESTLAB.COM
security = ADS
server string = Media server
show add printer wizard = No
smb1 unix extensions = No
winbind use default domain = Yes
workgroup = TESTLAB
idmap config testlab : range = 10000-999999
idmap config testlab : backend = rid
fruit:nfs_aces = No
idmap config * : range = 3000-7999
idmap config * : backend = tdb
hide dot files = No
include = /etc/samba/smb-shares.conf
invalid users = root
map acl inherit = Yes
use sendfile = Yes
vfs objects = acl_xattr
wide links = Yes
[PrivateShare]
path = /mnt/user/PrivateShare
read only = No
[PrivateShare-A]
path = /mnt/user/PrivateShare-A
read only = No
[PrivateShare-B]
path = /mnt/user/PrivateShare-B
read only = No
[PublicShare]
path = /mnt/user/PublicShare
read only = No
=======================================================
Here are some differences in the testparm output between this lab's Unraid 6.9.2 (working) and 6.12.6 (not working) configurations:
• (added in 6.12.6) "bind interfaces only = Yes" - Note: the man page lists this having a default value of no.
• (added in 6.12.6) "interfaces = 192.168.66.4 127.0.0.1" - Note: Man page says this default value is blank.
• (removed from 6.12.6) "server multi channel support = Yes" - Note: option was made yes by default from 4.15, hence disappeared from testparm output.
• (added in 6.12.6) "fruit:nfs_aces = No"
• (removed from 6.12.6) "map archive = No" - Note: The default value is yes, seems to be set to default in 6.12.16.
I don’t think any of the differences I highlighted would cause the error. I did try setting fruit:nfs_aces to yes, but it did not fix the issue.
In summary, I hope that I have modified the default smb.conf (by way of the smb-extra.conf file) into a configuration that is closer to your recommended one, including using a RID idmap for the domain. The permissions have been reconfigured and tested as working in Unraid 6.9.2 (which runs samba 4.12.14). However, after the upgrade to Unraid 6.12.6 (which runs samba 4.17.12) I start to get the error in the syslog. I'll continue to have a think about anything else I can troubleshoot or try but would appreciate any other recommendations if any are available. My current objective is to get the configuration to a state where the principals listed in the ACL are able to access the shared folders using their respective ACE's permission. I expect I will need to refine/harden the configuration after I have reached that objective.
Thank You!
Unraidster
More information about the samba
mailing list