Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

mount -t cifs //192.168.1.100/homes homes

after a reboot. The first attempt failed but the second attempt worked.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?

[  297.204170] FS-Cache: Netfs 'cifs' registered for caching
[  297.204264] Key type cifs.spnego registered
[  297.204298] Key type cifs.idmap registered
[  297.775463] CIFS VFS: Send error in SessSetup = -5
[  297.775891] CIFS VFS: cifs_mount failed w/return code = -5

   * What outcome did you expect instead?

successful mounting on the first attempt.

*** End of the template - remove these template lines ***

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

on another reboot and running mount -t cifs //192.168.1.100/homes /mnt/homes

dmesg showed the following messages:

[  526.952993] FS-Cache: Netfs 'cifs' registered for caching
[  526.953087] Key type cifs.spnego registered
[  526.953119] Key type cifs.idmap registered
[  527.284315] Status code returned 0xc0000001 NT_STATUS_UNSUCCESSFUL
[  527.284363] CIFS VFS: Send error in SessSetup = -5
[  527.284783] CIFS VFS: cifs_mount failed w/return code = -5


*** End of the template - remove these template lines ***

I am seeing exactly the same problem on all my debian clients after
migrating the server to samba 4 from backports (4.1.11+dfsg-1~bpo70+1)

Things I checked so far:

- Using different filesystem on server does not fix the problem.
- Updating client to cifs from debian testing or unstable does not fix
the problem.
- Updating the linux kernel on the client to 3.14 from backports does
not fix the problem.

- The error always occurs only once. Just executing the same mount
command again leads to a successful connection. Mounting other shares
afterwards works on the first call.

- Network is complete dual stack (IPv4+IPv6). Disabling IPv6 on client
does not fix the problem.

- Server has multiple IPv4 and IPv6 addresses on the primary interface.
This may be problematic, I will investigate further.

- Using different usernames, with/without password, with "nounix", with
sec=ntlm or sec=ntlmv2 does not fix the problem.

Maybe someone can shine some light on this...

Regards,
Thomas

I can confirm the bug on a fresh Jessie install (amd64). And the problem is
even worse, than the bug report states, as it happens from time to time,
unrelated to the boot time. I use autofs automounter, and the first access
of any of the automount directories always fails. Next attempt successful.

Changing samba debug level to 10, these were the first different log lines:

  Create local NT token for sambauser
[2015/04/26 22:16:05.532690, 10, pid=3036, effective(0, 0), real(0, 0), class=tdb] ../source3/lib/gencache.c:296(gencache_set_data_blob)
  Adding cache entry with key=[IDMAP/SID2XID/S-1-5-21-1926378044-615406353-1386413454-1000] and timeout=[Thu Jan  1 01:00:00 AM 1970 CET] (-1430079365 seconds in the past)

  Create local NT token for sambauser
[2015/04/26 22:17:13.532059, 10, pid=3071, effective(0, 0), real(0, 0)] ../source3/lib/idmap_cache.c:56(idmap_cache_find_sid2unixid)
  Parsing value for key [IDMAP/SID2XID/S-1-5-21-1926378044-615406353-1386413454-1000]: value=[-1:U]

The first (Adding cache) was a failure, the second (Parsing value) was a
success.

After some more debugging, it turned out that the problem lies somewhere
around winbindd. After stopping winbindd, all worked fine. As I don't need
it, I even uninstalled the whole package, but others might not be so lucky
to be able to live without it.

I can attach the full logs, if needed.

Samba version 4.1.17-Debian (2:4.1.17+dfsg-2)

Regards,
Zoltan

Hi all

I have exactly the same "Bug" after updating from Debian 7.x to Debian 8!
So i can confirm that:
1. This Bug exists
2. I can confirm that it is "fixed" if i stop winbind.

At this point a big THX to Zoltan for findig this "fix".

The problem is that deactivating winbind is not a "fix". It's a "quick
and dirt fix".

So please fix this bug, because i think it is important!

THX and Greets

Raven