Launchpad has imported 2 comments from the remote bug at
https://bugzilla.kernel.org/show_bug.cgi?id=195817.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2017-05-19T12:26:23+00:00 keith wrote:
The cifs kernel module currently is currently disregarding the nt_status
USER_SESSION_DELETED packets sent to it from remote SMB2+ peers and is
subsequently holding onto clearly dead SMB2+ sessions as a result.
This is causing issues as it appears that the kernel only reconnects
after a delay period, during which time all IO to that network share
(with that session id) results in an I/O error for the user; all the
while the kernel is repeatedly resubmitting the requests in the
background with the server just responding to each of them with the same
error.
This is contrasting to the behaviour on Windows clients - whereby if the
response the client gets is USER_SESSION_DELETED, it will immediately
dump that session and reconnect - transparently to the user.
This causes massive issues multiuser mounts (as is the case for me), as
if a users SMB session is deleted by the server for any reason, that
user essentially loses all access to that share for extended periods,
until the cifs module sees fit to treat that session as dead and
renegotiate or an admin intervenes.
Reproducing the issue is easily done, establish an SMB2+ mount to a
Windows Server machine, open any directory on client to establish a
session, then simply terminate that SMB session from the servers MMC
console, if you then try and run any queries against that mountpoint on
the client you will just end up with a string of I/O errors because its
trying to use a session id which is dead.
For reference I'm testing using the following mount options:
vers=3.02,multiuser,sec=ntlmsspi,file_mode=0750,dir_mode=0755,cache=none,credentials=/etc/smb.credentials.conf
Kernels 4.4 and 4.10 have extended delays until the user is able to
regain access to the mountpoint, the latest rc has cut that down
significantly and its only a few minutes, but even still if the session
has been deleted by the server the client should at least attempt to
reconnect and then resubmit the last command, rather than continue to
submit packets with dead session ID's and return I/O to the user.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1707167/comments/0
On 2019-02-07T04:25:43+00:00 lsahlber wrote:
This was fixed in :
commit d81243c697ffc71f983736e7da2db31a8be0001f
Author: Mark Syms
Date: Thu May 24 09:47:31 2018 +0100
CIFS: 511c54a2f69195b28afb9dd119f03787b1625bb4 adds a check for session
expiry, status STATUS_NETWORK_SESSION_EXPIRED, however the server can also
respond with STATUS_USER_SESSION_DELETED in cases where the session has been
idle for some time and the server reaps the session to recover resources.
Handle this additional status in the same way as SESSION_EXPIRED.
Signed-off-by: Mark Syms
Signed-off-by: Steve French
CC: Stable
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1707167/comments/3
** Changed in: linux
Status: Unknown => Fix Released
** Changed in: linux
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1707167
Title:
Kernel CIFS Module ignores USER_SESSION_DELETED PDUs and holds onto
dead sessions.
Status in Linux:
Fix Released
Status in linux package in Ubuntu:
Triaged
Bug description:
#Summary
The cifs kernel module currently ignores the nt_status USER_SESSION_DELETED
PDUs sent to it from remote SMB2+ peers and holds onto clearly dead SMB2+
sessions as a result.
This is causing issues, as it appears that the kernel only reconnects
after a delay period, during which time all IO to that network share
(with that session id) results in an I/O error for the user; all the
while the kernel is repeatedly resubmitting the requests in the
background with the server just responding to each of them with yet
more USER_SESSION_DELETED packets.
This is contrasting to the behaviour on Windows clients - whereby if
the response the client gets is USER_SESSION_DELETED, it drops that
session and reconnects - transparently to the user.
This causes massive issues multiuser mounts (as is the case for me),
as if a users SMB session is deleted by the server for any reason,
that user essentially loses all access to that share for extended
periods, until the cifs module sees fit to treat that session as dead
and renegotiate or an admin intervenes.
# Reproducing
Reproducing the issue is
