As indicated in https://discuss.kde.org/t/dolphin-seems-not-to-respect-default-acls-on-directories/5577 Having since a while serious problems with dolphin not respecting default ACLs on directories when copying files. We’re running Arch Linux 6.1.55-1-lts #1 SMP PREEMPT_DYNAMIC Sat, 23 Sep 2023 16:57:15 +0000 x86_64 GNU/Linux on the server, and EndeavourOS Linux 6.1.55-1-lts #1 SMP PREEMPT_DYNAMIC Sat, 23 Sep 2023 16:57:15 +0000 x86_64 GNU/Linux on the clients. But I can reproduce the problem on just the clients. We use PAM having /etc/pam.d/system-login:session optional pam_umask.so usergroups umask=0077 such that umask is by default 0007 and, for example, the users involved are members of the users group and by default have their group name the same as their username… pretty much all vanilla so far. (1) if I create a test directory as follows in /tmp: $ mkdir testacl $ chown richard:users testacl/ $ chmod g+s testacl/ $ setfacl -d -m group:users:rwx testacl $ getfacl testacl/ # file: testacl/ # owner: richard # group: users # flags: -s- user::rwx group::rwx other::--- default:user::rwx default:group::rwx default:group:users:rwx default:mask::rwx default:other::--- create files to copy: $ touch f-bash f-dolphin f-nautilus $ ls -la f-* -rw-rw---- 1 richard richard 0 28 sept. 16:05 f-bash -rw-rw---- 1 richard richard 0 28 sept. 16:05 f-dolphin -rw-rw---- 1 richard richard 0 28 sept. 16:05 f-nautilus Now, control test that things are setup as expected with bash $ cp f-bash testacl/ $ getfacl testacl/f-bash # file: testacl/f-bash # owner: richard # group: users user::rw- group::rwx #effective:rw- group:users:rwx #effective:rw- mask::rw- other::--- great, copied file gets group changed to users and group permissions are OK. But when dolphin copies its file to the test directory, the following is the result: $ getfacl testacl/f-dolphin # file: testacl/f-dolphin # owner: richard # group: richard user::rw- group::rwx #effective:rw- group:users:rwx #effective:rw- mask::rw- other::--- Notice that the copied file’s group didn’t get correctly updated. If I try with nautilus, the expected behaviour is seen, that is just like if one used cp. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.1.55-1-lts (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 5500U with Radeon Graphics Memory: 30.7 Gio of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: MINIPC PN51-E1 System Version: 0505
https://invent.kde.org/frameworks/kio/-/merge_requests/1434
ping?
Also here in current Plasma 6.x.x This Bug is very critica for us! This bug sabotages in critical way the work in a company, team using NFS Shares, it forces us to give root-passwords or sudo rights to standard users, that the amployees can do their jobs and rises big securtiy holes/risks.
Same behaviour as described for me. In Terminal (TTY and Konsole) I can access NFS shares with ACLs as expected, while other KDE apps (i.e. dolphin, digikam) refuse write access. KDE is running on current ARCH (Kernel 6.7.12-x64v2-xanmod1-1, plasma-desktop 6.0.3-1). NFS server is running on FreeBSD. NFS is kerberized in an Samba Active Directory environment with nfsv4_acl (not posix). Write access even missing when both group permissions and acl should allow it. Possibly related: https://bugs.kde.org/show_bug.cgi?id=418716 https://bugs.kde.org/show_bug.cgi?id=267209 [administrator@SERVER ~]$ ls -al /export/Common/SHAREX/ total 2435 drwxrwx---+ 4 administrator SHAREX-GROUP 10 6 Apr. 01:52 . drwxrwxr-x+ 5 administrator domain_users 8 30 Dez. 17:04 .. -rwxrw----+ 1 USERB SHAREX-GROUP 42 21 März 2021 .stignore -rwxrw-r--+ 1 root SHAREX-GROUP 1111 30 Dez. 17:04 .stignore.global -rwxrw-r--+ 1 administrator SHAREX-GROUP 1091 25 Okt. 2021 .stignore.global.orig drwxrwxr-x+ 7 administrator SHAREX-GROUP 7 30 März 17:18 Dokumente drwxrwxr-x+ 14 USERA SHAREX-GROUP 14 6 Apr. 09:23 Fotos [administrator@SERVER ~]$ getfacl /export/Common/SHAREX/ # file: /export/Common/SHAREX/ # owner: administrator # group: SHAREX-GROUP user:USERB:rwxpDdaARWcCos:fd-----:allow user:USERA:rwxpDdaARWcCos:fd-----:allow user:administrator:rwxpDdaARWcCos:fd----I:allow owner@:rwxp--aARWcCos:-------:allow group@:rwxp--a-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow [USERA@CLIENT ~]$ ls -al /misc/DOMAIN/Common/SHAREX/ insgesamt 2435 drwxrwx---+ 4 administrator SHAREX-GROUP 10 6. Apr 01:52 . drwxrwxr-x+ 5 administrator domain_users 8 30. Dez 17:04 .. drwxrwxr-x+ 7 administrator SHAREX-GROUP 7 30. Mär 17:18 Dokumente drwxrwxr-x+ 14 USERA SHAREX-GROUP 14 6. Apr 09:23 Fotos -rwxrw----+ 1 USERB SHAREX-GROUP 42 21. Mär 2021 .stignore -rwxrw-r--+ 1 root SHAREX-GROUP 1111 30. Dez 17:04 .stignore.global -rwxrw-r--+ 1 administrator SHAREX-GROUP 1091 25. Okt 2021 .stignore.global.orig [USERA@CLIENT ~]$ getfacl /misc/DOMAIN/Common/SHAREX/ getfacl: Entferne führende '/' von absoluten Pfadnamen # file: misc/DOMAIN/Common/SHAREX/ # owner: administrator # group: SHAREX-GROUP user::rwx group::rwx other::--- [USERA@CLIENT ~]$ id USERA uid=10010(USERA) gid=10000(domain_users) Gruppen=10000(domain_users),11001(SHAREX-GROUP),2000001(BUILTIN\users) [USERA@CLIENT ~]$ mount | grep Common SERVER.DOMAIN.TLD:/Common on /misc/DOMAIN/Common type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=X.X.X.X,local_lock=none,addr=X.X.X.X)
ping? ping?