ฉันทำงานใน 2 สภาพแวดล้อม:
1 เป็น VM ที่ใช้ RHEL 7 (PRETTY_NAME="Red Hat Enterprise Linux Server 7.9") สำหรับความสงสัย
อีกอันคือ kubernetes pod ที่ใช้ ubuntu (PRETTY_NAME="Ubuntu 18.04.5 LTS")
มีผู้ใช้ (jbossrdi) ที่สามารถรันคำสั่ง nfs4_acl ในสภาพแวดล้อมเหล่านี้เพื่อเปลี่ยน ACL สำหรับ dirs และไฟล์ dirs ใน workingdir เป็นของผู้ใช้รายนี้และมี ACE ต่อไปนี้ซึ่งใช้ซ้ำ:
A::[email protected]:rwaDxtTnNcCy, A:fdi:[email protected]:rwaDxtTnNcCy
dirs และไฟล์เหล่านี้พร้อมใช้งานในทั้งสองสภาพแวดล้อม ความแตกต่างเล็กน้อยสำหรับสภาพแวดล้อมพ็อด k8s ซึ่งถูกเปลี่ยนเส้นทางด้วย symlink symlink ทำให้ /gpfs/nobackup/projects/seeds_rdi เปิด /gpfs/k8s
ตอนนี้ปัญหาเกิดขึ้นเมื่อใช้ nfs4_setfacl ในสภาพแวดล้อม k8s เนื่องจากมีลักษณะการทำงานที่แตกต่างกัน เมื่อใช้ strace ฉันสามารถติดตามสิ่งที่เกิดขึ้นในคำสั่ง nfs4_setfacl และฉันสังเกตสิ่งต่อไปนี้:
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 (อาร์กิวเมนต์ไม่ถูกต้อง)
ในสภาพแวดล้อม VM ดำเนินการคำสั่งเดียวกัน:
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
สิ่งที่ควรทราบก็คือสิ่งนี้เกิดขึ้นในไฟล์ไม่ใช่ในไดเร็กทอรี
คำสั่งที่ฉันเรียกใช้มีดังต่อไปนี้:
strace nfs4_setfacl -Ra A::decostfr:RWXD,A:fdi:decostfr:RWXD /gpfs/nobackup/projects/seeds_rdi/data/test/Tools/GLENT/dagw/workingdir/decostfr/fdec280122a