Rowland Penny
2024-Jan-24 20:45 UTC
[Samba] Share access permission errors after upgrade from 4.12.14
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 = hashThat 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
unraidster
2024-Jan-25 09:01 UTC
[Samba] Share access permission errors after upgrade from 4.12.14
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. > > RowlandHi 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
Reasonably Related Threads
- Share access permission errors after upgrade from 4.12.14
- Share access permission errors after upgrade from 4.12.14
- Share access permission errors after upgrade from 4.12.14
- Share access permission errors after upgrade from 4.12.14
- Share access permission errors after upgrade from 4.12.14