чем заменить name_to_handle_at и open_by_handle_at

Я сходу не могу понять, зачем они вообще нужны userspace демону.

TL;DR

These system calls are designed for use by user-space file servers. For example, a user- space NFS server might generate a file handle and pass it to an NFS client. Later, when the client wants to open the file, it could pass the handle back to the server. This sort of functionality allows a user-space file server to operate in a stateless fashion with respect to the files it serves.

TL;DR

Варианта пожалуй три:

1. Разрешить name_to_handle_at, open_by_handle_at и CAP_DAC_READ_SEARCH для контейнера.
2. вынуть ганешу из докера.
3. спрыгнуть с nfs.

1. пробовал все сценарии включая –privileged, всё равно ругается на

2. хочется сохранить эту возможность.

3. какие альтернативы для бездискового клиента?

проблема то не в Operation not permitted, а Operation not supported.

В докере overlayfs, а с этой фс не работают эти вызовы

ехал докер, через докер, видит докер в докере докер, сунул докер в докер докер …докер докер докер докер

зачем докер?

проблема то не в Operation not permitted, а Operation not supported.

Тогда понятно, а то уже хотел твои руки поругать )

В докере overlayfs, а с этой фс не работают эти вызовы

Ну наверное тебе не нужны оверлеи для файловой системы экспортируемой через nfs?

В целом, если нужна read-only раздача через nfs/cifs с минимизацией рисков взлома, то (imho) лучше сделать в гипервизоре с полностью read-only данными (все изменяемое только в памяти). Как вариант OpenBSD или последнее ядро с lockdown и fs-verify.

Используй докер с сторадж драйвером devicemapper вместо overlay2. Этот драйвер использует thin provision снапшоты с обычными ext4 или xfs внутри.

ага, попробую devicemapper.

докер для того, чтобы дать коллеге пачку софта одной командой.

Так что с «кактусом», получилось? Зацвел?

нет

https://github.com/nfs-ganesha/nfs-ganesha/issues/511#issuecomment-560523801

авторы единственного работающего userspace NFS сервера рассказывают, что они готовы защищать невозможность работы NFS сервера из под докера любой ценой.

Как по мне, так какие-то странные аргументы. Можно пойти и напрогать костыли, всё таки это докер и бодаться с ним мягко говоря странно.

По сути надо запилить костыль вокруг недоступности нужных вызовов в overlay и сделать всё на простых колхозных open/pread, не выежываясь с всякими там непонятными handle_at

ffilz многобуквенно, но достаточно точно описал ситуацию.

Переход между stateless и statefull всегда болезнен, порождает массу регресов и трудоемок в тестировании. Поэтому крайне маловероятно, что кто-то решится гвоздями прибивать в этом месте statefull только ради того, чтобы ганеша заработал поверх overlayfs. Наверное даже проще поддержать open_by_handle_at в overlayfs, нежели калечить sateless-часть nfs-сервера.

Думаю тебе придется отказаться от overlayfs (использовать devicemapper), либо отказаться от doker-а, либо от nfs (использовать smb/cifs).

Хотя вот подумалось - а ты пробовал собрать ганешу без болезненных open_by_handle_at и т.п.?

Эти системные вызовы есть не везде, а ганеша вроде-бы работает не только на linux. Соответственно, вполне возможно что достаточно покалечить какой-нибудь configure или CMakeLists.txt чтобы open_by_handle_at с друзьями считался отсутствующим.

я краем глаза посмотрел — надо переписывать ганешу.

Тоже глянул (пока другой мой тест работал).

Гипотетически можешь попробовать собрать дремучую версию возле тега version_1_0_3, когда этих syscall-ов еще не было.

Но использовать это можно только в доверенной среде (как telnet для рута и без пароля).

о, спасибо