On February 5, 2020 11:48:36 AM GMT+02:00, Christian Reiss <[email protected]> wrote: >Hey, > >during debug level logging on the bricks I got this bit: > >[2020-02-05 09:34:11.368305] I [MSGID: 139001] >[posix-acl.c:263:posix_acl_log_permit_denied] >0-ssd_storage-access-control: client: >CTX_ID:096e8723-f941-4e65-9ce6-5a4a03634d02-GRAPH_ID:0-PID:50568-HOST:node03.example.com-PC_NAME:ssd_storage-client-0-RECON_NO:-0, > >gfid: be318638-e8a0-4c6d-977d-7a937aa84806, >req(uid:36,gid:36,perm:1,ngrps:3), >ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-) >[Permission denied] > >I read it as follows: > >req(uid:36,gid:36,perm:1,ngrps:3) > -> Requesting UID si 36 which is vdsm. > >ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-) > -> Owning UID is root, Zero matching groups, > resuling permissions for 36 are 000, > Access Resolution: INVALID/ Access Denidd > acl not used. > >Does this sound right? >I tried manually mounting with > > mount -t glusterfs node01.example.com:/ssd_storage /media -o acl > >then setting the acl inside one test dir: > > setfacl -m u:root:rwx 2bd08834-349b-474c-94a9-0d815dd069cc > >and testing: > >sudo -u vdsm dd if=2bd08834-349b-474c-94a9-0d815dd069cc of=/dev/null >dd: error reading ‘2bd08834-349b-474c-94a9-0d815dd069cc’: Permission >denied >131072+0 records in >131072+0 records out >67108864 bytes (67 MB) copied, 0.0662261 s, 1.0 GB/s > >which resulted on the node01 with the first mentioned error. > >(insert scream here) > >-Chris > >On 04/02/2020 21:54, Christian Reiss wrote: >> Thanks for replying, >> >> What I just wrote Stahil was: >> >> >> ACL is correctly set: >> >> # file: 5aab365f-b1b9-49d0-b011-566bf936a100 >> # owner: vdsm >> # group: kvm >> user::rw- >> group::rw- >> other::--- >> >> Doing a setfacl failed due to "Operation not supported", remounting >with >> acl, too: >> >> [root@node01 ~]# mount -o remount,acl >> >/rhev/data-center/mnt/glusterSD/node01.dc-dus.dalason.net\:_ssd__storage/ >> /bin/sh: glusterfs: command not found >> >> As I am running the oVirt node I am not sure how feasable >down/upgrading >> is. I think I am stuck with what I have. >> >> Also, if this would be a permission issue, I would not be able to >access >> the file at all. Seems I can access some of it. And all of it when >root >> loaded the whole file first. >> >> >> I also did, even if it was correctly set, the chown from the >mountpoint >> again, to no avail. >> >> >> On 04/02/2020 21:53, Christian Reiss wrote: >>> >>> ACL is correctly set: >>> >>> # file: 5aab365f-b1b9-49d0-b011-566bf936a100 >>> # owner: vdsm >>> # group: kvm >>> user::rw- >>> group::rw- >>> other::--- >>> >>> Doing a setfacl failed due to "Operation not supported", remounting >>> with acl, too: >>> >>> [root@node01 ~]# mount -o remount,acl >>> >/rhev/data-center/mnt/glusterSD/node01.dc-dus.dalason.net\:_ssd__storage/ >>> /bin/sh: glusterfs: command not found >>> >>> As I am running the oVirt node I am not sure how feasable >>> down/upgrading is. I think I am stuck with what I have. >>> >>> Also, if this would be a permission issue, I would not be able to >>> access the file at all. Seems I can access some of it. And all of it > >>> when root loaded the whole file first. >>
I first noticed that issue when going from v6.5 to v6.6 , so you still have the option to: A) Try with monting via acl abd run a find to set acl for root user. B) Downgrade to v6.5 C) Upgrade to 7.0 (7.1 & 7.2 were broken for me ) It looks like Gluster are failing Ovirt again :D Best Regards, Strahil Nikolov _______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/6PXFXT4L4HFIMH2DRUBIN5YEDK4RS6C2/
