nfs-ganesha version compatible with gluster 5.9
by Jordan Smith
I am running ganesha 2.7.6 on Ubuntu-bionic with gluster version 5.9.
I noticed for ganesha 2.8 there is a dependency for gluster 6 listed.
Can version 2.8 or 3 be installed on a 5.X gluster system.
I would like to upgrade to address a memory leak, but not sure if I need to upgrade the gluster cluster to use the newer version.
Thanks for the help.
4 years, 9 months
chown on a file with 777 permission does not work for any non-root user, not even the owner of the file
by des＠vmware.com
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt
-rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt
[root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2
[testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id
uid=2222(testu2) gid=8888(testg2) groups=8888(testg2)
[testu2@sc-rdops-vm07-dhcp-212-202 mnt]$
[testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt
chown: changing ownership of ‘new.txt’: Operation not permitted
[testu2@sc-rdops-vm07-dhcp-212-202 mnt]$
[root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1
[testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id
uid=1111(testu1) gid=8888(testg2) groups=8888(testg2)
[testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
[testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt
chown: changing ownership of ‘new.txt’: Operation not permitted
[testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) {
/* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership.
if (attr->owner != creds->caller_uid) {
status = fsalstat(ERR_FSAL_PERM, 0);
note = " (new OWNER was not user)";
goto out;
}
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) {
status = obj->obj_ops->test_access(obj, access_check, NULL,
NULL, false);
note = " (checked ACL)";
goto out;
}
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) {
/* Without an ACL, this user is not allowed some operation */
status = fsalstat(ERR_FSAL_PERM, 0);
note = " (no ACL to check)";
goto out;
}
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here.
So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
4 years, 9 months
FSAL loading RTLD_DEEPBIND and LD_PRELOAD
by Olivier Garaud
Hi,
I'm wondering about the way Ganesha loads the FSAL
in load_fsal we have
> #if defined(LINUX) && !defined(SANITIZE_ADDRESS)
> dl = dlopen(path, RTLD_NOW | RTLD_LOCAL | RTLD_DEEPBIND);
> #elif defined(FREEBSD) || defined(SANITIZE_ADDRESS)
> dl = dlopen(path, RTLD_NOW | RTLD_LOCAL);
> #endif
>
On my system Ganesha is built with jemalloc but my FSAL is not (it's not
using the same build chain)
My FSAL is using malloc_usable_size.
Ganesha does not use this symbol so it is resolved during dlopen.
Because the RTLD_DEEPBIND flag is used, the libc version of
malloc_usable_size is instead of the jemalloc one which ultimately leads to
a crash.
I could make sure both are built with the same allocator but this also
happens when I try to dynamically change the memory allocator (LD_PRELOAD
tcmalloc).
Looking to the history (back in 2012) the RTLD_DEEPBIND flags has been
introduced / removed and finally kept.
Can somebody remember the reason why it is needed ?
Did someone else had this kind of issue with LD_PRELOAD ?
Thanks for your help,
Regards,
Olivier
4 years, 9 months
Change in ...nfs-ganesha[next]: Fix Ganesha crash by sending stats
by Sachin Punadikar (GerritHub)
Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487038 )
Change subject: Fix Ganesha crash by sending stats
......................................................................
Fix Ganesha crash by sending stats
"ganesha_stats" with option client_all_ops sends stats for client
specific ops, but only if they are non-zero. In case if "reset"
operation was conducted, and there is no further activity by that
client, then no stats would be sent, leading to crash of Ganesha in
DBUS library code.
To avoid this, work-around is opted in which stats for the first
operation of that protocol will be always sent across. This will
avoid the crash.
Change-Id: Iec81e27d23459374062434b64f2273f97e548e86
Signed-off-by: Sachin Punadikar <psachin(a)in.ibm.com>
---
M src/support/server_stats.c
1 file changed, 28 insertions(+), 3 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/38/487038/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487038
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: Iec81e27d23459374062434b64f2273f97e548e86
Gerrit-Change-Number: 487038
Gerrit-PatchSet: 1
Gerrit-Owner: Sachin Punadikar <psachin(a)in.ibm.com>
Gerrit-MessageType: newchange
4 years, 9 months
Change in ...nfs-ganesha[next]: Set no_cleanup=true prior to calling fsal_open2()/fsal_reopen2()
by Madhu Thorat (GerritHub)
Madhu Thorat has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487024 )
Change subject: Set no_cleanup=true prior to calling fsal_open2()/fsal_reopen2()
......................................................................
Set no_cleanup=true prior to calling fsal_open2()/fsal_reopen2()
After a "state_lock" is held, if a FSALs open2(..)/reopen2(..) gets
called and if it fails with ESTALE then there is a possibility of
having a crash as we would try to take the same "state_lock" again in
state_wipe_file(..).
To avoid this we now set state_hdl->no_cleanup=true after holding a
"state_lock".
Change-Id: I99c611c14123266a5056c24c9a26e724476d09dd
Signed-off-by: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
---
M src/Protocols/NFS/nfs4_op_open.c
M src/Protocols/NFS/nfs4_op_open_downgrade.c
2 files changed, 24 insertions(+), 23 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/24/487024/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487024
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I99c611c14123266a5056c24c9a26e724476d09dd
Gerrit-Change-Number: 487024
Gerrit-PatchSet: 1
Gerrit-Owner: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
Gerrit-MessageType: newchange
4 years, 9 months
Change in ...nfs-ganesha[next]: scripts/systemd: .include is deprecated, use drop-in .conf file
by Kaleb KEITHLEY (GerritHub)
Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486938 )
Change subject: scripts/systemd: .include is deprecated, use drop-in .conf file
......................................................................
scripts/systemd: .include is deprecated, use drop-in .conf file
https://github.com/nfs-ganesha/nfs-ganesha/issues/547
It seems the .include was for the "Conflicts=..." line. Some
sites on the web say that for a Conflicts line you need to
override the entire contents of the file.
Systemd documentation is generally poor IMO, and there's little
to no documentation about drop-in files in general and nothing
about how to handle Conflicts= so this is my best guess at a
drop-in file.
Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com>
Change-Id: I1b701406836d4bd4268b981913b34c7f04311fa2
---
M src/nfs-ganesha.spec-in.cmake
A src/scripts/systemd/nfs-ganesha-lock.service.debian10
A src/scripts/systemd/nfs-ganesha-lock.service.el8
A src/scripts/systemd/rpc-statd.conf.debian10
A src/scripts/systemd/rpc-statd.conf.el8
5 files changed, 92 insertions(+), 46 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/38/486938/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486938
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I1b701406836d4bd4268b981913b34c7f04311fa2
Gerrit-Change-Number: 486938
Gerrit-PatchSet: 1
Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com>
Gerrit-MessageType: newchange
4 years, 9 months
Announce Push of V4-dev.8
by Frank Filz
Branch next
Tag:V4-dev.8
Merge Highlights
* MDCACHE - Unref chunk when not populating
* Supporting protocol update as part of UpdateExport
* FSAL: Skip additional file system types
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
8efea5d Frank S. Filz V4-dev.8
04bab1c Frank S. Filz FSAL: Skip additional file system types
7894fd1 Sriram Patil Supporting protocol update as part of UpdateExport
9c4cdcf Daniel Gryniewicz MDCACHE - Unref chunk when not populating
4 years, 9 months
Change in ...nfs-ganesha[next]: WIP: Fix entry->lru.refcnt
by Malahal (GerritHub)
Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486543 )
Change subject: WIP: Fix entry->lru.refcnt
......................................................................
WIP: Fix entry->lru.refcnt
Change-Id: I4fbc2bd6bff6c08338af52595a9bea66969f8467
Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_hash.h
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c
3 files changed, 40 insertions(+), 38 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/43/486543/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486543
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I4fbc2bd6bff6c08338af52595a9bea66969f8467
Gerrit-Change-Number: 486543
Gerrit-PatchSet: 1
Gerrit-Owner: Malahal <malahal(a)gmail.com>
Gerrit-MessageType: newchange
4 years, 9 months
Change in ...nfs-ganesha[next]: MDCACHE - Unref chunk when not populating
by Daniel Gryniewicz (GerritHub)
Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486532 )
Change subject: MDCACHE - Unref chunk when not populating
......................................................................
MDCACHE - Unref chunk when not populating
When we're progressing to the next chunk, and it's already there (i.e.
we don't need to populate it), we need to drop our ref on the previous
chunk.
Change-Id: I73b03510b4cf3cf311b64b4462d2680b2b21a25c
Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
1 file changed, 4 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/32/486532/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486532
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I73b03510b4cf3cf311b64b4462d2680b2b21a25c
Gerrit-Change-Number: 486532
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>
Gerrit-MessageType: newchange
4 years, 9 months
Change in ...nfs-ganesha[next]: Lock Owner hash table should account for its related owner
by Trishali Nayar (GerritHub)
Trishali Nayar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486514 )
Change subject: Lock Owner hash table should account for its related owner
......................................................................
Lock Owner hash table should account for its related owner
The lock owner has an open-owner under which the lock owner
was created. That should be taken into account for hashing
and comparing the lock owners.
Change-Id: I0c5cf1e2fdf891a0136accfed87d900dae17ff3b
Signed-off-by: Trishali Nayar <ntrishal(a)in.ibm.com>
---
M src/SAL/nfs4_owner.c
1 file changed, 27 insertions(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/14/486514/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486514
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I0c5cf1e2fdf891a0136accfed87d900dae17ff3b
Gerrit-Change-Number: 486514
Gerrit-PatchSet: 1
Gerrit-Owner: Trishali Nayar <ntrishal(a)in.ibm.com>
Gerrit-MessageType: newchange
4 years, 9 months
