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. 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. -- Thanks, Steve
