samba - Nov 2021 - Overwriting open files on cifs mount of Samba share fails

Hello all,

I have a Samba share mounted on a Linux client with cifs,
and I cannot overwrite open files for example by renaming another
existing file to the open file. The error message is "permission
denied"
although the permissions would be fine (same operation works if the
target file is not open).

Is this a known limitation of how Samba/SMB/cifs work and I have to live
with it, or is this something that should work in principle and I can
investigate further (check configs, update Samba, etc.)?

I am asking this upfront before investigating further because I am aware
that in the Windows world open files cannot be overwritten.
On the other hand, if this operation is known to not work then SMB
shares seem to be unsuitable for use cases where Linux users actively
work on files on these shares, and I assumed that many people use such
setups.

So I am unsure what is the case here and would be glad if I could get an
answer to this question before spending much more time on debugging that
might be in vain.
I did some hours of research already but so far I found only other
people with the same problem, no definitive answers.
For example, I did not find any configuration option that looked related
to this.


Background:

I am trying to use a Samba share from a Linux client,
but some (GUI) applications (most notably Evince, the PDF viewer of
Gnome) fail to work correctly in this case: when one opens a PDF on the
share, edits it, and saves under the same name, it fails.
There is even a bug report about this:
https://gitlab.gnome.org/GNOME/evince/-/issues/1473
I investigated this with strace and found out that when
saving files the application creates a temp file in the same directory
with the new content and then calls rename(2) to overwrite the target
file with the temp file, while the target file is still open.
This produces EACCES.

The following small Python snippet can reproduce this:

python3 -c 'p = "/tmp/"
import os
os.close(os.open(p+"test1", os.O_WRONLY|os.O_CREAT))
os.open(p+"test2", os.O_RDONLY|os.O_CREAT)
os.rename(p+"test1", p+"test2")'

On /tmp/ this works, if I replace the directory with the path to a cifs
mount the last step fails with "permission denied".
Afterwards, the target file is gone, which is weird for an operation
that returns a permission error.


If relevant:

I have tested this among others with Ubuntu 20.04 on both client and
server (kernel 5.4.0 and samba 4.11.6). I am aware that these are not
the latest versions, but as mentioned would greatly appreciate any
information about whether an update could potentially improve the
situation.
My configuration is totally standard as I tested it with a fresh
installation and just added a writable share.
The resulting mount options on the client are
rw,relatime,vers=3.1.1,cache=strict,uid=1000,noforceuid,gid=1000,noforcegid,
file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,
rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1
Of these, I only specified vers, uid and gid.
nounix was automatically added although testparm -v on the server says
"unix extensions = Yes".
Not sure whether all this is relevant, if there is hope in reconfiguring
something in order to make the application work I will happily provide
more info.

Thanks in advance for any help!

Kind regards
Philipp

On Fri, Nov 05, 2021 at 08:14:02PM +0100, Philipp Wendler via samba
wrote:
>I have tested this among others with Ubuntu 20.04 on both client and
>server (kernel 5.4.0 and samba 4.11.6). I am aware that these are not
>the latest versions, but as mentioned would greatly appreciate any
>information about whether an update could potentially improve the
>situation.
>My configuration is totally standard as I tested it with a fresh
>installation and just added a writable share.
>The resulting mount options on the client are
>rw,relatime,vers=3.1.1,cache=strict,uid=1000,noforceuid,gid=1000,noforcegid,
>file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,
>rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1
>Of these, I only specified vers, uid and gid.
>nounix was automatically added although testparm -v on the server says
>"unix extensions = Yes".
"unix extensions" only works over SMB1 at the moment. You
have specified SMB version 3.1.1 in your mount options on
the client, plus friends don't let friends use SMB1 anymore
(and your server almost certainly has SMB1 disabled).

The client redirector will have to try and spoof this,
rename over open files can't be done with "standard"
SMB2+.