Zunächst einmal: Ja, das übergeordnete Verzeichnis verfügt über die richtigen Berechtigungen. Nachdem das geklärt ist, geht es nun um Folgendes.
Meine Benutzer können nicht schreiben oder rm von/mnt/file-server/reports/vendor/client/2018/02-04-02-10/
Alle Benutzer sind Mitglieder der Gruppe „sftpusers“. Jedes Verzeichnis 02-04-02-10hat dieselben Berechtigungen. Jeder Benutzer kann in JEDEM Verzeichnis eine Datei/ein Verzeichnis schreiben/speichern, außer wenn sich die Datei/das Verzeichnis im 02-04-02-10Verzeichnis befindet.
$tree -Rpg /mnt/file-server
/mnt/file-server/
├── [drwsrws--- sftpuser] reports
│ ├── [drwsrws--- sftpuser] vendor
│ │ ├── [drwsrws--- sftpuser] client
│ │ │ └── [drwsrws--- sftpuser] 2018
│ │ │ ├── [drwsrws--- sftpuser] 02-04-02-10
│ │ │ │ ├── [-rw-rw---- sftpuser] Fast_Track_Instock.csv
│ │ │ │ ├── [-rw-rw---- sftpuser] Forecast_and_Inventory_Planning.csv
│ │ │ │ ├── [-rw-rw---- sftpuser] parent_asi.csv
│ │ │ │ ├── [-rw-rw---- sftpuser] Sales_and_Inventory_Product_Details_Manufacturer.csv
│ │ │ │ ├── [-rw-rw---- sftpuser] Sales_and_Inventory_Product_Details_Sourcing.csv
│ │ │ │ ├── [-rw-rw---- sftpuser] Sales_Diagnostic_Ordered_Revenue.csv
│ │ │ │ ├── [-rw-rw---- sftpuser] Sales_Diagnostic_Shipped_Cogs.csv
│ │ │ │ └── [-rw-rw---- sftpuser] Sales_Diagnostic_Shipped_Revenue.csv
$lsattr /mnt/file-server/reports/vendor/client/2018/ | grep 02-04
-------------e-- ./02-04-02-10
$stat /mnt/file-server/reports/vendor/client/2018/02-04-02-10/
File: ‘02-04-02-10/‘
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 97eh/2430d Inode: 15335547 Links: 2
Access: (2770/drwsrws---) Uid: ( 2001/ fps) Gid: ( 1006/sftpusers)
Access: 2018-03-19 10:03:34.657116835 -0600
Modify: 2018-03-19 10:03:43.743147764 -0600
Change: 2018-03-19 17:40:03.574287737 -0600
Birth: -
Root kann Dateien schreiben/rmen, kein Problem.
Hier ist ein Beispiel für einen Benutzer und den Versuch, eine Datei zu berühren:
id -a uid=3009(seanhadmin) gid=3009(seanhadmin) groups=3009(seanhadmin),1006(sftpusers)
touch /mnt/file-server/reports/vendor/client/2018/02-04-02-10/foo touch: cannot touch ‘/mnt/file-server/reports/vendor/client/2018/02-04-02-10/foo’: Permission denied
$df -h | grep file-server
/dev/md126 4.0T 1.3T 2.6T 33% /mnt/file-server
Was in aller Welt übersehe ich? Aus reiner Verzweiflung habe ich sogar den Server neu gestartet (natürlich hat das das Problem nicht behoben).
AKTUALISIEREN
Also, ich habe festgestellt, dass mit meinen ACLs etwas nicht stimmt.
So sieht eine gute ACL aus:
$getfacl 01-07-01-13/
file: 01-07-01-13/
owner: fps
group: sftpusers
flags: ss-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:group:sftpusers:rwx
default:mask::rwx
default:other::---
Hier ist02-04-02-10
getfacl 02-04-02-10/
file: 02-04-02-10/
owner: fps
group: sftpusers
flags: -s-
user::rwx
group::r-x
group:2000:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:sftpusers:rwx
default:mask::rwx
default:other::---
Egal, was ich probierte, ich konnte es nicht richtig aktualisieren. Als Workaround habe ich das Verzeichnis in ein anderes Dateisystem verschoben, dann zurück und dann die Berechtigung/Eigentümerschaft erneut korrigiert.
Wenn jemand eine Lösung dafür hat, warum die ACL nicht aktualisiert wird, würde ich sie gerne hören.
Antwort1
Die Problemumgehung bestand darin, das übergeordnete Verzeichnis in das Problemverzeichnis in ein anderes Dateisystem zu kopieren, es dann wieder an seinen ursprünglichen Platz zurückzukopieren und die Berechtigungen/Eigentümerschaft zu korrigieren.
Ich konnte das Setfacl-Problem nicht beheben, da die Problemverzeichnisse rm'd waren.
Falls es jemanden interessiert, die Befehle, die ich ausgeführt habe, waren:
$setfacl -Rd --set u:fps:rwx 02-04-02-10 $setfacl -Rd --set g:sftpusers:rwx 02-04-02-10 $setfacl -Rdm o::0 02-04-02-10