Description of problem: When we shadow copy on windows we go ahead and try to restore the previous version of the file. On right click over the file we have 3 options 1.Restore Previous Versions 2.Copy 3.Open When we say OPEN we get to see the content of the file. In windows files we are not able to see the content. It throws denial pop up. "@_GMT<timestamp>/filepath Version-Release number of selected component (if applicable): samba-client-4.4.2-1.el7rhgs.x86_64 glusterfs-client-xlators-3.7.9-2.el7rhgs.x86_64 How reproducible: Always Steps to Reproduce: 1.Create a windows file over windows client mount 2.Create a valid snapshot 3.Activate the snapshot 4.Right click on the windows file and click on Restore Previous Versions and then Click the OPEN tab Actual results: Not able to see the content of the file Expected results: Should be able to check the file content Additional info:
The bug description was not very clear therefore had a discussion with Vivek and following are the observations: On right click over the file we have 3 options 1.Restore Previous Versions 2.Copy 3.Open "Open" is working fine for .txt, and .pdf files, but not for .docx (Microsoft Word) files. With this information it seems like Microsoft word is trying to create temporary file before opening .docx file. The snapshot files (.docx) are accessed from .snaps directory (USS) and this directory is read-only therefore we are seeing the error. Will cross-check this assumption and see if we can provide any workaround for this problem.
If the RCA is correct, then other filesystems/snapshot implementations would possibly also suffer. As a fix/workaround, we could add an option "shadow:read only" (or so) to the shadow_copy2 module, that lets the module return every file *and directory* as read-only to the smb layer.
Closed the samba bugs in bulk when PM_Score was less than 0. As the team was working on few of them, opening all of them.
Reducing the bug priority/severity as it is marked known issue.