W dniu 07.11.2021 o 23:50, Steve French pisze:
That is interesting ... and weird. Why would POSIX allow doing
something write related (fsync) without write permission?
To work around this (especially if the server is reliable enough) -
simply mount with "nostrictsync" (we will write out cached writes to
the server on flush, but won't send the fsync).
Will look at it more.
Mounting with nostrictsync has made the problem go away. Thank you both!
Best regards,
Julian
On Sun, Nov 7, 2021 at 4:47 PM Jeremy Allison <jra@xxxxxxxxx> wrote:
On Sun, Nov 07, 2021 at 11:15:49PM +0100, Julian Sikorski wrote:
Hi,
thanks for responding. I am using loglevel 10. I have uploaded the
logs to my dropbox as they are too big to attach:
https://www.dropbox.com/sh/r4b7q7ti2zmtlu9/AACqFY0FW2oW41Vu8l3nLZJSa?dl=0
The problem happens around 15:45:48. Do the logs show what access mask
the fsp is being opened with you requested?
I am using quite an old samba server (4.9.5+dfsg-5+deb10u1) due to the
fact that openmediavault is based off debian 10 and there are no samba
backports available. Having said that, this configuration can work, as
shown by goffice/goffice-0.10.50-1.fc35.src.rpm rebuild and the fact
that it was working before for months previously.
The error is occurring on the file:
/srv/dev-disk-by-label-omv/julian/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-devel-0.10.50-2.fc35.x86_64.rpm
this is a regular file, not a directory
opened with ACCESS_MASK: 0x00120089
that is:
SEC_STD_SYNCHRONIZE|
SEC_STD_READ_CONTROL|
SEC_FILE_READ_ATTRIBUTE|
SEC_FILE_READ_EA|
SEC_FILE_READ_DATA
so indeed, this is being opened *without*
SEC_FILE_WRITE_DATA|SEC_FILE_APPEND_DATA
so smbd is correct in returning ACCESS_DENIED
to an SMB2_FLUSH call.
Looks like this is a client bug, in that it
is passing a Linux fsync(fd) call directly
to the SMB2 server without checking if the
underlying file is open for write access.
In this case, the SMB2 client should just
return success to the caller, as any SMB_FLUSH
call will always return ACCESS_DENIED on a
non-writable file handle, and according to
Linux semantics calling fsync(fd) on an fd
open with O_RDNLY should return success.
Steve, over to you :-).
Jeremy.
