Во-первых, да, родительский каталог имеет правильные разрешения. Теперь, когда с этим разобрались, вот в чем дело.
Мои пользователи не могут писать или изменять данные/mnt/file-server/reports/vendor/client/2018/02-04-02-10/
Все пользователи являются членами группы sftpusers. Каждый каталог, ведущий к, 02-04-02-10имеет одинаковые разрешения. Каждый пользователь может записывать/изменять файл/каталог в КАЖДОМ каталоге, за исключением случаев, когда файл/каталог находится в каталоге 02-04-02-10.
$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 может записывать/изменять файлы, проблем нет.
Вот пример пользователя и попытки доступа к файлу:
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
Что я упускаю? Я даже перезагрузил сервер от отчаяния (конечно, это не помогло).
ОБНОВЛЯТЬ
Итак, я обнаружил что-то странное в своих ACL.
Вот как выглядит хороший 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::---
Вот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::---
Что бы я ни пытался, мне не удалось заставить его корректно обновиться. В качестве обходного пути я переместил каталог в другую файловую систему, затем переместил его обратно, а затем снова исправил разрешение/владельца.
Если у кого-то есть решение, почему ACL не обновляется, я был бы рад его услышать.
решение1
Обходной путь состоял в том, чтобы скопировать родительский каталог проблемного каталога в другую файловую систему, а затем скопировать его обратно на место и исправить разрешения/владельца.
Мне не удалось устранить проблему с setfacl, поскольку проблемные каталоги были удалены.
Если кому-то интересно, вот команды, которые я запускал:
$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