Bug 1197875

Summary: CIFS DFS shares fail to mount when specifying sec= option
Product: Red Hat Enterprise Linux 6 Reporter: Ryan Crews <rcrews>
Component: kernelAssignee: Sachin Prabhu <sprabhu>
kernel sub component: CIFS QA Contact: xiaoli feng <xifeng>
Status: CLOSED ERRATA Docs Contact: Jana Heves <jsvarova>
Severity: medium    
Priority: urgent CC: cww, dwysocha, eguan, hbarcomb, jsvarova, kcleveng, martin.moore, salmy, sprabhu, swhiteho
Version: 6.6   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-2.6.32-582.el6 Doc Type: Bug Fix
Doc Text:
Automatic signing is now enabled When setting a security type with the "sec=" mount option and no signing had been specified with the trailing "i", automatic signing was not previously enabled. For example, in DFS mounts where the DFS node requires signing but the client had disabled it using "sec=", the user could not mount the DFS node if the node required signing to be enabled. The provided fix sets `MAY_SIGN` flags for all security types, thus fixing this bug.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-10 22:11:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1172231, 1268411    

Description Ryan Crews 2015-03-02 20:30:44 UTC
Description of problem:
Attempting to mount a DFS CIFS share with mount.cifs fails with "mount error(95): Operation not supported" when using the sec= mount option.

Version-Release number of selected component (if applicable):
Tested: 2.6.32-431.1.2.el6.x86_64 & 2.6.32-504.8.1.el6.x86_64
cifs-utils: cifs-utils-4.8.1-19.el6.x86_64

How reproducible: 100%

Steps to Reproduce:
1. Attempt to mount a CIFS DFS share with any security mode.
# mount -o sec=ntlmssp,username=user,domain=domain //kasane.local/neet /neet

Actual results: Error 95
[root@nayuki ~]# mount.cifs -o sec=ntlm,username=teto,domain=kasane //kasane.local/neet /neet
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Expected results: Success (no error)


Additional info: Node can be mounted directly, or DFS share can be mounted without sec option:
[root@nayuki ~]# mount.cifs -o username=teto,domain=kasane '//kasane.local/neet/triplebaka' /neet/
[root@nayuki ~]# grep cifs /proc/mounts 
//kasane.local/neet/triplebaka /neet cifs rw,relatime,sec=ntlm,cache=loose,unc=\134\134neru\134triplebaka,username=teto,domain=kasane,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.122.101,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1 0 0
[root@nayuki ~]# 

Direct to node, bypassing DFS:
[root@nayuki ~]# mount.cifs -o sec=ntlmssp,username=teto,domain=kasane '//neru/triplebaka' /neet/
[root@nayuki ~]# ls /neet/
install.log
[root@nayuki ~]# grep cifs /proc/mounts 
//neru/triplebaka/ /neet cifs rw,relatime,sec=ntlmssp,cache=loose,unc=\134\134neru\134triplebaka,username=teto,domain=kasane,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.122.101,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1 0 0

A network trace shows that nothing occurs after:
53	8.243534	192.168.122.100	192.168.122.16	SMB	148	Negotiate Protocol Request
54	8.244503	192.168.122.16	192.168.122.100	SMB	275	Negotiate Protocol Response

Comment 1 Ryan Crews 2015-03-02 21:00:23 UTC
Also tested this on 2.6.32-279.el6.x86_64 with cifs-utils-4.4-5.el6.x86_64:

[root@nayuki ~]# mount.cifs -o sec=ntlmssp,username=administrator,domain=kasane '//kasane.local/neet/triplebaka' /neet/
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
[root@nayuki ~]# rpm -q cifs-utils
cifs-utils-4.4-5.el6.x86_64
[root@nayuki ~]# uname -r
2.6.32-279.el6.x86_64

root@nayuki ~]# mount.cifs -o username=administrator,domain=kasane '//kasane.local/neet/triplebaka' /neet/
[root@nayuki ~]# echo success!

Comment 2 Ryan Crews 2015-03-02 21:07:47 UTC
I suspect this could be relevant to how packet signing is handled, as these messages appear in the system logs:

Mar  2 16:02:13 nayuki kernel: CIFS VFS: signing required but server lacks support
Mar  2 16:02:13 nayuki kernel: CIFS VFS: cifs_mount failed w/return code = -95
Mar  2 16:02:19 nayuki kernel: CIFS VFS: Server requires packet signing to be enabled in /proc/fs/cifs/SecurityFlags.
Mar  2 16:02:19 nayuki kernel: CIFS VFS: cifs_mount failed w/return code = -95

These are for the following mount attempts:
[root@nayuki ~]# mount.cifs -o sec=ntlmi,username=teto,domain=kasane '//kasane.local/neet/triplebaka' /neet/
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
[root@nayuki ~]# mount.cifs -o sec=ntlm,username=teto,domain=kasane '//kasane.local/neet/triplebaka' /neet/
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

In this case, the server is Windows 2008 R2. Please let me know if any other data would be helpful.

[root@nayuki ~]# smbclient -L //haku.kasane.local -U kasane/teto
Enter kasane/teto's password: 
Domain=[KASANE] OS=[Windows Server 2008 R2 Standard 7600] Server=[Windows Server 2008 R2 Standard 6.1]

	Sharename       Type      Comment
	---------       ----      -------
	ADMIN$          Disk      Remote Admin
	C$              Disk      Default share
	IPC$            IPC       Remote IPC
	neet            Disk      
	NETLOGON        Disk      Logon server share 
	orz             Disk      
	SYSVOL          Disk      Logon server share 
session request to HAKU.KASANE.LOCA failed (Called name not present)
Domain=[KASANE] OS=[Windows Server 2008 R2 Standard 7600] Server=[Windows Server 2008 R2 Standard 6.1]

	Server               Comment
	---------            -------

	Workgroup            Master
	---------            -------

Comment 19 Aristeu Rozanski 2015-10-20 19:08:54 UTC
Patch(es) available on kernel-2.6.32-582.el6

Comment 24 errata-xmlrpc 2016-05-10 22:11:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-0855.html