[Bugs] [Bug 1305749] New: Vim commands from a non-root user fails to execute on fuse mount with trash feature enabled
bugzilla at redhat.com
bugzilla at redhat.com
Tue Feb 9 06:16:46 UTC 2016
https://bugzilla.redhat.com/show_bug.cgi?id=1305749
Bug ID: 1305749
Summary: Vim commands from a non-root user fails to execute on
fuse mount with trash feature enabled
Product: GlusterFS
Version: 3.7.7
Component: trash-xlator
Keywords: Triaged
Severity: medium
Priority: medium
Assignee: bugs at gluster.org
Reporter: anoopcs at redhat.com
CC: anoopcs at redhat.com, bugs at gluster.org,
jthottan at redhat.com, pank.singh9191 at gmail.com
Depends On: 1302307
+++ 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 at 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 at redhat.com)
------
commit b609a55be4119c44b19252bd951780a78deb21c9
Author: Anoop C S <anoopcs at 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 at redhat.com>
Reviewed-on: http://review.gluster.org/13346
Smoke: Gluster Build System <jenkins at build.gluster.com>
Tested-by: jiffin tony Thottan <jthottan at redhat.com>
Reviewed-by: jiffin tony Thottan <jthottan at redhat.com>
CentOS-regression: Gluster Build System <jenkins at build.gluster.com>
NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1302307
[Bug 1302307] Vim commands from a non-root user fails to execute on fuse
mount with trash feature enabled
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list