Bug 14518

Summary:	Mount of cifs share fails with permission denied
Product:	Mageia	Reporter:	René Poisson <poisson.rene>
Component:	RPM Packages	Assignee:	Thomas Backlund <tmb>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	major
Priority:	Normal	CC:	sysadmin-bugs
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	kernel	CVE:
Status comment:
Attachments:	Wireshark pcap capture of the mount failure

Description René Poisson 2014-11-13 01:19:04 CET

Description of problem:
It is impossible to mount a cifs share from a FREECOM Dual Drive Network NAS with Mageia 5 beta 1. The same share can be mounted uneder Mageia 5.
Included is a Wireshark capture that shows the reason:
- During initial Session Setup and X Request, the NAS returns a User ID of 0x100
- The response being "More processing request", this Id is used by cifs (or is it samba ?) to re-issue the request with required parameters
- At that time the NAS respond chnaging the User ID to $x101 (I did not find any thing in the Microsoft documentation that forbids that to happen)
- But in the in the next command, Tree Connect and X Request, Mageia 5 re-uses the previous client ID of 0x100
- The NAS refuses the connection

I first found the problem with autofs but found out that a manual mount fails the same way.

Version-Release number of selected component (if applicable):
Mageia 5 Beta 1
samba-client-3.6.24-9.mga5
samba-common-3.6.24-9.mga5
cifs-utils-6.4-4.mga5

How reproducible:
Solid error, impossible to mount any share from this NAS.
Shares from Windows 7 machine and Synology DS411 can be mounted, however the client ID is not changed between responses by these devices.

Steps to Reproduce:
1. Mount a cifs share on a FREECOM Dual Drive Network NAS from autofs or manually
2. Directory not found from autofs with return code = -13 in journal file or permission denied for manual mount



Reproducible: 

Steps to Reproduce:

Comment 1 René Poisson 2014-11-13 01:21:17 CET

Created attachment 5594 [details]
Wireshark pcap capture of the mount failure

Packet captured during a failing mount of a NAS cifs share

Comment 2 René Poisson 2014-11-13 01:26:10 CET

Error in initial description:
"The same share can be mounted uneder Mageia 5" is in fact "The same share can be mounted uneder Mageia 4".
Packages used by Mageia 4 are:
samba-common-3.6.24-1.1.mga4
samba-client-3.6.24-1.1.mga4
cifs-utils-6.2-2.1.mga4

Comment 3 David Walser 2014-11-15 00:43:39 CET

Have you checked with lsof to see what process is associated with the socket that is producing incorrect packets?

Have you tried installing the Mageia 4 cifs-utils package to see if it fixes it?  Note that the Mageia 4 samba package is the same as Mageia 5, so it wouldn't be that one.

Have you tried running the Mageia 4 kernel on the Mageia 5 system to see if that fixes it?

Component: Release (media or process) => RPM Packages

Comment 4 René Poisson 2014-11-16 21:52:59 CET

Hi David,

Sorry for the late reply, I have been unavailable that week-end.

I have not been able to downgrade the cifs-utils package on Mageia5-beta1.
I was not able either to install a "Mageia 4" kernel because I used the 
default beta1 partitionning which is far too small (12GB for the / file 
system) to allow for a different kernel compilition (may be I should enter 
an enhancement bug to correct that. Nowadays, with 1TB drives, 12GB for / is 
a bit small ...)

However, I have been able to compile a 3.17.3 kernel (from kernel.org) on a 
Mageia 4 system (with 48GB in / partition).

The "culprit" is, as you probably foresaw, the cifs.ko kernel module. Booted 
on that kernel, the shares on the Freecom device are not mounted anymore.

Mageia 4 kernel comes with version 2.02 which works even if the samba server 
changes the User Id between requests while Mageia 5 comes with cifs version 
2.05 where User Id changes are ignored.

Thank you for your help,

René

Comment 5 David Walser 2014-11-18 05:01:43 CET

Thanks, assigning to the kernel maintainer.  Reporting this upstream to the kernel folks may help too.

Assignee: bugsquad => tmb
Source RPM: (none) => kernel

Comment 6 Samuel Verschelde 2015-05-20 00:32:16 CEST

Is this bug still present in latest cauldron?

Keywords: (none) => NEEDINFO

Comment 7 René Poisson 2015-05-20 18:38:52 CEST

(In reply to Samuel VERSCHELDE from comment #6)
> Is this bug still present in latest cauldron?

Sorry again, I have been away from home for some time for family reasons. I'm only here a few days before I am again  absent for hip surgery and not available for quite a few weeks ...

Anyway, I do not own anymore the device that was changing the User Id between commands so I can't verify with the only NAS I got, which never exhibited the problem.

It is probably safe to close it as not reproducible. If some one has a device behaving the same way the Freecom Dual Drive did, and see the error he/she will re-open the case.

Comment 8 Samuel Verschelde 2015-05-20 18:47:10 CEST

Thanks, closing as WORKSFORME then.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME