У меня есть настройка NFS4 с правильной работой idmapd. ls -l от клиента показывает правильные имена пользователей, даже если идентификаторы пользователей на разных машинах различаются.
Однако, когда идентификаторы пользователей не совпадают, я получаю сообщение об ошибке «В разрешении отказано» при попытке доступа к файлам, даже если ls -l показывает правильное имя пользователя. Когда идентификаторы пользователей совпадают случайно, все работает нормально.
sudo sysctl -w sunrpc.nfsd_debug=1023 дает следующий вывод в системном журнале сервера для неудачного доступа к файлу:
nfsd_dispatch: vers 4 proc 1
nfsv4 compound op #1/3: 22 (OP_PUTFH)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsv4 compound op ffff88003d0f5078 opcnt 3 #1: 22: status 0
nfsv4 compound op #2/3: 3 (OP_ACCESS)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
nfsv4 compound op ffff88003d0f5078 opcnt 3 #2: 3: status 0
nfsv4 compound op #3/3: 9 (OP_GETATTR)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
nfsv4 compound op ffff88003d0f5078 opcnt 3 #3: 9: status 0
nfsv4 compound returned 0
nfsd_dispatch: vers 4 proc 1
nfsv4 compound op #1/7: 22 (OP_PUTFH)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsv4 compound op ffff88003d0f5078 opcnt 7 #1: 22: status 0
nfsv4 compound op #2/7: 32 (OP_SAVEFH)
nfsv4 compound op ffff88003d0f5078 opcnt 7 #2: 32: status 0
nfsv4 compound op #3/7: 18 (OP_OPEN)
NFSD: nfsd4_open filename dom_file op_stateowner (null)
renewing client (clientid 4f96587d/0000000e)
nfsd: nfsd_lookup(fh 28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba, dom_file)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
nfsd: fh_lock(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba) locked = 0
nfsd: fh_compose(exp 08:01/22806529 srv/dom_file, ino=22809724)
nfsd: fh_verify(36: 01070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
fh_verify: srv/dom_file permission failure, acc=804, error=13
nfsv4 compound op ffff88003d0f5078 opcnt 7 #3: 18: status 13
nfsv4 compound returned 13
Это кому-нибудь полезно? Будем очень признательны за любые подсказки по отладке.
Server kernel: 2.6.32-40-server (Ubuntu 10.04)
Client kernel: 3.2.0-27-generic (Ubuntu 12.04)
Та же проблема с моим новым сервером. 3.2.0-27-generic (Ubuntu 12.04).
Спасибо.
NFSv4 использует строковые принципы utf8 между клиентом и сервером. В результате достаточно использовать одни и те же имена пользователей и домен nfs4 на клиенте и сервере. Идентификаторы могут быть разными. НО .... Если вы используете AUTH_SYS (монтируете с sec = sys, что по умолчанию), ваши запросы RPC вместо принципала kerberos будут использовать uid и gids с клиентского хоста. В этом случае, если uid на клиенте и сервере различаются, вы получите отказ в доступе. В случае RPCGSS_SEC ваш принципал kerberos отправляется, и на сервере будет использоваться тот же idmapd для сопоставления его с локальным uid и gids. ls -l работает так, как ожидалось, поскольку он использует idmapd для сопоставления идентификаторов владельцев файлов и групп принципалам, которые позже отправляются клиенту.