Bug 1040275 - Stopping/Starting a Gluster volume resets ownership
Summary: Stopping/Starting a Gluster volume resets ownership
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: posix
Version: mainline
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Vijay Bellur
QA Contact:
URL:
Whiteboard:
Depends On: 1040211
Blocks: 1095971
TreeView+ depends on / blocked
 
Reported: 2013-12-11 05:41 UTC by Anand Avati
Modified: 2015-09-01 23:06 UTC (History)
10 users (show)

Fixed In Version: glusterfs-3.4.3
Clone Of: 1040211
: 1095971 (view as bug list)
Environment:
Last Closed: 2014-04-17 13:15:13 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Anand Avati 2013-12-11 05:41:31 UTC
+++ This bug was initially created as a clone of Bug #1040211 +++

Description of problem:
We have noticed that if you stop and start a Gluster volume the ownership of the mount reverts to root/root.

For example:

On a client machine with the volume mounted as "environments" we see:
drwxr-xr-x 30 pe-puppet pe-puppet 4096 Dec  2 10:18 environments

We then stop and start the volume on the storage server:
[root@rhs-001 d11]# gluster volume stop puppet-env
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
volume stop: puppet-env: success
[root@rhs-001 d11]# gluster volume start puppet-env
volume start: puppet-env: success

Immediately after we look at the mount point again and see:
drwxr-xr-x 30 root      root      4096 Dec  2 10:18 environments

This is obviously quite high impact as applications expect their volumes to have certain ownership.

Version-Release number of selected component (if applicable):
glusterfs-3.4.0.33rhs-1.el6_4.x86_64

How reproducible:
100%

Steps to Reproduce:
1. [root@unused-9-68 ~]# mount -t nfs  unused-9-37:/rep_test1 /mnt
2. [root@unused-9-68 ~]# chown fred.fred /mnt/
3. [root@unused-9-68 ~]# ls -ld /mnt/
drwxr-xr-x 4 fred fred 8192 Nov  6 15:56 /mnt/
4. [root@unused-9-37 ~]# gluster volume stop rep_test1
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
volume stop: rep_test1: success
5. [root@unused-9-37 ~]# gluster volume start rep_test1
volume start: rep_test1: success
6. [root@unused-9-68 ~]# ls -ld /mnt/
drwxr-xr-x 4 root root 8192 Nov  6 15:56 /mnt/

Actual results:
Ownership changes

Expected results:
Ownership should not change.

--- Additional comment from Gowrishankar Rajaiyan on 2013-12-10 23:08:35 EST ---

We have storage.owner-uid and storage.owner-gid volume options. Does that help ?

--- Additional comment from Anand Avati on 2013-12-11 00:40:40 EST ---

Ironically, this is a bug introduced by the patch which implemented storage.owner-uid/gid option.

Comment 1 Anand Avati 2013-12-11 05:44:19 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#1) for review on master by Anand Avati (avati)

Comment 2 Anand Avati 2013-12-11 05:50:30 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#2) for review on master by Anand Avati (avati)

Comment 3 Anand Avati 2013-12-11 05:52:42 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#3) for review on master by Anand Avati (avati)

Comment 4 Anand Avati 2013-12-11 06:24:52 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#4) for review on master by Anand Avati (avati)

Comment 5 Anand Avati 2013-12-11 14:58:32 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#5) for review on master by Anand Avati (avati)

Comment 6 Anand Avati 2013-12-11 15:44:07 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#6) for review on master by Anand Avati (avati)

Comment 7 Anand Avati 2013-12-11 16:01:32 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#7) for review on master by Anand Avati (avati)

Comment 8 Anand Avati 2013-12-11 18:27:09 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#8) for review on master by Anand Avati (avati)

Comment 9 Anand Avati 2013-12-12 03:06:54 UTC
REVIEW: http://review.gluster.org/6476 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#9) for review on master by Anand Avati (avati)

Comment 10 Lukas Bezdicka 2013-12-12 09:15:14 UTC
Happens also on 3.4.1

Comment 11 Anand Avati 2013-12-13 07:50:00 UTC
COMMIT: http://review.gluster.org/6476 committed in master by Vijay Bellur (vbellur) 
------
commit 8bdc329e892f35ca19dfd07b542aa81afd855fce
Author: Anand Avati <avati>
Date:   Tue Dec 10 14:28:22 2013 -0800

    posix: if brick-uid or brick-gid is not specified, do not set
    
    Current code would set owner uid/gid explicitly to 0/0 on start
    even if none was specified. Fix it.
    
    Change-Id: I72dec9e79c51bd1eb3af5334c42b7c23b01d0258
    BUG: 1040275
    Signed-off-by: Anand Avati <avati>
    Reviewed-on: http://review.gluster.org/6476
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: Lukáš Bezdička <lukas.bezdicka>
    Reviewed-by: Krishnan Parthasarathi <kparthas>
    Reviewed-by: Vijay Bellur <vbellur>

Comment 12 Anand Avati 2013-12-16 18:21:19 UTC
REVIEW: http://review.gluster.org/6519 (posix: if brick-uid or brick-gid is not specified, do not set) posted (#1) for review on release-3.4 by Vijay Bellur (vbellur)

Comment 13 Anand Avati 2013-12-17 07:15:32 UTC
COMMIT: http://review.gluster.org/6519 committed in release-3.4 by Vijay Bellur (vbellur) 
------
commit 046cb49f20476ed900ae6dbe6f6ab7fad53d71a9
Author: Anand Avati <avati>
Date:   Tue Dec 10 14:28:22 2013 -0800

    posix: if brick-uid or brick-gid is not specified, do not set
    
    Current code would set owner uid/gid explicitly to 0/0 on start
    even if none was specified. Fix it.
    
    Change-Id: I72dec9e79c51bd1eb3af5334c42b7c23b01d0258
    BUG: 1040275
    Signed-off-by: Anand Avati <avati>
    Reviewed-on: http://review.gluster.org/6476
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: Lukáš Bezdička <lukas.bezdicka>
    Reviewed-by: Krishnan Parthasarathi <kparthas>
    Reviewed-by: Vijay Bellur <vbellur>
    Reviewed-on: http://review.gluster.org/6519
    Reviewed-by: Lukáš Bezdička <lukas.bezdicka>

Comment 14 Niels de Vos 2014-04-17 13:15:13 UTC
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.4.3, please reopen this bug report.

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

The fix for this bug likely to be included in all future GlusterFS releases i.e. release > 3.4.3. In the same line the recent release i.e. glusterfs-3.5.0 [3] likely to have the fix. You can verify this by reading the comments in this bug report and checking for comments mentioning "committed in release-3.5".

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/5978
[2] http://news.gmane.org/gmane.comp.file-systems.gluster.user
[3] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137


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