Mount.cifs does not work without keyutils being installed

[Carsten Eie Frigaard]

In 17.10 you could mount a cifs network-drive via

> sudo mount -t cifs //xx.yy.zz/abc t -o vers=1.0,username=xxxxxx,sec=ntlm,uid=1000,gid=1000,iocharset=utf8,domain=DD

having cifs-utils (and smbclient) installed manually.

But in 18.04 (both with SMB1 and moving til SMB3) it does not work until keyutils has been installed.

The only error I see, when the cifs mount is not working, is a -2 error ("mount error(2): No such file or directory" or "CIFS VFS: cifs_mount failed w/return code = -2"):

mbmount> sudo mount -t cifs //xx.yy.zz/abc t --verbose -o vers=3,username=xxxxxx,sec=ntlmv2,uid=1000,gid=1000,iocharset=utf8,domain=DD,nounix
Password for xxxxx: ********
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Smbmount> dmesg | tail
[ 89.915840] [UFW BLOCK] IN=wlp4s0 OUT= MAC=28:16:ad:18:e7:87:00:18:4d:4f:f5:1c:08:00 SRC=10.88.128.13 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=17677 PROTO=TCP SPT=445 DPT=55514 WINDOW=0 RES=0x00 RST URGP=0
[ 89.916307] [UFW BLOCK] IN=wlp4s0 OUT= MAC=28:16:ad:18:e7:87:00:18:4d:4f:f5:1c:08:00 SRC=10.88.4.188 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=5527 PROTO=TCP SPT=445 DPT=52714 WINDOW=0 RES=0x00 RST URGP=0
[ 362.580011] FS-Cache: Loaded
[ 362.592410] FS-Cache: Netfs 'cifs' registered for caching
[ 362.592495] Key type cifs.spnego registered
[ 362.592498] Key type cifs.idmap registered
[ 362.752492] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc
[ 362.787329] CIFS VFS: cifs_mount failed w/return code = -2
[ 381.832633] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc
[ 381.870721] CIFS VFS: cifs_mount failed w/return code = -2

> apt install keyutils
...

Smbmount> sudo mount -t cifs //xx.yy.zz/abc t --verbose -o vers=3,username=xxxxxx,sec=ntlmv2,uid=1000,gid=1000,iocharset=utf8,domain=DD,nounix

>MOUNT OK HERE>

Smbmount> dmesg | tail
[ 89.916307] [UFW BLOCK] IN=wlp4s0 OUT= MAC=28:16:ad:18:e7:87:00:18:4d:4f:f5:1c:08:00 SRC=10.88.4.188 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=5527 PROTO=TCP SPT=445 DPT=52714 WINDOW=0 RES=0x00 RST URGP=0
[ 362.580011] FS-Cache: Loaded
[ 362.592410] FS-Cache: Netfs 'cifs' registered for caching
[ 362.592495] Key type cifs.spnego registered
[ 362.592498] Key type cifs.idmap registered
[ 362.752492] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc
[ 362.787329] CIFS VFS: cifs_mount failed w/return code = -2
[ 381.832633] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc
[ 381.870721] CIFS VFS: cifs_mount failed w/return code = -2
[ 432.322763] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc

Keyutils were not manually installed in my 17.10 system. And I am aware of the change in default SMB versions from kernel 4.13.5 and on (cause me to insert the vers=1.0 in the mount options):

From man mount.cifs:
 "The default since v4.13.5 is for the client and server to negotiate the highest possible
 version greater than or equal to 2.1. In kernels prior to
 v4.13, the default was 1.0. For kernels between v4.13 and v4.13.5 the default is 3.0."

And there are no fundamental change in the packages for cifs-utils, as I can see (both suggests to use keyutils!).

My 17.10:
Package: cifs-utils
Status: install ok installed
Priority: optional
Section: otherosfs
Installed-Size: 229
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Version: 2:6.7-1
Replaces: smbfs (<< 2:4.0~rc1-1)
Depends: samba-common, libc6 (>= 2.17), libcap-ng0, libkeyutils1 (>= 1.4), libkrb5-3 (>= 1.13~alpha1+dfsg), libpam0g (>= 0.99.7.1), libtalloc2 (>= 2.0.4~git20101213), libwbclient0 (>= 2:4.0.3+dfsg1)
Suggests: keyutils, smbclient, winbind
Conffiles:
 /etc/request-key.d/cifs.idmap.conf 4c95734a68b45b65a5dc7b108836427b
 /etc/request-key.d/cifs.spnego.conf db5289bad3063aea58e1814380259a28
Description: Common Internet File System utilities
 The SMB/CIFS protocol provides support for cross-platform file sharing with
 Microsoft Windows, OS X, and other Unix systems.
 .
 This package provides utilities for managing mounts of CIFS network
 file systems.
Original-Maintainer: Debian Samba Maintainers <email address hidden>
Homepage: http://www.samba.org/~jlayton/cifs-utils/

My 18.04:
Package: cifs-utils
Status: install ok installed
Priority: optional
Section: otherosfs
Installed-Size: 226
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Version: 2:6.8-1
Replaces: smbfs (<< 2:4.0~rc1-1)
Depends: samba-common, libc6 (>= 2.17), libcap-ng0, libkeyutils1 (>= 1.4), libkrb5-3 (>= 1.13~alpha1+dfsg), libpam0g (>= 0.99.7.1), libtalloc2 (>= 2.0.4~git20101213), libwbclient0 (>= 2:4.0.3+dfsg1)
Suggests: keyutils, smbclient, winbind
Conffiles:
 /etc/request-key.d/cifs.idmap.conf 4c95734a68b45b65a5dc7b108836427b
 /etc/request-key.d/cifs.spnego.conf db5289bad3063aea58e1814380259a28
Description: Common Internet File System utilities
 The SMB/CIFS protocol provides support for cross-platform file sharing with
 Microsoft Windows, OS X, and other Unix systems.
 .
 This package provides utilities for managing mounts of CIFS network
 file systems.
Original-Maintainer: Debian Samba Maintainers <email address hidden>
Homepage: http://www.samba.org/~jlayton/cifs-utils/

My system info:

My old linux, 17.10 box:
 mount.cifs version: 6.7
 Linux cef-leno 4.13.0-39-generic #44-Ubuntu SMP Thu Apr 5 14:25:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

My new linux: 18:04 box:
 mount.cifs version: 6.8

 Distributor ID: Ubuntu
 Description: Ubuntu 18.04 LTS
 Release: 18.04
 Codename: bionic

 Linux xxxxxx 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[Carsten Eie Frigaard (cfrigaard)]

A small clarification of the problem: The core issue is that installing cifs-utils (and smbclient) and doing a cifs SMB3 (or SMB1) mount:

> sudo mount -t cifs //xx.yy.zz/abc t --verbose -o vers=3,username=xxxxxx,sec=ntlmv2,uid=1000,gid=1000,iocharset=utf8,domain=DD,nounix

yields a obfuscating "-2" CIFS error code:

  dmesg: [ 381.870721] CIFS VFS: cifs_mount failed w/return code = -2

  error text: No such file or directory" or "CIFS VFS: cifs_mount failed w/return code = -2"

Installing keyutils resolves the problem, and the mount command succeeds.

Keyutils is a suggested package in cifs-utils (and libkeyutils1 is required), but it seems that the CIFS mount is directly dependent on the keyutils package (not just the libkeyutils1 as one would expect).

The problem is NOT new in 18.04, it was basically the same in 17.10.

A suggested solution could be 1) to check CIFS for use/dependency of keyutils, and to put a better error message into the log ('keytuils missing' not just -2), or 2) to make keyutils required for the cifs-utils package.

NOTE: I still get a strange

  dmesg: [ 362.752492] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc

when the mount succeeds.

Regards
.c

[Augustin (gus3000)]

This bug is still present on Ubuntu 18.04 as of 21/01/2019.
I also suggest making keyutils a required dependency, as it is a "the program fails when this is not installed" dependency.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[HasHPIT (hashpit)]

Also affects Kubuntu 19.04

[Andreas Hasenack (ahasenack)]

It's not as simple as that, I can mount cifs shares just fine on 18.04 without having keyutils installed. I tried the exact same command line as in comment #1, bar the username/domain, against a synology DS216 NAS, and it worked just fine:

$ sudo mount -t cifs //ds216.lowtech/downloads --verbose -o vers=3,username=andreas,sec=ntlmv2,uid=1000,gid=10000,iocharset=utf8,domain=LOWTECH,nounix
Password for andreas@//ds216.lowtech/downloads: *************
mount.cifs kernel mount options: ip=10.10.1.5,unc=\\ds216.lowtech\downloads,vers=3.0,file_mode=0644,dir_mode=0755,vers=3,sec=ntlmv2,iocharset=utf8,nounix,uid=1000,gid=10000,user=andreas,domain=LOWTECH,pass=********

$ mount -t cifs
//ds216.lowtech/downloads on /ds216/downloads type cifs (rw,nosuid,nodev,noexec,relatime,vers=3,sec=ntlmv2,cache=strict,username=andreas,domain=LOWTECH,uid=1000,forceuid,gid=10000,forcegid,addr=10.10.1.5,file_mode=0644,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1,user)

Do you guys have a pam module or something else storing keys in the kernel keyring, which cifs-utils is trying to use in your case? Try "keyctl show", as root and as your user.

Something else you could try is enabling cifs debugging, as outlined here:

https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging

The first two "echo" commands fail here, but the one to cifsFYI works, and produces a bit more information in dmesg.

Let's see if any of this helps us get to the root of the problem.

[Andreas Hasenack (ahasenack)]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822841 is what downgraded keyutils from a Recommends to a Suggests

[Carsten Eie Frigaard (cfrigaard)]

Hi Andreas,

Should I try to produce some info to you regarding the "Mount.cifs" defect?

It was a long time since I last saw it, so it may take some time to
dig up again...but it seems to be worthwhile to generate some
additional debug info to you.

Please write, if there are particular details you are looking for,
otherwise I will try to follow your outline in the email, looking for
keys in keystores. But it may take some time, due to the upcomming
semester, and lots of new students!

Regards
Carsten Eie Frigaard

Den ons. 3. jul. 2019 kl. 22.31 skrev Andreas Hasenack <email address hidden>:
>
> It's not as simple as that, I can mount cifs shares just fine on 18.04
> without having keyutils installed. I tried the exact same command line
> as in comment #1, bar the username/domain, against a synology DS216 NAS,
> and it worked just fine:
>
> $ sudo mount -t cifs //ds216.lowtech/downloads --verbose -o vers=3,username=andreas,sec=ntlmv2,uid=1000,gid=10000,iocharset=utf8,domain=LOWTECH,nounix
> Password for andreas@//ds216.lowtech/downloads: *************
> mount.cifs kernel mount options: ip=10.10.1.5,unc=\\ds216.lowtech\downloads,vers=3.0,file_mode=0644,dir_mode=0755,vers=3,sec=ntlmv2,iocharset=utf8,nounix,uid=1000,gid=10000,user=andreas,domain=LOWTECH,pass=********
>
> $ mount -t cifs
> //ds216.lowtech/downloads on /ds216/downloads type cifs (rw,nosuid,nodev,noexec,relatime,vers=3,sec=ntlmv2,cache=strict,username=andreas,domain=LOWTECH,uid=1000,forceuid,gid=10000,forcegid,addr=10.10.1.5,file_mode=0644,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1,user)
>
> Do you guys have a pam module or something else storing keys in the
> kernel keyring, which cifs-utils is trying to use in your case? Try
> "keyctl show", as root and as your user.
>
> Something else you could try is enabling cifs debugging, as outlined
> here:
>
> https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging
>
>
> The first two "echo" commands fail here, but the one to cifsFYI works, and produces a bit more information in dmesg.
>
> Let's see if any of this helps us get to the root of the problem.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1772148
>
> Title:
> Mount.cifs does not work without keyutils being installed
>
> Status in cifs-utils package in Ubuntu:
> Confirmed
>
> Bug description:
> In 17.10 you could mount a cifs network-drive via
>
> > sudo mount -t cifs //xx.yy.zz/abc t -o
> vers=1.0,username=xxxxxx,sec=ntlm,uid=1000,gid=1000,iocharset=utf8,domain=DD
>
> having cifs-utils (and smbclient) installed manually.
>
> But in 18.04 (both with SMB1 and moving til SMB3) it does not work
> until keyutils has been installed.
>
> The only error I see, when the cifs mount is not working, is a -2
> error ("mount error(2): No such file or directory" or "CIFS VFS:
> cifs_mount failed w/return code = -2"):
>
> mbmount> sudo mount -t cifs //xx.yy.zz/abc t --verbose -o vers=3,username=xxxxxx,sec=ntlmv2,uid=1000,gid=1000,iocharset=utf8,domain=DD,nounix
> Password for xxxxx: ********
> mount err...

[Andreas Hasenack (ahasenack)]

Hello Carsten, thanks for coming back to us

I have a feeling this is about secrets stored in the keyring, so any clue around that area would help. In the end we might just put keyutils back as a Recommends, but I would like to understand in which scenario this is needed.

[Carsten Eie Frigaard (cfrigaard)]

Hi Andreas,

I'll see what I can do..but it may take a few months, due to the
upcoming semester...I think your hunch is correct, I just need to
re-establish an environmet to reproduce the defect (in a virtual box).

In the meantime: have fun!
Carsten

Den ons. 14. aug. 2019 kl. 16.01 skrev Andreas Hasenack <email address hidden>:
>
> Hello Carsten, thanks for coming back to us
>
> I have a feeling this is about secrets stored in the keyring, so any
> clue around that area would help. In the end we might just put keyutils
> back as a Recommends, but I would like to understand in which scenario
> this is needed.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1772148
>
> Title:
> Mount.cifs does not work without keyutils being installed
>
> Status in cifs-utils package in Ubuntu:
> Confirmed
>
> Bug description:
> In 17.10 you could mount a cifs network-drive via
>
> > sudo mount -t cifs //xx.yy.zz/abc t -o
> vers=1.0,username=xxxxxx,sec=ntlm,uid=1000,gid=1000,iocharset=utf8,domain=DD
>
> having cifs-utils (and smbclient) installed manually.
>
> But in 18.04 (both with SMB1 and moving til SMB3) it does not work
> until keyutils has been installed.
>
> The only error I see, when the cifs mount is not working, is a -2
> error ("mount error(2): No such file or directory" or "CIFS VFS:
> cifs_mount failed w/return code = -2"):
>
> mbmount> sudo mount -t cifs //xx.yy.zz/abc t --verbose -o vers=3,username=xxxxxx,sec=ntlmv2,uid=1000,gid=1000,iocharset=utf8,domain=DD,nounix
> Password for xxxxx: ********
> mount error(2): No such file or directory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>
> Smbmount> dmesg | tail
> [ 89.915840] [UFW BLOCK] IN=wlp4s0 OUT= MAC=28:16:ad:18:e7:87:00:18:4d:4f:f5:1c:08:00 SRC=10.88.128.13 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=17677 PROTO=TCP SPT=445 DPT=55514 WINDOW=0 RES=0x00 RST URGP=0
> [ 89.916307] [UFW BLOCK] IN=wlp4s0 OUT= MAC=28:16:ad:18:e7:87:00:18:4d:4f:f5:1c:08:00 SRC=10.88.4.188 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=5527 PROTO=TCP SPT=445 DPT=52714 WINDOW=0 RES=0x00 RST URGP=0
> [ 362.580011] FS-Cache: Loaded
> [ 362.592410] FS-Cache: Netfs 'cifs' registered for caching
> [ 362.592495] Key type cifs.spnego registered
> [ 362.592498] Key type cifs.idmap registered
> [ 362.752492] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc
> [ 362.787329] CIFS VFS: cifs_mount failed w/return code = -2
> [ 381.832633] CIFS VFS: BAD_NETWORK_NAME: \\xx.yy.zz\abc
> [ 381.870721] CIFS VFS: cifs_mount failed w/return code = -2
>
> > apt install keyutils
> ...
>
> Smbmount> sudo mount -t cifs //xx.yy.zz/abc t --verbose -o
> vers=3,username=xxxxxx,sec=ntlmv2,uid=1000,gid=1000,iocharset=utf8,domain=DD,nounix
>
> >MOUNT OK HERE>
>
> Smbmount> dmesg | tail
> [ 89.916307] [UFW BLOCK] IN=wlp4s0 OUT= MAC=28:16:ad:18:e7:87:00:18:4d:4f:f5:1c:08:00 SRC=10.88.4.188 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=5527 PROTO=TCP SPT=445 DPT=52714 WINDOW=0 RES=0x00 RST URGP=0
> [ 362.580011] FS-Cache: Loaded
> [ 362.592410] FS-Ca...

[krbvroc1 (kbass)]

I just spent days troubleshooting mount.cifs not working and ultimately determined it was due to this bug. I could mount okay, but no id/group mapping to the proper users would take place. All files were owned by the mounter or the uid/gid passed to the mount command. For 'cifsacl' option, this is not how it is supposed to work.

I started with an sssd setup which didn't work and then tried straight samba/winbind which equally didn't work.

I use mount.cifs with the 'cifsacl' option. 'cifsacl' will use winbind to perform the mapping. In the Linux kernel, cifsacl.c calls functions such as 'sid_to_id' which in turn issues a 'request_key' call.

So the cifs-utils package installs
/etc/request-key.d/cifs.idmap.conf
/etc/request-key.d/cifs.spnego.conf

However the package only has a 'suggestion' of the keyutils package. Without installing keyutils which creates the /etc/request-key.conf file AND installs the /sbin/request-key binary, the 'cifsacl' option doesn't work / perform the winbind mapping as it should. cifs-utils installed the cifs.idmap.conf which requires the /sbin/request-key binary be installed to invoke the cifs.idmap userspace helper.

If this cifs-utils does not change the keyutils to a required dependency, then I think there at least needs to be some serious logging/warning when a mount with cifsacl option is done to warn the user that cifs.idmap is not going to work / be invoked.

One I installed the keyutils package, then everything worked as I expected (and had been working on a different distro).

After enabling debugging of the cifs module, I had seen the following messages when keyutils was not installed when accessing the mounted fs (with cifsacl):

kernel: fs/cifs/smb2ops.c: get_smb2_acl_by_path: rc = 0 ACL len 176
kernel: fs/cifs/cifsacl.c: sid_to_id: Can't map SID os:S-1-5-21-xxx-1115 to a uid
kernel: fs/cifs/cifsacl.c: sid_to_id: Can't map SID gs:S-1-5-21-xxx-513 to a gid
kernel: fs/cifs/inode.c: looking for uniqueid=3276811

Those debug level messages were not very helpful in indicating the request-key was failing rather than a samba/winbind issue.

This was on a new Ubuntu 20.04 LTS install.

Some comments above indicated an 'it works for me'. However those scenarios did not include the 'cifsacl' option, so the use of the cifs.idmap upcall was not exercised.

[Andreas Hasenack (ahasenack)]

Here is some of the history of the keyutils dependency in the cifs-utils package:

- first added in response to debian bug #504690 in 2011:
cifs-utils (2:4.9-1) unstable; urgency=low

  [ Luk Claes ]
  * Add Recommends to keyutils so following DFS links works out of the
    box. Closes: #504690.
  * Install README. Closes: #603094.
  * Add --without-libcap to dh_auto_configure. Closes: #615211.

  [ Steve Langasek ]
  * New upstream release. Closes: #600788.
    - mount.cifs: use original device name as-is for mtab.
      Closes: #586009, #583508, #589218.

 -- Luk Claes <email address hidden> Sat, 02 Apr 2011 17:10:35 +020

Then downgraded to "suggests" in 2016, in response to debian bug #822841:

cifs-utils (2:6.5-2) unstable; urgency=medium

  * Team upload
  * Move keyutils and winbind from Recommends to Suggests (Closes: #822841)
  * Spring cleaning:
    - Standards-Version: 3.9.8 (no change)
    - Use secure Vcs-* URIs
    - Remove cifs-utils.NEWS as mount.cifs is setuid again since 2:5.4-2
      (pre-wheezy)
    - Updated gbp.conf (Old style config section)
    - Renamed cifs-utils.lintian to cifs-utils.lintian-overrides
    - Updated copyright file

 -- Mathieu Parent <email address hidden> Tue, 03 May 2016 12:16:18 +0200

Now, mount.cifs works just fine without cifs-utils installed, for many scenarios. Maybe even most of the time? The main problem seems to be to identify the cases when keyutils is needed, and clearly communicate that.

[krbvroc1 (kbass)]

As far as I can tell, mount.cifs will not work properly without keyutils for several scenarios:
- 'cifsacl' option is used or
- kerberos auth is used / spnego is used
- when kernel level dns resolution is needed - so the cifs upcall for dns.resolver is required

All these cases where the cifs module needs to invoke helper functions require keyutils.

[Andreas Hasenack (ahasenack)]

Can you elaborate on when this happens " - when kernel level dns resolution is needed - so the cifs upcall for dns.resolver is required"? Together with kerberos still?

[krbvroc1 (kbass)]

From https://www.kernel.org/doc/readme/Documentation-filesystems-cifs-README

Enabling Kerberos (extended security) works but requires version 1.2 or later
of the helper program cifs.upcall to be present and to be configured in the
/etc/request-key.conf file. The cifs.upcall helper program is from the Samba
project(http://www.samba.org). NTLM and NTLMv2 and LANMAN support do not
require this helper. Note that NTLMv2 security (which does not require the
cifs.upcall helper program), instead of using Kerberos, is sufficient for
some use cases.

DFS support allows transparent redirection to shares in an MS-DFS name space.
In addition, DFS support for target shares which are specified as UNC
names which begin with host names (rather than IP addresses) requires
a user space helper (such as cifs.upcall) to be present in order to
translate host names to ip address, and the user space helper must also
be configured in the file /etc/request-key.conf. Samba, Windows servers and
many NAS appliances support DFS as a way of constructing a global name
space to ease network configuration and improve reliability.

To use cifs Kerberos and DFS support, the Linux keyutils package should be
installed and something like the following lines should be added to the
/etc/request-key.conf file:

[Andreas Hasenack (ahasenack)]

> In addition, DFS support for target shares which are specified as UNC
> names which begin with host names (rather than IP addresses) requires
> a user space helper (such as cifs.upcall)

So DFS would require /sbin/key.dns_resolver? DFS was the original requirement for adding keyutils as a Recommends back in 2011 via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504690.

Your list then becomes:
for several scenarios:
- 'cifsacl' option is used or
- kerberos auth is used / spnego is used
- when DFS is used

The extra deps that keyutils pulls in seem minor and already exist on the normal system:
Depends: libc6 (>= 2.15), libkeyutils1 (>= 1.6)

FWIW, I would favor promoting keyutils back to Recommends.

[Andreas Hasenack (ahasenack)]

keyutils is a Recommends since cifs-utils 2:6.11-2