Ubuntu24.04 NFS

よくよく考えてみると、Ubuntuを長く使っているのに、NFSを使ったことがなかったような気がする。

今回、Ubuntu Desktop 24.04 LTSをインストールして使い始めたのだけれど、ストレージサーバーの役割をしているUbuntu Server 24.04 LTSや22.04のフォルダをマウントしたくなったので、設定してみることにした。

ここから広告

広告ここまで

NFSについて

概要

今更だけど、知らない。Geminiさんに聞いてみた。

NFS（Network File System）は、ネットワーク経由でリモートのファイルシステムを共有するためのプロトコルです。ローカルのディスクにアクセスするのと同じ感覚で、別のコンピュータのファイルやディレクトリにアクセスできるようになります。

NFSとよく比較されるのが、主にWindowsで使われるSamba/CIFSです。
NFSとSambaはどちらもファイル共有を実現しますが、歴史的背景と設計思想が異なるため、それぞれ得意な環境が異なります。NFSはUNIX/Linux環境でより一般的であり、SambaはWindowsとの互換性を重視する環境で使われます。

また、認証については、NFSはUID/GIDベース、Samba/CIFSはユーザ名/パスワードベースであることも教えてくれた。

実際にやってみたところ、

サーバー側でディレクトリを公開する。
- 公開範囲はIPアドレス範囲やホスト名で決めることができる。
- どのような形のアクセスをさせるのかをエクスポートオプションで決める。
  - 読み書き可能 or 読み取り専用
  - 同期 or 非同期
  - アクセスしてきた人のUID/GIDの取り扱い(nobody:nogroup or そのまま)
  - Kerberosによるセキュリティ設定
  - とかとか
クライアントからアクセスする。
- mountコマンドでマウント。オプションとしてサーバーにあわせたパラメーターをセット。
- Kerberos認証を利用する場合は、チケットを取得してアクセス。

といった具合だった。

バージョン

Geminiさんに各バージョンの違いを聞いてみた。

特徴	NFSv2	NFSv3	NFSv4	備考
リリース年	1989	1995	2003
プロトコル	UDP	UDP/TCP	TCP
ファイルサイズ	2GB制限	制限なし	制限なし
セキュリティ	限定的	部分的サポート*1	組み込み*2	1 Kerberosのようなより高度なセキュリティメカニズムを部分的にサポート 2 Kerberos認証が標準化
ステート	ステートレス	ステートレス	ステートフル*3	*3 セッション維持、サーバー再起動後に自動的に接続を復元
複合操作	なし	なし	あり*4	*4 複数の操作を1つのRPCコールにまとめることが可能
ファイアウォール	困難	困難	容易

NFSv4では以下が追加された、とも教えてくれた。

ユーザーIDマッピング
ACL (Access Control List)
ロック管理の統合
NFSv4.1ではpNFS (Parallel NFS) が導入され、より大規模な環境でのパフォーマンスが向上しました。

見る限り、NFSv4利用一択のようだ。

連携するサービス達

nfs-kernel-serverにはこんなサービスが入っていた。

ユニット	概要
fsidd.service	NFS FSID Daemon
nfs-blkmap.service	pNFS block layout mapping daemon
nfs-mountd.service	NFS Mount Daemon
nfs-server.service	NFS server and services
nfsdcld.service	NFSv4 Client Tracking Daemon

nfs-commonにはこんなサービスが入っていた。
このパッケージは、サーバーをインストールすると一緒にインストールされる。

ユニット	概要
auth-rpcgss-module.service	Kernel Module supporting RPCSEC_GSS
nfs-client.target	NFS client services
nfs-idmapd.service	NFSv4 ID-name mapping service
nfs-utils.service	NFS server and client services
proc-fs-nfsd.mount	NFSD configuration filesystem
rpc-gssd.service	RPC security service for NFS client and server
rpc-statd-notify.service	Notify NFS peers of a restart
rpc-statd.service	NFS status monitor for NFSv2/3 locking.
rpc-svcgssd.service	RPC security service for NFS server

ここにあるサービスの定義を開けてみて、以下の形式でサービスの関係を線で結んでみた。

┌─────────┐
│依存されるサービス│
└────┬────┘
          │
┌────┴────┐
│ 依存するサービス │
└─────────┘

パッケージをインストールする時に生成されるものもあるかもしれないが、その辺りは追えていない。
見えているところだけのサービスの関係性を書き出してみた(図形の操作ミスで線が間違っている可能性も…)。

BindToやPartOfは、依存されているそのサービスが再起動すると、依存しているサービスも再起動されるようになっているそうな。
これで行くと、サーバーにおいては、nfs-serverとnfs-utilを再起動、クライアントにおいてはnfs-utilを再起動すると、設定変更がサービスに伝わるように見える。

サーバーの公開設定

NFSのクライアントに公開するファイルシステムは、/etc/exports、あるいは、/etc/exports.d/hoge.exportsで指定する。
パッケージをインストールしてみて、設定ファイルを見てみた。

$ sudo apt install nfs-kernel-server

インストール直後の/etc/exports

# /etc/exports: the access control list for filesystems which may be exported
#		to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#

NFSv2とNFSv3のサンプルとして、以下が書かれていた。

/srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
~~~(1)~~~~       ~~~(2)~~~ ~~~~~~~~~~(3)~~~~~~~~~~~  ~~~~~~~~~~~~~~~~(4)~~~~~~~~~~~~~~~~

エクスポートポイント
エクスポートポイントをマウントできるクライアント
- リゾルバが認識できるホスト名、ワイルドカード(*と?)を用いたホスト名、NISのネットグループ、IPアドレスとネットマスク(address/netmask)で指定可能。
エクスポートオプション(クライアント名とオプションの間にスペースを入れてはいけない)
スペースで区切ってマウントできるクライアントを複数指定

NFSv4のサンプルとして、以下が書かれていた。

/srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)

このように、"gss/krb5"、"gss/krb5i"、または"gss/krb5p"という特別な文字列を使用して、RPCSEC_GSSセキュリティを使用できるが、この構文は非推奨と書かれている。

新しい書き方は sec= での指定で、以下のフレーバーを使用する順に指定する。

sys: デフォルト(暗号化セキュリティなし)
krb5: 認証のみ、安全な通信経路で使えばパフォーマンスが良い
krb5i: 完全性保護(データの改ざん防止)
krb5p: プライバシー保護(データの暗号化)、安全だけどパフォーマンスが良くない

ro、rw、no_root_squash、root_squash、およびall_squashだけは、フレーバーごとのオプションが指定可能。

ユーザーIDマッピング

サーバーにあるファイルにアクセスする時、どのUID/GIDでアクセスするのかが重要。

Geminiさんに聞いてみたところ、

all_squashと設定すると、rootを含むすべてのユーザーはannonymous uid/gidにマッピングされる。
no_all_squash(これがデフォルト)と設定すると、要求通りのUID/GIDで利用できる。
rootだけはroot_squashでマッピングさせることができる。

ということだった。

マッピング先のデフォルトは-2だそうで、Ubuntuだとnobodyにマッピングされる。

$ id nobody
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

テスト環境

ホームラボにはSamba AD DCがあるので、セキュリティあり・なしの両方を試してみることにした。

ホスト名	IPアドレス	役割	備考
addc.hogeserver.hogeddns.jp	192.168.110.10	Samba AD DC	Ubuntu 22.04 Server + DockerでSamba AD DC レルム HOGESERVER.HOGEDDNS.JP、ドメイン HOGEDOMAIN
u2404s.hogeserver.hogeddns.jp	192.168.110.14	NFSサーバー	Ubuntu 24.04 Server Samba AD DCに参加
u2404d.hogeserver.hogeddns.jp	<DHCPで払い出し>	NFSクライアント	Ubuntu 24.04 Desktop Samba AD DCに参加

最初、サーバー(u2404s)はADに参加していたが、クライアント(u2404d)はADに参加していなかった。

しかし、Kerberosによるセキュリティを利用する場合には、

自ホストのコンピューターアカウントでチケットを取得し、それを使って公開されたディレクトリをマウント
ユーザーアカウントでチケットを取得し、マウントされたディレクトリにアクセス

という手順になるため、特に前者のためにADへの参加が必要だった。
そして後者は、ドメインユーザーでログインしていると自動で行われて楽だったりもする。

そのため、過去に整理した手順でADに参加した。ただし、

IPアドレスの固定とhostsの設定はしていない。
smb.confのinterfacesにはインターフェース名(ens33)を指定している。

等、いくつかの手順をクライアント環境っぽく変更している。

NFSv4 sec=sys

普通に考えると、これがよく使われる形なのではないかと。

サーバー側の設定

パッケージをインストールする。

$ sudo apt install nfs-kernel-server

公開用のディレクトリを作成する。テストを兼ねている。

$ sudo mkdir -p /srv/nfsv4/{squash,nosquash}
$ sudo chown nobody:nogroup /srv/nfsv4 /srv/nfsv4/squash
$ sudo chmod 777 /srv/nfsv4/nosquash/
$ ll /srv/nfsv4/
total 16
drwxr-xr-x 4 nobody nogroup 4096 Sep 27 07:49 ./
drwxr-xr-x 3 root   root    4096 Sep 27 07:49 ../
drwxrwxrwx 2 root   root    4096 Sep 27 07:49 nosquash/
drwxr-xr-x 2 nobody nogroup 4096 Sep 27 07:49 squash/

公開用のディレクトリの公開方法を設定する。

/etc/exports

#/srv/nfsv4		u2404d(sec=sys,ro,fsid=0,no_subtree_check,insecure,all_squash)
/srv/nfsv4/squash	u2404d(sec=sys,rw,no_subtree_check,insecure,all_squash)
/srv/nfsv4/nosquash	u2404d(sec=sys,rw,no_subtree_check,insecure,no_all_squash,no_root_squash)

fsid=0については、

設定すると共有のルートディレクトリになり、例えば/srv/nfsv4/squashをマウントする場合には/squashでマウントするようになる。
上のように ro を指定すると、サブディレクトリはすべて ro の状態になる。

といった具合で、最上位のディレクトリを指定するもので、共有全体の基本設定を決めるようだ。

設定を反映させる。

$ sudo systemctl restart nfs-server
$ sudo exportfs -v
/srv/nfsv4/squash
                u2404d.hogeserver.hogeddns.jp(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,root_squash,all_squash)
/srv/nfsv4/nosquash
                u2404d.hogeserver.hogeddns.jp(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,no_root_squash,no_all_squash)

続いてポートを開放する。

$ sudo ufw allow nfs
Rule added
Rule added (v6)

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
2049                       ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
2049 (v6)                  ALLOW       Anywhere (v6)

これで共有ができる。

クライアント側の設定

クライアント側は、nfs-clientというパッケージがあるのかと思ったら、nfs-commonに変わっているようだ。
mount.nfsとかidmapdが入っているので、このパッケージをインストールすればマウントができそう。

$ apt show nfs-common
Package: nfs-common
Version: 1:2.6.4-3ubuntu5.1
...
Description: クライアントとサーバに共通の NFS サポートファイル
 NFS を使うマシンは、クライアントまたはサーバのどちらであっても本パッケージ を使ってください。含まれているプログラム: lockd,
 statd, showmount, nfsstat, gssd, idmapd, mount.nfs

パッケージをインストールする。

$ sudo apt install nfs-common

squashをマウントしてテストしてみる。

$ sudo mount -t nfs4 -o sec=sys u2404s.hogeserver.hogeddns.jp:/srv/nfsv4/squash /mnt

$ touch /mnt/squash_1000
$ sudo touch /mnt/squash_0

$ ll /mnt
合計 8
drwxr-xr-x  2 nobody nogroup 4096  9月 27 09:58 ./
drwxr-xr-x 23 root   root    4096  9月 22 11:09 ../
-rw-r--r--  1 nobody nogroup    0  9月 27 09:58 squash_0
-rw-rw-r--  1 nobody nogroup    0  9月 27 09:58 squash_1000

$ sudo umount /mnt

nosquashをマウントしてテストしてみる。

$ sudo mount -t nfs4 -o sec=sys u2404s.hogeserver.hogeddns.jp:/srv/nfsv4/nosquash /mnt

$ touch /mnt/nosquash_1000
$ sudo touch /mnt/nosquash_0

$ ll /mnt
合計 8
drwxrwxrwx  2 root   root   4096  9月 27 10:00 ./
drwxr-xr-x 23 root   root   4096  9月 22 11:09 ../
-rw-r--r--  1 root   root      0  9月 27 10:00 nosquash_0
-rw-rw-r--  1 rohhie rohhie    0  9月 27 10:00 nosquash_1000

サーバーのnosquashで、/etc/ssl/private/ssl-cert-snakeoil.keyのリンクを作って中身を見てみた。

どちらも、rootでのアクセスでないと中身が見えない。
シンボリックリンクの場合、クライアントではクライアントのssl-cert-snakeoil.keyが見える。
ハードリンクの場合、クライアントからサーバーのssl-cert-snakeoil.keyが見える。

こういった動きを意識して共有設定をすれば便利に使えそうだ。

NFSv4 sec=krb5p

Kerberos認証を使った場合の共有についても試してみた。
あんまり情報がない、あるいは、高度な表現だったりして理解ができず、かなり時間がかかってしまった。

大まかにはこのような手順。どちらもドメインに参加している前提。

サーバー側
- Samba AD DCでサーバーのSPNを追加し、キータブを取り出す。
- サーバーでキータブを登録し、いくつかのKerberosサーバーとしての設定と、idmapdの設定をする。
- sec=krb5pでディレクトリを公開する。
クライアント側
- Samba AD DCでコンピューターのキータブを取り出す。
- クライアントでキータブを登録し、idmapdの設定をする。
- コンピューターのキーターブを使い、sec=krb5pでマウントする。
- ユーザーのキーを使い、実際にディレクトリやファイルへアクセスする。

やっぱりちょっと複雑ではある。

サーバー側の設定(Samba AD DC)

ホームラボのSamba AD DCはDockerで稼働しているので、中に入っていって操作する。

$ sudo docker exec -it samba bash --login

Samba AD DCで、NFSのサービスプリンシパルネームを作成する。

# samba-tool spn add nfs/u2404s.hogeserver.hogeddns.jp u2404s$
# samba-tool spn list u2404s$
u2404s$
User CN=U2404S,CN=Computers,DC=hogeserver,DC=hogeddns,DC=jp has the following servicePrincipalName:
         HOST/U2404S.hogeserver.hogeddns.jp
         RestrictedKrbHost/U2404S.hogeserver.hogeddns.jp
         HOST/U2404S
         RestrictedKrbHost/U2404S
         nfs/u2404s.hogeserver.hogeddns.jp

キータブを取り出す。

# samba-tool domain exportkeytab nfs.keytab --principal=nfs/u2404s.hogeserver.hogeddns.jp
# klist -tke nfs.keytab
Keytab name: FILE:nfs.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 09/21/2025 13:14:20 nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96)
   1 09/21/2025 13:14:20 nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96)
   1 09/21/2025 13:14:20 nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (DEPRECATED:arcfour-hmac)

これをホストに取り出して、サーバーにコピーする。

$ sudo docker cp samba:/nfs.keytab ./
$ sudo chown rohhie:rohhie nfs.keytab
$ scp nfs.keytab u2404s:/home/rohhie

$ sudo docker exec samba rm /nfs.keytab
$ rm nfs.keytab

ラボのPCは自分でしか使わないから残しておいても害はないけれど、みんなで使うような環境ではキータブを削除しておくのがよろしいかと。

サーバー側の設定

※ドメインに参加しているので、SambaやKerberos関連のパッケージはインストール済みとして進める。

多くのシステムがデフォルトで利用するという/etc/krb5.keytabは、このサーバーには作られていなかった。
この場合はファイルをコピーするだけでもOK。

だけど、もしも元々サービスを提供している場合にはキータブを追加するのだろうから、その手順を試してみた。

ktutilというツールを使うが、考え方としては、

追加したいキータブを読み込む。リストで見られるようになる。
不要な鍵を削除して、追加したい鍵のみリストに残す。
/etc/krb5.keytabに追加書き込みする(上書きにはならない、必ず追加書き込みになる)

ということだった。

今回はすべての鍵を、新しく/etc/krb5.keytabを作って書き込むので操作は以下の通りとなった。
Geminiさんに教えてもらいながら進める。

$ sudo ktutil
ktutil:  read_kt nfs.keytab
ktutil:  list -t -e
slot KVNO Timestamp         Principal
---- ---- ----------------- ---------------------------------------------------
   1    1 09/21/2025 13:14  nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96)
   2    1 09/21/2025 13:14  nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96)
   3    1 09/21/2025 13:14  nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (arcfour-hmac)
ktutil:  write_kt /etc/krb5.keytab
ktutil:  quit

$ ll /etc/krb5.keytab
-rw------- 1 root root 315 Sep 21 14:47 /etc/krb5.keytab

$ sudo klist -tke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 09/21/2025 14:47:56 nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96)
   1 09/21/2025 14:47:56 nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96)
   1 09/21/2025 14:47:56 nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP (DEPRECATED:arcfour-hmac)

scpで持って来たキータブは削除しておく。

パッケージをインストールする。

$ sudo apt install nfs-kernel-server

公開用のディレクトリを作成する。

$ sudo mkdir -p /srv/nfsv4/krb5/{local-rohhie,rohhie,hoge,piyo}

$ sudo chown rohhie:rohhie /srv/nfsv4/krb5/local-rohhie
$ sudo chown 'HOGEDOMAIN\rohhie:HOGEDOMAIN\domain users' /srv/nfsv4/krb5/rohhie
$ sudo chown 'HOGEDOMAIN\hoge:HOGEDOMAIN\domain users' /srv/nfsv4/krb5/hoge
$ sudo chown 'HOGEDOMAIN\piyo:HOGEDOMAIN\domain users' /srv/nfsv4/krb5/piyo
$ sudo chmod -R 750 /srv/nfsv4/krb5/*

$ ll /srv/nfsv4/krb5/
total 24
drwxr-xr-x 6 root              root                    4096 Sep 27 15:26 ./
drwxr-xr-x 5 nobody            nogroup                 4096 Sep 27 14:09 ../
drwxr-x--- 2 HOGEDOMAIN\hoge   HOGEDOMAIN\domain users 4096 Sep 27 14:09 hoge/
drwxr-x--- 2 rohhie            rohhie                  4096 Sep 27 14:09 local-rohhie/
drwxr-x--- 2 HOGEDOMAIN\piyo   HOGEDOMAIN\domain users 4096 Sep 27 14:09 piyo/
drwxr-x--- 2 HOGEDOMAIN\rohhie HOGEDOMAIN\domain users 4096 Sep 27 15:21 rohhie/

ドメインにrohhieというユーザーはいるのだけど、名前でIDがマッピングされるとのことで、サーバー側のrohhieにマッピングされる。
rohhieはそのまま使うとして、hogeとpiyoについてはドメインユーザーを利用することにした。

公開用のディレクトリの公開方法を設定する。
Kerberosによる安全な認証が前提になるから、ネットワーク全体からのアクセスを許可してみた。

/etc/exports

/srv/nfsv4/krb5		192.168.110.0/24(sec=krb5p,rw,no_subtree_check,insecure)

Kerberos認証が使えるようにする。

/etc/default/nfs-kernel-server

# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0

# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD="yes"

ユーザー名をIDにマッピングさせる方法の設定。

/etc/idmapd.conf

[General]

Verbosity = 0
# set your own domain here, if it differs from FQDN minus hostname
# Domain = localdomain
Domain = hogeserver.hogeddns.jp

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

設定を反映させる。

$ sudo systemctl restart nfs-server

$ sudo exportfs -v
/srv/nfsv4/squash
                u2404d.hogeserver.hogeddns.jp(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,root_squash,all_squash)
/srv/nfsv4/nosquash
                u2404d.hogeserver.hogeddns.jp(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,no_root_squash,no_all_squash)
/srv/nfsv4/krb5
                192.168.110.0/24(sync,wdelay,hide,no_subtree_check,sec=krb5p,rw,insecure,root_squash,no_all_squash)

ポートを開放する。

$ sudo ufw allow nfs
Rule added
Rule added (v6)

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
2049                       ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
2049 (v6)                  ALLOW       Anywhere (v6)

追加で1つ、Sambaの状態を確認。

/etc/samba/smb.conf

winbind use default domain = yes

これがないと、接続してきたユーザーのIDが正しくマッピングされず、nobody:nogroupになってしまう。
ローカルユーザーと同じ名前を持つドメインユーザーがいると、ドメインユーザーのグループにも所属していることになってしまう弊害があるけれど、他に指定する方法を見つけることができなかった。

詳細は後述。

設定を変更した場合には反映させる。

$ sudo systemctl restart nmbd

サーバー側の設定ができた。

クライアント側の設定(Samba AD DC)

Samba AD DCでコンピューターのキータブを取り出すため、Samba AD DCに入る。

$ sudo docker exec -it samba bash --login

コンピューターのキータブを取り出す。

# samba-tool domain exportkeytab u2404d.keytab --principal=u2404d$
Export one principal to u2404d.keytab

# klist -tke u2404d.keytab
Keytab name: FILE:u2404d.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 09/22/2025 18:20:38 u2404d$@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96)
   1 09/22/2025 18:20:38 u2404d$@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96)
   1 09/22/2025 18:20:38 u2404d$@HOGESERVER.HOGEDDNS.JP (DEPRECATED:arcfour-hmac)

--principalにsAMAccountNameであるU2404D$を指定するのが肝。
取り出したキータブはrpc.gssdが見つけて処理をしてくれるが、このやり方以外のものは、名前を合わせても上手く使えない。

これを見つけるのがことのほか大変だった…多分、今までにやったことがなかった操作だった。

これをホストに取り出して、サーバーにコピーする。

$ sudo docker cp samba:/u2404d.keytab ./
$ sudo chown rohhie:rohhie u2404d.keytab
$ scp u2404d.keytab u2404d:/home/rohhie

$ sudo docker exec samba rm /u2404d.keytab
$ rm u2404d.keytab

こちらも作業用のキータブは削除しておいた。

クライアント側の設定

※ドメインに参加しているので、SambaやKerberos関連のパッケージはインストール済みとして進める。

コンピューターのキータブを/etc/krb5.keytabに追加する。
まだないようなら、ファイルをコピーしても問題はない。

$ sudo ktutil
ktutil:  rkt u2404d.keytab
ktutil:  l -t -e
slot KVNO Timestamp         Principal
---- ---- ----------------- ---------------------------------------------------
   1    1 2025-09-22T18:20            u2404d$@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96) 
   2    1 2025-09-22T18:20            u2404d$@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96) 
   3    1 2025-09-22T18:20            u2404d$@HOGESERVER.HOGEDDNS.JP (arcfour-hmac) 
ktutil:  wkt /etc/krb5.keytab
ktutil:  quit

$ sudo klist -tke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 2025-09-22T18:26:46 u2404d$@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96) 
   1 2025-09-22T18:26:46 u2404d$@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96) 
   1 2025-09-22T18:26:46 u2404d$@HOGESERVER.HOGEDDNS.JP (DEPRECATED:arcfour-hmac)

nfs-commonにはidmapdが入っているし、試行錯誤の最中はIDマッピングができていた。
しかし、それを終えてログを戻し、最終確認をしていたら、ドメインユーザーの持ち物がすべてnobody:nogroupで表示されている。

nfs-idmapdが動いていない。
nfs-idmapdはnfs-serverと一緒に動くように設定されているから、nfs-kernel-serverが動いていなければならない。
だから起動できない。

色々とやり過ぎていて、何故いままでIDマッピングができていたのかが分からない…

ということで、IDマッピングを動かすために、クライアントなんだけれどもサーバーをインストールする。
一緒にクライアントもインストールされる。

$ sudo apt install nfs-kernel-server

もし、rpc-gssdが停止しているようなら起動する。
/etc/krb5.keytabがないと終了してしまうようだ。今書いている手順なら起動しているかもしれない。

$ sudo systemctl start rpc-gssd

IDマッピングをするための設定。

/etc/default/nfs-common

...
NEED_IDMAPD=yes
...

/etc/idmapd.conf

[General]

Verbosity = 0
# set your own domain here, if it differs from FQDN minus hostname
# Domain = localdomain
Domain = hogeserver.hogeddns.jp

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

設定の変更を反映させる。

$ sudo systemctl restart nfs-utils nfs-server

Sambaの状態を確認。

/etc/samba/smb.conf

winbind use default domain = yes

設定を変更した場合には反映させる。

$ sudo systemctl restart nmbd

これで準備は整ったので、実際にアクセスしていく。

クライアントからのアクセス

まず、コンピューターのキータブを使ってサーバーのディレクトリをマウントする。

$ sudo mount -t nfs4 -o sec=krb5p,vers=4.2 u2404s.hogeserver.hogeddns.jp:/srv/nfsv4/krb5 /mnt

アクセスしてみると、この段階ではrootだけがアクセスできる状態になっている。
rootをsquashしているので、nobody:nogroupとして扱われている。

$ ll /mnt
ls: cannot open directory '/mnt': Stale file handle
(日本語環境 ls: ディレクトリ '/mnt' を開くことが出来ません: 古いファイルハンドルです)

$ LANG=en_us.utf-8 ll /mnt
ls: cannot access '/mnt': Permission denied
(エラーの内容が変わる)

$ sudo ll /mnt
合計 24
drwxr-xr-x   6 root   root    4096  9月 27 15:26 ./
drwxr-xr-x  23 root   root    4096  9月 22 11:09 ../
drwxr-x---   2 nobody nogroup 4096  9月 27 14:09 hoge/
drwxr-x---?  2 rohhie rohhie  4096  9月 27 15:40 local-rohhie/
drwxr-x---   2 nobody nogroup 4096  9月 27 14:09 piyo/
drwxr-x---   2 rohhie nogroup 4096  9月 27 15:21 rohhie/

ドメインユーザーpiyoになってアクセスしてみる。

$ su 'HOGEDOMAIN\piyo'
パスワード:

$ ll /mnt ※全員に見えるディレクトリなので見える
合計 24
drwxr-xr-x   6 root   root    4096  9月 27 19:43 ./
drwxr-xr-x  23 root   root    4096  9月 22 11:09 ../
drwxr-x---   2 nobody nogroup 4096  9月 27 14:09 hoge/
drwxr-x---?  2 rohhie rohhie  4096  9月 27 15:40 local-rohhie/
drwxr-x---   2 nobody nogroup 4096  9月 27 14:09 piyo/
drwxr-x---   2 rohhie nogroup 4096  9月 27 15:21 rohhie/

$ touch /mnt/piyo/test ※自分のディレクトリなので読み書きができる
$ ll /mnt/piyo
合計 8
drwxr-x--- 2 nobody nogroup 4096  9月 27 19:46 ./
drwxr-xr-x 6 root   root    4096  9月 27 19:43 ../
-rw-r--r-- 1 nobody nogroup    0  9月 27 19:46 test

$ touch /mnt/rohhie/test ※同じグループなので読むことができる
touch: '/mnt/rohhie/test' に touch できません: 許可がありません
$ ll /mnt/rohhie/
合計 8
drwxr-x--- 2 rohhie nogroup 4096  9月 27 15:21 ./
drwxr-xr-x 6 root   root    4096  9月 27 19:43 ../

$ ll /mnt/local-rohhie/ ※グループ違いなので読むことができない
ls: ディレクトリ '/mnt/local-rohhie/' を開くことが出来ません: 許可がありません

この時のチケットの状態をみると、サーバーのサービス利用ができるようになっていることが分かる。

$ klist
Ticket cache: FILE:/tmp/krb5cc_1008103
Default principal: piyo@HOGESERVER.HOGEDDNS.JP

Valid starting       Expires              Service principal
2025-09-27T19:43:55  2025-09-28T05:43:55  krbtgt/HOGESERVER.HOGEDDNS.JP@HOGESERVER.HOGEDDNS.JP
        renew until 2025-10-04T19:43:55
2025-09-27T19:43:55  2025-09-28T05:43:55  U2404D$@HOGESERVER.HOGEDDNS.JP
        renew until 2025-10-04T19:43:55
2025-09-27T19:44:01  2025-09-28T05:43:55  nfs/u2404s.hogeserver.hogeddns.jp@HOGESERVER.HOGEDDNS.JP
        renew until 2025-10-04T19:43:55

サーバーにもクライアントにもいるrohhie(UID 1000)、かつ、ドメインユーザーでもある場合にどういう取り扱いになるのか。
気になったので調べたが、長くなったので後述する。

以上で、だいたい使えるレベルの設定ができたのではないかと思っている。

起きたこと・調べたこと

かなり色々なことが起きて、この設定手順を確立するまでに相当時間がかかった。
完成のイメージが見えなかったのと、エラーが出たときに原因が分かりにくいのとで本当に大変。

詳細ログの出力

詳細なログは設定をしないと出てこない。
コマンドの実行結果はだいたい Permission denied で原因が掴めない。

ログ出力についてマニュアルで詳細を見つけられなかったので、ネットの情報を見て9とかallを設定。
とにかくdebugとかの文字を見つけたら全部設定してみた。
設定が落ち着いた後で、ログレベルの設定エラーが出ているものを見て手直ししたのが以下。

/etc/nfs.conf

...
[exportfs]
# debug=0
debug=9
...
[gssd]
# verbosity=0
verbosity=9
# rpc-verbosity=0
rpc-verbosity=9
...
[exportd]
# debug="all|auth|call|general|parse"
debug="all"
...
[mountd]
# debug="all|auth|call|general|parse"
debug="all"
...
[nfsdcld]
# debug=0
debug=9
...
[nfsdcltrack]
# debug=0
debug=9
...
[nfsd]
# debug=0
debug=9
...
[statd]
# debug=0
debug=1
...
[sm-notify]
# debug=0
debug=1
...
[svcgssd]
# principal=
verbosity=9
rpc-verbosity=9
idmap-verbosity=9

/etc/idmapd.conf

[General]

Verbosity = 9
...

反映だけれども、恐らくはサーバー側で nfs-server、クライアント側で nfs-utils を再起動すれば良さそうな気がする。
一回再起動するのもいいかもしれない。

新しく記録されるログは、以下で追いかけることができる。

$ journalctl -f

試したところ、一度マウントできてディレクトリやファイルにアクセスした場合、クライアントはチケットを持っていて、サーバー側もキャッシュを持っていてログが出ないものもある。

この場合は、

クライアント側で当該ユーザーのログアウト、アンマウント、nfs-utilsの再起動、サーバー側でnfs-serverの再起動をした
クライアント側でマウント、当該ユーザーで入り直してアクセス

という操作でログが出力される。

Fail2banでBANされていた

ちょっと前にFail2Banについて調べていて、その環境が残ったままだった。
ポートを開放せずにマウントを試したところ、Banされた。

Sep 21 15:48:48 u2404s kernel: [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:f1:40:1f:00:0c:29:7b:90:85:08:00 SRC=192.168.110.178 DST=192.168.110.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26036 DF PROTO=TCP SPT=955 DPT=2049 WINDOW=64240 RES=0x00 SYN URGP=0
Sep 21 15:48:48 u2404s fail2ban[866]: [ufw-port-scan] Found 192.168.110.178 - 2025-09-21 15:48:48
Sep 21 15:48:49 u2404s kernel: [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:f1:40:1f:00:0c:29:7b:90:85:08:00 SRC=192.168.110.178 DST=192.168.110.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26037 DF PROTO=TCP SPT=955 DPT=2049 WINDOW=64240 RES=0x00 SYN URGP=0
Sep 21 15:48:50 u2404s fail2ban[866]: [ufw-port-scan] Found 192.168.110.178 - 2025-09-21 15:48:49
Sep 21 15:48:50 u2404s kernel: [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:f1:40:1f:00:0c:29:7b:90:85:08:00 SRC=192.168.110.178 DST=192.168.110.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26038 DF PROTO=TCP SPT=955 DPT=2049 WINDOW=64240 RES=0x00 SYN URGP=0
Sep 21 15:48:51 u2404s fail2ban[866]: [ufw-port-scan] Found 192.168.110.178 - 2025-09-21 15:48:50
Sep 21 15:48:51 u2404s fail2ban[866]: [ufw-port-scan] Ban 192.168.110.178

mountのパラメーターによっては、プロトコルのバージョンが下がっていき、UDP 111にも接続しに行く。

Sep 21 16:30:06 u2404s kernel: [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:f1:40:1f:00:0c:29:7b:90:85:08:00 SRC=192.168.110.178 DST=192.168.110.14 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=32617 DF PROTO=UDP SPT=48052 DPT=111 LEN=64
Sep 21 16:30:06 u2404s fail2ban[866]: [ufw-port-scan] Found 192.168.110.178 - 2025-09-21 16:30:06
Sep 21 16:30:07 u2404s kernel: [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:f1:40:1f:00:0c:29:7b:90:85:08:00 SRC=192.168.110.178 DST=192.168.110.14 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=32618 DF PROTO=UDP SPT=48052 DPT=111 LEN=64
Sep 21 16:30:07 u2404s fail2ban[866]: [ufw-port-scan] Found 192.168.110.178 - 2025-09-21 16:30:07
Sep 21 16:30:08 u2404s kernel: [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:f1:40:1f:00:0c:29:7b:90:85:08:00 SRC=192.168.110.178 DST=192.168.110.14 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=32619 DF PROTO=UDP SPT=48052 DPT=111 LEN=64
Sep 21 16:30:08 u2404s fail2ban[866]: [ufw-port-scan] Found 192.168.110.178 - 2025-09-21 16:30:08
Sep 21 16:30:08 u2404s fail2ban[866]: [ufw-port-scan] 192.168.110.178 already banned

トラブルシューティングをしているときに役立つかもしれないので特徴を。

かなり待たされる(タイムアウトするまで頑張る)。
Banされた後にUFWを無効にしてもBanの状態は継続していて、接続は遮断され、UFWのログも出ない。
一度接続が確立すると、コネクションは張りっぱなしになるとみられ、ファイアウォールを閉じてもマウントが可能。
サーバー側で、nfs-server.serviceを再起動したら、その後は接続ができなくなる。

設定変更したときに、どのサービスを再起動すれば良いのか分かりづらかった。
なのでサーバーを再起動するのだけれど、Ban状態は復元されるので、状況が変わらない…なかなかに厳しい。

改めてポートを閉じて、試してみると、こんな表示がされて長時間待たされる。

$ sudo mount -v -t nfs4 -o sec=krb5p u2404s.hogeserver.hogeddns.jp:/ /mnt
mount.nfs4: timeout set for Tue Sep 23 06:13:57 2025
mount.nfs4: trying text-based options 'sec=krb5p,vers=4.2,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs4: mount(2): Permission denied
mount.nfs4: trying text-based options 'sec=krb5p,vers=4,minorversion=1,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs4: mount(2): Connection timed out
mount.nfs4: Connection timed out for u2404s.hogeserver.hogeddns.jp:/ on /mnt

Banされた後はこんな表示がされる。Connection refusedは繰り返し表示される。

$ sudo mount -v -t nfs4 -o sec=krb5p u2404s.hogeserver.hogeddns.jp:/ /mnt
mount.nfs4: timeout set for Tue Sep 23 06:22:46 2025
mount.nfs4: trying text-based options 'sec=krb5p,vers=4.2,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs4: mount(2): Permission denied
mount.nfs4: trying text-based options 'sec=krb5p,vers=4,minorversion=1,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs4: mount(2): Connection refused
...
mount.nfs4: Connection refused for u2404s.hogeserver.hogeddns.jp:/ on /mnt

ちょっと指定を変えたところ、こんな表示がされる。

$ sudo mount -v -t nfs u2404s.hogeserver.hogeddns.jp:/ /mnt
mount.nfs: timeout set for Tue Sep 23 06:25:52 2025
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs: mount(2): Input/output error
mount.nfs: mount system call failed for /mnt

Banされた状態からの回復には、これが使える。

$ sudo fail2ban-client unban 192.168.110.178

ホストが再起動するまでFail2Banを止めておくのもいいかもしれない。

$ sudo systemctl stop fail2ban

Fail2Banの監視対象から外すこともできる。

/etc/fail2ban/jail.local

[DEFAULT]
ignoreip = 192.168.110.0/24 127.0.0.1/8 ::1

接続が確立したら改めて有効化すれば良い。

コンピューターのキータブ

サーバー側でSPNを設定し、そのキータブを取り出すことは、過去にやったやり方で問題なくできた。

しかし、クライアント側で使用するコンピューターのキータブは取り出したことがなかった。
マニュアルを見てどんなキータブを求められているのかは分かっても、取り出し方がなかなか見つけられなかった。

失敗例はこれ。その他、どんなやり方でSPNを取り出しても駄目だった。
※Samba AD DCでの操作。

# samba-tool domain exportkeytab u2404d.keytab --principal=host/u2404d
# klist -tke u2404d.keytab
Keytab name: FILE:u2404d.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 09/23/2025 07:29:41 HOST/U2404D@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96)
   1 09/23/2025 07:29:41 HOST/U2404D@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96)
   1 09/23/2025 07:29:41 HOST/U2404D@HOGESERVER.HOGEDDNS.JP (DEPRECATED:arcfour-hmac)

成功したのはこれ。

# samba-tool domain exportkeytab u2404d.keytab --principal=u2404d$
# klist -tke u2404d.keytab
Keytab name: FILE:u2404d.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 09/23/2025 07:35:33 U2404D$@HOGESERVER.HOGEDDNS.JP (aes256-cts-hmac-sha1-96)
   1 09/23/2025 07:35:33 U2404D$@HOGESERVER.HOGEDDNS.JP (aes128-cts-hmac-sha1-96)
   1 09/23/2025 07:35:33 U2404D$@HOGESERVER.HOGEDDNS.JP (DEPRECATED:arcfour-hmac)

失敗する場合の出力はこう。

$ sudo mount -v -t nfs4 -o sec=krb5p u2404s.hogeserver.hogeddns.jp:/ /mnt
mount.nfs4: timeout set for Tue Sep 23 07:46:56 2025
mount.nfs4: trying text-based options 'sec=krb5p,vers=4.2,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs4: mount(2): Permission denied
mount.nfs4: trying text-based options 'sec=krb5p,vers=4,minorversion=1,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs4: mount(2): Permission denied
mount.nfs4: trying text-based options 'sec=krb5p,vers=4,addr=192.168.110.14,clientaddr=192.168.110.178'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting u2404s.hogeserver.hogeddns.jp:/

クライアント側のログはこうだった。

 9月 23 07:44:56 u2404d kernel: netfs: FS-Cache loaded
 9月 23 07:44:56 u2404d kernel: NFS: Registering the id_resolver key type
 9月 23 07:44:56 u2404d kernel: Key type id_resolver registered
 9月 23 07:44:56 u2404d kernel: Key type id_legacy registered
 9月 23 07:44:56 u2404d rpc.gssd[1239]: inotify event for topdir (nfs) - ev->wd (8) ev->name (clnt0) ev->mask (0x40000100)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: creating client nfs/clnt0
 9月 23 07:44:56 u2404d rpc.gssd[1239]: scanning client nfs/clnt0
 9月 23 07:44:56 u2404d rpc.gssd[1239]: inotify event for clntdir (nfs/clnt0) - ev->wd (11) ev->name (gssd) ev->mask (0x00000100)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: scanning client nfs/clnt0
 9月 23 07:44:56 u2404d rpc.gssd[1239]: inotify event for clntdir (nfs/clnt0) - ev->wd (11) ev->name (krb5) ev->mask (0x00000100)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: scanning client nfs/clnt0
 9月 23 07:44:56 u2404d rpc.gssd[1239]: inotify event for clntdir (nfs/clnt0) - ev->wd (11) ev->name (idmap) ev->mask (0x00000100)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: 
                                         handle_gssd_upcall(0x7da9d7712740): 'mech=krb5 uid=0 service=* enctypes=20,19,26,25,18,17' (nfs/clnt0)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: start_upcall_thread(0x7da9d7712740): created thread id 0x7da9d6bfe6c0
 9月 23 07:44:56 u2404d rpc.gssd[1239]: krb5_use_machine_creds(0x7da9d6bfe6c0): uid 0 tgtname (null)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: No key table entry found for u2404d$@HOGESERVER.HOGEDDNS.JP while getting keytab entry for 'u2404d$@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: No key table entry found for U2404D$@HOGESERVER.HOGEDDNS.JP while getting keytab entry for 'U2404D$@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: No key table entry found for root/u2404d@HOGESERVER.HOGEDDNS.JP while getting keytab entry for 'root/u2404d@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: No key table entry found for nfs/u2404d@HOGESERVER.HOGEDDNS.JP while getting keytab entry for 'nfs/u2404d@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: No key table entry found for host/u2404d@HOGESERVER.HOGEDDNS.JP while getting keytab entry for 'host/u2404d@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Scanning keytab for root/*@HOGESERVER.HOGEDDNS.JP
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Scanning keytab for nfs/*@HOGESERVER.HOGEDDNS.JP
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Scanning keytab for host/*@HOGESERVER.HOGEDDNS.JP
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: Processing keytab entry for principal 'HOST/U2404D@HOGESERVER.HOGEDDNS.JP'
 9月 23 07:44:56 u2404d rpc.gssd[1239]: We will NOT use this entry (HOST/U2404D@HOGESERVER.HOGEDDNS.JP)
 9月 23 07:44:56 u2404d rpc.gssd[1239]: ERROR: gssd_refresh_krb5_machine_credential_internal: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host u2404s.hogeserver.hogeddns.jp
 9月 23 07:44:56 u2404d rpc.gssd[1239]: ERROR: No credentials found for connection to server u2404s.hogeserver.hogeddns.jp
 9月 23 07:44:56 u2404d rpc.gssd[1239]: do_error_downcall(0x7da9d6bfe6c0): uid 0 err -13
 9月 23 07:44:56 u2404d rpc.gssd[1239]: 
                                         handle_gssd_upcall(0x7da9d7712740): 'mech=krb5 uid=0 service=* enctypes=20,19,26,25,18,17' (nfs/clnt0)
<繰り返し同じログが出力される>

赤文字の部分が、NFSv4が探してくれるキータブ。
今回の場合は、U2404D$@HOGESERVER.HOGEDDNS.JP が使えるキータブだった。

host/u2404d@HOGESERVER.HOGEDDNS.JP も使ってくれそうな気がするが、この場合にNFSはホスト名に$を付けることはしないようで、Samba AD DCではチケットが発行されなかった。

rootとかnfsとかのSPNを登録してキータブを作ってみたけれど、それらのキータブを見つけても、チケットは取得できない。

この場合の特徴は、

サーバー側のログは、要求あったけど、諦めたのね、で終わり。
クライアント側では mount(2): Permission denied と表示されるのみ。

といったところ。

接続に失敗したら、クライアント側でも詳細なログが出力されるようにしておくと、原因が分かりやすい。

NFSv3での接続

設定が上手くいかず、色々と緩めて接続できたのがこれ。
ポート111を使っていた。

/etc/exports

/var/local/share 192.168.110.0/24(rw,sync,all_squash,no_subtree_check)

$ sudo mount -t nfs -o vers=3,proto=tcp,port=2049 u2404s.hogeserver.hogeddns.jp:/var/local/share /mnt

ポート2049を指定しているが、フォールバックしてポート111で接続していた。

今となっては、どうしてここまで上手くいかなかったのか分からないが、とにかく全然動いてくれなかった。
ログがよく分からず、上手くいかない、ネットのTipsで試す…を繰り返した結果ではある。

役に立つかどうか分からないけれど、とりあえず書き記しておく。

ドメインユーザーでアクセス権限なし！？

ドメインユーザーがオーナーになっているディレクトリにアクセスしたら、以下のエラーが出た。

$ su HOGEDOMAIN\\piyo
$ ll /mnt/piyo
ls: cannot open directory '/mnt': Permission denied

ドメインユーザーのIDが解決できていなかった。
このログは、マウントを止めて、クライアントとサーバー共にサービスを再起動し、改めてアクセスすると出力される。

Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_ids: calling nsswitch->princ_to_ids
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: nss_getpwnam: name 'piyo@HOGESERVER.HOGEDDNS.JP' domain '(null)': resulting localname 'piyo'
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_ids: nsswitch->princ_to_ids returned -2
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_ids: final return value is -2
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: DEBUG: serialize_krb5_ctx: lucid version!
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: prepare_krb5_rfc4121_buffer: protocol 1
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: prepare_krb5_rfc4121_buffer: serializing key with enctype 20 and size 32
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: doing downcall
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1758998817 (35998 from now), clnt: <null>, uid: -1, gid: -1, num aux grps: 0:
Sep 27 17:46:59 u2404s rpc.svcgssd[3565]: sending null reply

ホームラボでは、
　piyo@HOGESERVER.HOGEDDNS.JP
ではなく、
　HOGEDOMAIN\piyo@HOGESERVER.HOGEDDNS.JP
で名前を解決することができるし、他のサービスはそれがちゃんとできているようにログからは見えていた。

けれども、rpc.svcgssdでそれを指定する方法が見つからない。

仕方がないので、HOGEDOMAINなしでユーザーを見つけられるように、サーバー側のwinbindの設定を修正した。

/etc/samba/smb.conf

winbind use default domain = yes ← この行がなかったので追加

反映。

$ sudo systemctl restart winbind

これで名前が解決できるようになり、出力されるログが以下のように変わった。

Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: sname = piyo@HOGESERVER.HOGEDDNS.JP
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_ids: calling nsswitch->princ_to_ids
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nss_getpwnam: name 'piyo@HOGESERVER.HOGEDDNS.JP' domain '(null)': resulting localname 'piyo'
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_ids: nsswitch->princ_to_ids returned 0
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_ids: final return value is 0
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_grouplist: calling nsswitch->gss_princ_to_grouplist
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nss_getpwnam: name 'piyo@HOGESERVER.HOGEDDNS.JP' domain '(null)': resulting localname 'piyo'
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_grouplist: nsswitch->gss_princ_to_grouplist returned 0
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: nfs4_gss_princ_to_grouplist: final return value is 0
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: DEBUG: serialize_krb5_ctx: lucid version!
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: prepare_krb5_rfc4121_buffer: protocol 1
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: prepare_krb5_rfc4121_buffer: serializing key with enctype 20 and size 32
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: doing downcall
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1758999289 (35996 from now), clnt: <null>, uid: 1008103, gid: 1000513, num aux grps: 4:
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]:   (   1) 1000513
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]:   (   2) 1008103
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]:   (   3) 1009601
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]:   (   4) 3000001
Sep 27 17:54:53 u2404s rpc.svcgssd[3565]: sending null reply

ではこの

winbind use default domain = yes

という設定が入っている場合に、UID/GIDの取り扱いはどうなるかというと…

$ id rohhie
uid=1000(rohhie)
gid=1000(rohhie)
groups=1000(rohhie),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),101(lxd),
       1001103(rohhie),1000513(domain users),1000512(domain admins),1000572(denied rodc password replication group),1009601(sogo users),3000001(BUILTIN\users),3000000(BUILTIN\administrators)

$ id 'HOGEDOMAIN\rohhie'
uid=1001103(rohhie)
gid=1000513(domain users)
groups=
       1000513(domain users),1001103(rohhie),1000512(domain admins),1000572(denied rodc password replication group),1009601(sogo users),3000001(BUILTIN\users),3000000(BUILTIN\administrators)

※ちょっと分かりづらいけれど、比較のために途中で改行している。

結果として、UID 1000のユーザーは、ローカルのUIDとGIDを持ち、ローカルの各種グループに所属しつつも、ドメインのグループにも参加している扱いになっている。

一方、この指定が入っていない場合にどうなるかというと、きちんとユーザーが区別できる。
表示も明示的にHOGEDOMAIN\が付与されている。

$ id rohhie
uid=1000(rohhie)
gid=1000(rohhie)
groups=1000(rohhie),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),114(lpadmin)

$ id HOGEDOMAIN\\rohhie
uid=1001103(HOGEDOMAIN\rohhie)
gid=1000513(HOGEDOMAIN\domain users) groups=1000513(HOGEDOMAIN\domain users),1001103(HOGEDOMAIN\rohhie),1000512(HOGEDOMAIN\domain admins),1000572(HOGEDOMAIN\denied rodc password replication group),1009601(HOGEDOMAIN\sogo users),3000001(BUILTIN\users),3000000(BUILTIN\administrators)

同じ名前を持つ人さえいなければ問題ないので、そんな風にシステムを整理しても良いのかもしれない。

さいごに

最初にkrb5pで挑戦しようとしたこと、Fail2Banが動いていたことなど、トラブルから始まる設定で折れかけた…
Geminiさんに聞いても答えを持っていないことが多く、検索しても自分にとってちょうど良い情報にはなかなか巡り会えなかった。

ホームラボではSamba AD DCが動いているのだけれど、これを中心にkrb5pで接続しようとしたとき、サーバー・クライアント共にドメインに参加している必要があり、それならSambaでマウントしてもいいんじゃね？となって、更に折れかけた…

NFS関連のサービスはSamba AD DCに対応してくれているが、特別対応という印象で、ちゃんと動くけれど型が決まっている。
その型通りでないと動かないので、型どおりに操作をする必要がある。

そう、今回の手順整理は、パズルのピースを1つ1つはめ込んでいくようだった。

今回の目的は、サンドボックス的な環境を作り、そこから外部ストレージにデーターを保管すること。
ユーザーIDとパスワードを保管しない運用を考えた場合、sec=sysでの接続がいいかな。
そうなると、記事の大部分は使わないなぁ。

とはいえ、今までは1つしかやり方が分からないので、そのやり方で押し通すしかなかった。
そのことを思えば、(レガシーだけど)新たな選択肢ができたことは喜ばしい。

さあ、詳細ログ出力を元に戻して、本番環境への実装作業に入ろう。
(と思ったら、クライアントですべてがnobody:nogroup表示…なんてこったい。手順の修正はしたけど、最後の最後まで分からないことだらけ)

NFSについて

概要

バージョン

連携するサービス達

サーバーの公開設定

ユーザーIDマッピング

テスト環境

NFSv4 sec=sys

サーバー側の設定

クライアント側の設定

NFSv4 sec=krb5p

サーバー側の設定(Samba AD DC)

サーバー側の設定

クライアント側の設定(Samba AD DC)

クライアント側の設定

クライアントからのアクセス

起きたこと・調べたこと

詳細ログの出力

Fail2banでBANされていた

コンピューターのキータブ

NFSv3での接続

ドメインユーザーでアクセス権限なし！？

さいごに

コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他

コメントはこちらからお気軽にどうぞ～投稿に関するご意見・感想・他