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:
Created attachment 5594 [details] Wireshark pcap capture of the mount failure Packet captured during a failing mount of a NAS cifs share
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
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
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é
Thanks, assigning to the kernel maintainer. Reporting this upstream to the kernel folks may help too.
Assignee: bugsquad => tmbSource RPM: (none) => kernel
Is this bug still present in latest cauldron?
Keywords: (none) => NEEDINFO
(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.
Thanks, closing as WORKSFORME then.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME