DFS mounts broken with kernel 3.0.101-0.47.55-default

SUSE Linux Enterprise Server SLES Updates
1

After installing the latest kernel update to SLES 11 SP3 (3.0.101-0.47.55) cifs mounts of our AD shares (DFS) do no longer work.

After going back to 3.0.101-0.47.52-default everything is fine, as before the update. All other patches have been applied.

The mount error is:
mount error(1): Operation not permitted
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

dmesg reports:
[ 9322.605008] CIFS VFS: Send error in SessSetup = -1
[ 9322.605465] CIFS VFS: cifs_mount failed w/return code = -1
[ 9374.923398] CIFS VFS: cifs_calc_signature2: Can’t generate signature [ 9374.923401]

The problem occurs only when using the DFS syntax. Mounting UNC path or samba shares works fine.

A DFS path in our environment is somthing like //ukl-dc02.ad.uniklinik-freiburg.de/group/
whereas an UNC path would be something like //ukl-fscl01grp02/group02$/ i.e. pointing to the actual file server.

As file servers can change and we make extensive use of DFS path, we absolutely depend on this way of mounting.

2

mbaumstark,

It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.

Has your issue been resolved? If not, you might try one of the following options:

Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.suse.com/faq.php

If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.

Good luck!

Your SUSE Forums Team
http://forums.suse.com

3

Hello,

we are facing a similar issue after upgrading to 3.0.101-0.47.52-default.

On our side, neither trying to mount the share over DFS nor directly from the file server (UNC) works.
In our environment “packet signing” is mandatory, so we need to use the mount option ‘sec=ntlmsspi’.

Just for the record, our mount command looks like this:
mount -t cifs //domain/path/to/folder /tmp/foo/ --verbose -o username=username,password=password,uid=1234,gid=1234,sec=ntlmsspi

For now we have rolled back to 3.0.101-0.47.52-default.

Looking at the kernel sauce shows that a new function, ‘cifs_crypto_shash_md5_allocate()’, is implemented in ‘fs/cifs/cifsencrypt.c‘.
This function is called in ‘cifs_calc_signature()’ but not in ‘cifs_calc_signature2()’. Maybe this code path was forgotten?

Calling ‘cifs_crypto_shash_md5_allocate()’ in ‘cifs_calc_signature2()’ instead of just failing with “Can’t generate signature” seems to solve the problem for us.
Attached is a mini kernel patch, even though I am in no way sure this is the right way to fix this issue. Just a hint.

We would be very happy if you could push out a new version as soon as possible as we heavily relay on CIFS mounts to work.

Cheers,
Maurice Forster

Patch:
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----

— fs/cifs/cifsencrypt.c 2015-07-13 18:07:32.000000000 +0200
+++ fs/cifs/cifsencrypt_new.c 2015-07-13 18:03:39.000000000 +0200
@@ -139,8 +139,11 @@ static int cifs_calc_signature2(const st
return -EINVAL;

    if (!server->secmech.sdescmd5) {

  •           cERROR(1, "%s: Can't generate signature\

", func);

  •           return -1;

  •           rc = cifs_crypto_shash_md5_allocate(server);

  •           if (rc) {

  •                   cERROR(1, "%s: Can't alloc md5 crypto\

", func);

  •                   return -1;

  •           }
  }

  rc = crypto_shash_init(&server->secmech.sdescmd5->shash);

-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----

#####################################################################################

4

Hi Maurice,

thank you for reporting the results of your analysis: I’ve forwarded them to my SUSE contacts, asking for some developer to evaluate further actions.

While response is usually quick, I cannot make any promises other than to give feedback once I received a response.

Best regards,
Jens

5

thanks J,

SUSE/Novell has provided me with a link to the PTF and we are testing it, but it should be fine.

cheers

6

[QUOTE=laukdden_bdr;28839]thanks J,

SUSE/Novell has provided me with a link to the PTF and we are testing it, but it should be fine.

cheers[/QUOTE]

Did they give you any kind of indication on the timeline for an official fix being published to the update repos?