Lucrez in 2 medii:
1 este o VM care rulează RHEL 7 (PRETTY_NAME="Red Hat Enterprise Linux Server 7.9") pentru curiozitate
Celălalt este un pod kubernetes care rulează un ubuntu (PRETTY_NAME="Ubuntu 18.04.5 LTS").
Există un utilizator (jbossrdi) care poate rula comenzi nfs4_acl în aceste medii pentru a schimba ACL pentru directori și fișiere. Dir-urile din directorul de lucru sunt deținute de acest utilizator și au următoarele ACE care sunt aplicate recursiv:
A::[email protected]:rwaDxtTnNcCy, A:fdi:[email protected]:rwaDxtTnNcCy
Aceste directoare și fișiere sunt disponibile în ambele medii, o mică diferență pentru mediul pod k8s unde este redirecționat cu un link simbolic. Legătura simbolică pune /gpfs/nobackup/projects/seeds_rdi pe /gpfs/k8s.
Acum problema apare când se folosește nfs4_setfacl în mediul k8s, deoarece are un comportament diferit. Folosind strace, pot urmări ceea ce se întâmplă în comanda nfs4_setfacl și observ următoarele:
setxattr("/gpfs/k8s/data/test/Tools/GLENT/dagw/workingdir/decostfr/fdec280122a/doc/GBS_curation.html", "system.nfs4_acl", "\0\0\0\26\0\0 \0\0\0\0\0\0\0\26\1\277\0\0\0\10decostfr\0\0\0", 728, XATTR_REPLACE) = -1 EINVAL (Argument nevalid)
În mediul VM executând aceeași comandă:
setxattr("/gpfs/nobackup/projects/seeds_rdi/data/test/Tools/GLENT/dagw/workingdir/decostfr/fdec280122a/doc/GBS_curation_original.html", "system.nfs4_acl", "\0\0\0\35 \0\0\0\0\0\0\0\0\0\26\1\277\0\0\0\10decostfr\0\0\0", 1036, XATTR_REPLACE) = 0
Ceva de remarcat este, de asemenea, că acest lucru se întâmplă pe fișiere și nu pe directoare.
Comanda pe care am rulat-o este următoarea:
strace nfs4_setfacl -Ra A::decostfr:RWXD,A:fdi:decostfr:RWXD /gpfs/nobackup/projects/seeds_rdi/data/test/Tools/GLENT/dagw/workingdir/decostfr/fdec280122a