Description of problem: vi or vim is not working with trashcan feature of glusterfs via non-root user. Version-Release number of selected component (if applicable): Glusterfs 3.7.6 How reproducible: You can reproduce by using following steps Steps to Reproduce: We are using gluster 3.7.6 on ubuntu 14.04. We are facing an issue with trashcan feature. Our scenario is as follow: 1. 2 node server (ubuntu 14.04 with glusterfs 3.7.6) 2. 1 client node (ubuntu 14.04) 3. I have created one volume vol1 with 2 bricks in replica and with transport = tcp mode. 4. I have enabled quota on vol1 5. Now I have enabled trashcan feature on vol1 6. Now I have mounted vol1 on client's home directory "mount -t glusterfs -o transport=tcp server-1:/vol1 /home/" 7. Now when I logged in via any existing non-root user and perform any editing via vim or vi editor then I am getting this error "E200: *ReadPre autocommands made the file unreadable" and my user's home directory permission also get changed to 000. After sometime this permission gets automatically back to original one. (NOTE: user's home directories are copied in mounted directory glusterfs volume vol1. And user's home directory have user's specific permissions) Actual results: got this error "E200: *ReadPre autocommands made the file unreadable" while editing any file via vim or vi editor Expected results: I should able to edit any file via vim or vi editor Additional info: May be this issue related to vim working style format since vim or vi have to create a swap file for editing.
REVIEW: http://review.gluster.org/13346 (features/trash: Handle unlink unwind properly) posted (#1) for review on master by Anoop C S (anoopcs)
COMMIT: http://review.gluster.org/13346 committed in master by Jeff Darcy (jdarcy) ------ commit b609a55be4119c44b19252bd951780a78deb21c9 Author: Anoop C S <anoopcs> Date: Wed Feb 3 18:24:20 2016 +0530 features/trash: Handle unlink unwind properly When enabled, trash translator does a rename internally for every unlink request and unwinds the original unlink call. But this was unwinded back with prerparent and postparent as NULL which resulted in changing the parent directory permissions to 000. This issue is consistently seen as a failure when a non-root user executes vim commands which internally tries to perform stat operations (as part of swap/backup file creation) on a file whose parent directory's permission was modified to 000 due to recent unlink for another file inside the same directory. Change-Id: I161a036b37fb815866d50d2d6260ff0ad22d7223 BUG: 1302307 Signed-off-by: Anoop C S <anoopcs> Reviewed-on: http://review.gluster.org/13346 Smoke: Gluster Build System <jenkins.com> Tested-by: jiffin tony Thottan <jthottan> Reviewed-by: jiffin tony Thottan <jthottan> CentOS-regression: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org>