En primer lugar, sí, el directorio principal tiene los permisos correctos. Ahora que eso está fuera del camino, este es el trato.
Mis usuarios no pueden escribir ni hacer rm desde/mnt/file-server/reports/vendor/client/2018/02-04-02-10/
Todos los usuarios son miembros del grupo sftpusers. Todos los directorios que conducen deben 02-04-02-10tener los mismos permisos. Cada usuario puede escribir/rm un archivo/directorio en CADA directorio, excepto si el archivo/directorio está en el 02-04-02-10directorio.
$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 puede escribir archivos/rm, no hay problema.
A continuación se muestra un ejemplo de un usuario y el intento de tocar un archivo:
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
¿Qué diablos me estoy perdiendo? Incluso reinicié el servidor por pura desesperación (por supuesto, no lo solucionó).
ACTUALIZAR
Entonces encontré algo raro con mis ACL.
Así es como se ve una buena ACL:
$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::---
Aquí está02-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::---
No importa lo que intenté, no pude actualizarlo correctamente. Como solución alternativa, moví el directorio a un sistema de archivos diferente, luego lo moví hacia atrás y luego corrigí el permiso/propiedad nuevamente.
Si alguien tiene una solución de por qué la ACL no se actualiza, me encantaría escucharla.
Respuesta1
La solución fue copiar el directorio principal al directorio problemático en otro sistema de archivos, luego copiarlo nuevamente en su lugar y corregir los permisos/propiedad.
No pude solucionar el problema de setfacl porque los directorios problemáticos estaban solucionados.
Si alguien tiene curiosidad, los comandos que ejecuté fueron:
$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