Bug 15131 - Client access fails to Samba share with NT_STATUS_ACCESS_DENIED. SELINUX issue.
Summary: Client access fails to Samba share with NT_STATUS_ACCESS_DENIED. SELINUX issue.
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.11.17
Hardware: All Linux
: P5 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2022-07-26 14:13 UTC by James Schatzman
Modified: 2022-07-28 12:19 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description James Schatzman 2022-07-26 14:13:44 UTC
We are unable to access private share on Centos 7.9/Samba 4.10 or 4.11. Identically configured SMB share works fine on RHEL 9/Samba 4.15.

Comparing the debug output of smbclient -d9, the only difference (aside from the IP address of the server) between success (Samba 4.15 server) and failure (Sambe 4.10 or 4.11 server) is:

--> Centos 7.9/Samba 4.10 or 4.11 (fails): signed SMB2 message (sign_algo_id=1)
--> RHEL 9 (works): signed SMB2 message (sign_algo_id=2)

The symptoms are that Windows 10 clients cannot access the share, and smbclient (all versions) is unable to access the share, resulting in a message:


Linux client procedure:

command: smbclient -U <user> \\\\host-ip\\share-name
<log in succeeds>
smb: \> dir
smb: \>

The same behavior is observed with Samba servers on multiple Centos 7.9 systems with identical configurations.

An otherwise identical system with RHEL 9 installed and Samba 4.15, with the same user accounts and files, and the same smb.conf file (changing netbios name has no effect on this issue) works fine with Windows 10 and Linux smb clients.

We tried upgrading the Samba server version to 4.11 but no change was observed. We suspect that upgrading to 4.15 would solve the problem, but there does not appear to be support for Samba 4.15 on Centos 7.9.

We are looking for a solution for Centos 7.9 which is still required for multiple commercial applications due to lack of vendor support for more recent OS versions.

Options seem to be

a) Modified smb.conf that fixes the problem?

b) A way to install samba server 4.15 on Centos 7.9?


	workgroup = WGNAME
	server string = Samba Server Version %v
	netbios name = NBNAME
	log file = /var/log/samba/%m.log
	max log size = 1000
	client min protocol = NT1
        hosts allow = 10.2.10. 127.
        smb ports = 445
	security = user
	encrypt passwords = yes
	map to guest = bad user
	guest account = nobody
	guest ok = yes
	client ntlmv2 auth = yes
	domain master = yes
	local master = yes
	preferred master = yes
	os level = 33
	wins support = yes
	name resolve order = host bcast
	dns proxy = no
	wins proxy = no
	load printers = no

        public = yes
	writeable = yes
	guest ok = yes
        available = yes
	read only = no
	create mask = 0755
	directory mask = 0755

Simplified versions behave the same way. For example, eliminating "client min protocol", "os level", multiple guest parameters, has no effect on this problem.
Comment 1 James Schatzman 2022-07-26 14:45:31 UTC
Further testing on Centos 8 Stream system with Samba 4.16.2 also failed.

Current results:

4.10.16-19.el7_9 fails
4.11.17-1.el7  fails
4.16.2-1.el8   fails
4.15.5-108.el9_0 works

This makes me think that maybe the problem is somehow related to RHEL 9 vs Centos 7 or Centos 8 Stream. As far as I can determine, the user account, share directory and permissions, Samba configuration, are identical on the systems.

Login works fine on all systems. Actually accessing the share only works on the RHEL 9 system.
Comment 2 Rowland Penny 2022-07-27 10:45:48 UTC
(In reply to James Schatzman from comment #1)
You could try the samba packages from either Tranquil IT or Samba+
Comment 3 James Schatzman 2022-07-27 13:08:52 UTC
SOLVED: This turned out to be an SELINUX issue. By default, Centos 7-8 Selinux configuration prevents Samba clients from accessing files in /home/*. On RHEL 9, that does not seem to be the case.
Comment 4 James Schatzman 2022-07-27 13:09:40 UTC
It would be helpful if Samba server logged useful information re file access.
Comment 5 Rowland Penny 2022-07-28 12:19:26 UTC
(In reply to James Schatzman from comment #4)
Closing this because it obviously wasn't a Samba problem.