Description of problem: When we create a directory (say X) from windows client 1 (say WC-1) and create text files in directory X over the WC-1 only. Now from another windows client (WC-2) delete few files from directory X. Go to WC-1 right click over X and click on "Restore Previous Version" we are able to see snapshots. Now click open the snapshot directory link you are able to see all the files that are created initially in WC-1 (including the deleted files). Try to restore the directory (X). It wont allow you to restore those deleted files throwing an error saying "Permission Denied" and asks you to skip. After that when you go into the directory you still wont find the deleted files as it is not restored at all. This is tested against Windows Normal share mount on 2 different clients and it works fine (as in able to restore directory). One can restore from any other client even if the operation is carried from a different client. Version-Release number of selected component (if applicable): samba-client-4.4.2-1.el7rhgs.x86_64 glusterfs-cli-3.7.9-3.el7rhgs.x86_64 How reproducible: Always Steps to Reproduce: 1.Create a Disp-Rep volume 2.Enable USS & Snapshot directory 4.Set up VSS on the server 5.Mount the volume share in 2 different clients (preferable windows 8.1) 6.Create a directory (say A) on the windows client-1 (say WC-1) 7.Create 6-10 text files inside directory (A) on WC-1 8.Take a snapshot and activate it. 9.On WC-2 delete 2-3 files in directory (A). 10.On WC-1 right click on the directory (A) goto "Restore Previous Version" 11.Click on the snapshot link to restore the directory (X) Actual results: Permission Denied popup while restoring Expected results: Directory should get restored with all the deleted files without any issues Additional info:
Patch posted upstream at http://review.gluster.org/14274
Downstream patch posted at https://code.engineering.redhat.com/gerrit/#/c/74096
Followed the steps to reproduce mentioned above and Verified on versions samba-client-4.4.3-4.el7rhgs.x86_64 glusterfs-cli-3.7.9-5.el7rhgs.x86_64 There was no permission denied issue and was able to restore successfully.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1240