Bug 1305749 - Vim commands from a non-root user fails to execute on fuse mount with trash feature enabled
Vim commands from a non-root user fails to execute on fuse mount with trash f...
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: trash-xlator (Show other bugs)
3.7.8
All All
medium Severity medium
: ---
: ---
Assigned To: Anoop C S
: Triaged
Depends On: 1302307
Blocks: glusterfs-3.7.9
  Show dependency treegraph
 
Reported: 2016-02-09 01:16 EST by Anoop C S
Modified: 2016-04-19 03:21 EDT (History)
4 users (show)

See Also:
Fixed In Version: glusterfs-3.7.9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1302307
Environment:
Last Closed: 2016-04-19 03:16:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anoop C S 2016-02-09 01:16:46 EST
+++ This bug was initially created as a clone of Bug #1302307 +++

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.

--- Additional comment from Vijay Bellur on 2016-02-03 08:27:11 EST ---

REVIEW: http://review.gluster.org/13346 (features/trash: Handle unlink unwind properly) posted (#1) for review on master by Anoop C S (anoopcs@redhat.com)

--- Additional comment from Vijay Bellur on 2016-02-04 12:15:06 EST ---

COMMIT: http://review.gluster.org/13346 committed in master by Jeff Darcy (jdarcy@redhat.com) 
------
commit b609a55be4119c44b19252bd951780a78deb21c9
Author: Anoop C S <anoopcs@redhat.com>
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@redhat.com>
    Reviewed-on: http://review.gluster.org/13346
    Smoke: Gluster Build System <jenkins@build.gluster.com>
    Tested-by: jiffin tony Thottan <jthottan@redhat.com>
    Reviewed-by: jiffin tony Thottan <jthottan@redhat.com>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
Comment 1 Vijay Bellur 2016-02-09 01:21:13 EST
REVIEW: http://review.gluster.org/13401 (features/trash: Handle unlink unwind properly) posted (#2) for review on release-3.7 by Anoop C S (anoopcs@redhat.com)
Comment 2 Vijay Bellur 2016-02-10 22:14:44 EST
REVIEW: http://review.gluster.org/13401 (features/trash: Handle unlink unwind properly) posted (#3) for review on release-3.7 by Anoop C S (anoopcs@redhat.com)
Comment 3 Vijay Bellur 2016-02-16 07:49:56 EST
REVIEW: http://review.gluster.org/13401 (features/trash: Handle unlink unwind properly) posted (#4) for review on release-3.7 by Anoop C S (anoopcs@redhat.com)
Comment 4 Vijay Bellur 2016-03-08 09:00:27 EST
REVIEW: http://review.gluster.org/13401 (features/trash: Handle unlink unwind properly) posted (#5) for review on release-3.7 by Anoop C S (anoopcs@redhat.com)
Comment 5 Vijay Bellur 2016-03-08 10:29:57 EST
COMMIT: http://review.gluster.org/13401 committed in release-3.7 by Vijay Bellur (vbellur@redhat.com) 
------
commit ccdfd9f8550e1d1f9d311eb997f23c9b10c7a70b
Author: Anoop C S <anoopcs@redhat.com>
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@redhat.com>
    >Reviewed-on: http://review.gluster.org/13346
    >Smoke: Gluster Build System <jenkins@build.gluster.com>
    >Tested-by: jiffin tony Thottan <jthottan@redhat.com>
    >Reviewed-by: jiffin tony Thottan <jthottan@redhat.com>
    >CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
    >NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    (cherry picked from commit b609a55be4119c44b19252bd951780a78deb21c9)
    
    Signed-off-by: Anoop C S <anoopcs@redhat.com>
    Change-Id: I88950b7d2e42bda65272bc359e8dc60a2ce04d89
    BUG: 1305749
    Reviewed-on: http://review.gluster.org/13401
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
    Reviewed-by: jiffin tony Thottan <jthottan@redhat.com>
    Reviewed-by: Vijay Bellur <vbellur@redhat.com>
    Smoke: Gluster Build System <jenkins@build.gluster.com>
Comment 6 Kaushal 2016-04-19 03:21:07 EDT
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.9, please open a new bug report.

glusterfs-3.7.9 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] https://www.gluster.org/pipermail/gluster-users/2016-March/025922.html
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Note You need to log in before you can comment on or make changes to this bug.