Bug#966917: Regression: cannot replace files on cifs mounts anymore when running linux-image-4.19.0-10-amd64

[Salvatore Bonaccorso <carnil@debian.org>]

Control: tags -1 + upstream

On Mon, Aug 03, 2020 at 10:23:49AM +0200, Philipp Huebner wrote:
> Package: src:linux
> Version: 4.19.132-1
> Severity: important
> 
> Dear Maintainer(s),
> 
> we are using several cifs mounts, among them our users' homes, and this
> regression causes graphical logins to fail, because
>  ~/.local/share/xorg/Xorg.0.log
> could no longer be moved to
>  ~/.local/share/xorg/Xorg.0.log.old:
> 
> > Aug  3 04:19:41 /usr/lib/gdm3/gdm-x-session[8166]: (EE) Cannot move
> old log file "/home/phuebner/.local/share/xorg/Xorg.0.log" to
> "/home/phuebner/.local/share/xorg/Xorg.0.log.old"
> 
> Manually deleting either Xorg.0.log or Xorg.0.log.old fixes logging in
> for the next attempt, deleting both fixes the next two login attempts.
> 
> While looking for the root cause, it turned out to be a generic problem
> with linux-image-4.19.0-10-amd64:
> 
> ~$ rm -f foo bar
> ~$ echo test > foo
> ~$ echo test > bar
> ~$ mv foo bar
> mv: cannot move 'foo' to 'bar': File exists
> 
> This is a problem on all our cifs mounts, no file can be replaced
> without actively deleting it first.
> 
> The mounts look like this (taken from /proc/mounts):
> //homes-server/phuebner /home/phuebner cifs
> rw,nosuid,nodev,relatime,vers=1.0,cache=strict,username=phuebner,uid=5079,noforceuid,gid=65534,noforcegid,addr=10.144.0.14,soft,unix,posixpaths,serverino,mapposix,nobrl,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1
> 0 0
> 
> The server is running samba 2:4.9.5 on Debian 10, for some tricky
> reasons we cannot use higher smb versions than 1.0 at the moment.
> 
> Manually booting the client into the previous kernel
> (linux-image-4.19.0-9-amd64) restores the normal behaviour.
> 
> Quick action on this would be much appreciated!

Could you please check if applying
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e6705182d4e1b77248a93470d6d7b3013d59b30
on top fixes the issue for you?

The fix was backported to 4.19.135 and the introducing commit was
backported in 4.19.132.

Regards,
Salvatore