Created attachment 18153 [details] strace log Can not open the excel file in Windows previous versions. Windows Execl sends create request with access mask 0x0012019f (contain Write/Append/Write EA/ Write Attribute), Samba server returns STATUS_MEDIA_WRITE_PROTECTED because openat() return EROFS.
Isn't MEDIA_WRITE_PROTECTED exactly the right error message? I'm not sure that it's expected to directly open snapshot files with Excel. How does that work in Windows? Whenever I test this, I only expect the "restore" operation to work.
Created attachment 18154 [details] windows_previous_version_open_excel_file Network packet shows ... 1. It works well if Excel opens file with read access. 2. Excel shows 'Sorry We Couldn't Open ...' when it send create request with write access. And this issue did not happen in Samba-4.13 --- > Whenever I test this, I only expect the "restore" operation to work. Yes. 'Restore' still works fine.
Created attachment 18155 [details] sniffer
(In reply to Mike Liu from comment #2) > And this issue did not happen in Samba-4.13 ... and I would argue that this is potentially a bug in Samba 4.13 that was silently fixed. What do others think? Should Samba silently swallow the O_RDWR bits in the open request? Does your file system have writable snapshots that don't work anymore now?
> ... and I would argue that this is potentially a bug in Samba 4.13 that was silently fixed. > What do others think? Should Samba silently swallow the O_RDWR bits in the open request? I think previous samba work around it. /* * Just pave over the user requested mode and use O_RDONLY. Later * attempts by the client to write on the handle will fail in the * pwrite() syscall with EINVAL which we carefully map to EROFS. In sum, * this matches Windows behaviour. */ how.flags &= ~(O_WRONLY | O_RDWR | O_CREAT); > Does your file system have writable snapshots that don't work anymore now? No. We use read-only (mount ro) for snapshots.
*** This bug has been marked as a duplicate of bug 13688 ***