2021年8月21日 2021年8月21日 By wataru In

何！NFSだとinotifyが動かないだ、と、の話

今回は、minidlnaサーバを構築時に引っかかったinotifyの問題をまとめたいと思います。

やりたかったことを簡単に説明すると、ファイルサーバをNFSで公開して、minidlnaにてメディア情報をDLNAで公開する。
ファイルサーバとminidlna起動サーバは別サーバで起動する。
ついでにminidlnaは以下の種類存在している

・songs : 歌の音楽を配信
・bgm : 歌のない音楽を提供
・all : すべての音楽を提供
・movie : 映画を配信 (検証中)

ざっくり分けてこれだけの提供をしています。

結構リソースが取るわけです。

と言うことで、メディア情報（音楽、動画）を安全なサーバで保存して、危うい提供サービスは別サーバで運用、それぞれをNFSで結合すれば、Happy Happyになると考えたわけです。

っで、minidlnaでinotifyが動かないとどうなるのか？

minidlnaでinotifyが動かないと、新しいメディア情報をファイルサーバにアップデートしても検出されません。
つまりは、入ったまま再生することが出来ません

困ります… 初期設定の提供メニューのままでは面白くありません。

別で調査しましたが、キャッシュクリア & 再起動なら問題なく取り込めます
ファイルはそのまま参照可能ですので

実際に動作を確認します

実行環境のメモ

環境はQNAP TS-351のContainerStation(Docker)を使い、QNAPのNFSサーバにDockerContainerのローカルにNFSマウントします
構築方法や設定は記事の下に書いておきます

参考までにディレクトリのマウント意味を書いておきます

マウントポイント意味
/mnt/nfsNFSサーバのマウント
/mnt/mountDocker指定のマウント
/mnt/testただのディレクトリローカル環境での動作確認
マウントポイント

端末にログインして(端末 > )ボタンでシェルを/bin/sh でOK

不具合動作を確認する

監視を開始します

/ # inotifywait /mnt/nfs
Setting up watches.
Watches established.

QNAPの管理画面からFile Stationを選択、NFS共有ディレクトリにファイルをアップロード

… 無反応 …

^Cして、ディレクトリを確認

/ # ls -al /mnt/nfs/
total 1432
drwxrwxrwx 6 root root 4096 Aug 21 00:15 .
drwxr-xr-x 1 root root 4096 Aug 20 23:07 ..
drwxrwxrwx 2 root root 4096 Aug 21 00:15 .@upload_cache
drwxrwxrwx 3 root root 4096 Aug 19 03:04 @Recycle
-rw-rw-rw- 1 root root 1440056 Jan 18 2021 SAMY0028.BMP
drwx—— 6 998 root 4096 Aug 20 04:37 gitlab

ファイル(SAMY0028.BMP)は追加されている

ネットワークからアップデートしたファイルが発見できないのか？

ローカル環境での動作確認（動いて当たり前）

とりあえずの動作確認で、ローカルでの操作を確認します。

ローカルでは、希望した動作がします。

ファイル変更を検出、サーバ側でのファイル変更を確認が可能です

別ターミナルを使うので、QNAPで2つの端末を起動します
それぞれ、端末い(監視する)、端末ろ(ファイルを操作する)とします

○　ファイルの作成

端末い : ディレクトリを監視します

/ # inotifywait /mnt/nfs
Setting up watches.
Watches established.

端末ろ : ファイルを生成

/ # touch /mnt/nfs/test

端末い : 出力を確認

/mnt/nfs/ CREATE test

ファイルの作成時はFile Stationにてファイル作成を確認

○　ファイルの編集

端末い : ディレクトリを監視します

/ # inotifywait /mnt/nfs
Setting up watches.
Watches established.

端末ろ : ファイルを生成

/ # echo 1 > /mnt/nfs/test

端末い : 出力を確認

/mnt/nfs/ MODIFY test

○　ファイルの削除

端末い : ディレクトリを監視します

/ # inotifywait /mnt/nfs
Setting up watches.
Watches established.

端末ろ : ファイルを生成

/ # echo 1 > /mnt/nfs/test

端末い : 出力を確認

/mnt/nfs/ DELETE test

Dockerでのホストボリュームの場合

ホストボリュームはちゃんとファイルの監視を出来ている動作をしてくれます。
これならminidlnaに利用可能です

今回は毎回操作するのが面倒くさいのとアップロードを嚙んだ場合には複数のアクセスが出るのでモニターモード(-m)を使います

/ # inotifywait -m /mnt/mount
Setting up watches.
Watches established.

色々出ますが、QNAPのファイルアップデート周りの試行錯誤がｗ

/mnt/mount/ MOVED_TO SAMY0028.BMP
/mnt/mount/ ATTRIB SAMY0028.BMP
/mnt/mount/ ATTRIB SAMY0028.BMP
/mnt/mount/ DELETE SAMY0028.BMP

手順

  1. ファイルをアップロード
  2. ファイルを削除

編集も考えましたが、無視！

あくまでも想像ですが、
　・　MOVED_TOはアップロードの一時キャッシュからの移動
　・　ATTRIBは最新閲覧とか変更　←　これは良く解りません(パーミッションとか変えているのかな？)
　・　DELETEは普通に削除
って感じでしょうかね


別サーバのNFS Clientからの変更

ここでは、QNAP TS-351にNFSサーバを建てて、別のQNAP TS-351にNFSクライアントで動作を確認します

構築方法は… 略 構築方法

マウントしたらはじめにinodesが違うことを確認します
※　ローカルの場合はNFS / ボリューム割当共に同じ値です

/ # df -i | grep mnt
Filesystem              Inodes      Used Available Use% Mounted on
overlay              145752064   1375937 144376127   1% /
                     119474176    710400 118763776   1% /mnt/nfs

ローカルとNFSでは値が異なります。

参考までに、NFSサーバが起動しているcontainerでは一致します
※　別で撮ったので値は違います。同じ値であることが重要です

/ #  df -i | grep mnt
                     119474176    710401 118763775   1% /mnt/mount
                     119474176    710401 118763775   1% /mnt/nfs

次に変更が検出可能か？を確認します

/ # inotifywait -m /mnt/nfs/
Setting up watches.
Watches established.

ローカルでも動かなかったので、動きませんでしたｗ

操作とinode…

作業1) ブラウザにて2ファイルの追加

                     119474176    710402 118763774   1% /mnt/nfs

作業2) 1ファイルの削除

                     119474176    710401 118763775   1% /mnt/nfs

作業3) 1ファイルの削除

overlay 145752064 1375937 144376127 1% /
119474176    710400 118763776   1% /mnt/nfs

NFSのinodeは変化しますが、ディスクのinodeは145752064と変化がありません

NFSサーバのinodeはクライアントと同じく変更されます…

/ #  df -i | grep mnt
                     119474176    710400 118763776   1% /mnt/mount
                     119474176    710400 118763776   1% /mnt/nfs

最後にサーバ監視のクライアント変更を行うと…
ちゃんと検出されます

クライアント :

/ # touch /mnt/nfs/test2

サーバ :

/ # inotifywait -m /mnt/mount
Setting up watches.
Watches established.

変更を加える

/mnt/mount/ ACCESS,ISDIR 
/mnt/mount/ CLOSE_NOWRITE,CLOSE,ISDIR 
/mnt/mount/ CREATE test2
/mnt/mount/ CLOSE_WRITE,CLOSE test2

結局なんだったっけ？ｗ　状態になってきたのでまとめると

inotifyでファイル変更を監視しているツールはNFSでは使えない！

と言うことですね。

たぶん、昔からの常識だったですが、引っかかったのでメモります

inode countでも検出できれば使えそうな気もしますが…

検証環境構築方法

サーバ : QNAP TS-351

アプリ : ContainerStation

image : alpine:latest

アイテム値
名称test-nfs-inode
コマンド/bin/sh
自動起動Enable
CPU100 %
メモリー制限15906 MB
環境PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ネットワークモードNAT
特権モードEnable
ホストからのボリュームホストパス : マウントポイント /backups : /mnt/mount
設定項目

NFSツールをインストール

/ # apk add nfs-utils
(1/16) Installing libtirpc-conf (1.3.2-r0)
(2/16) Installing krb5-conf (1.0-r2)
(3/16) Installing libcom_err (1.46.2-r0)
(4/16) Installing keyutils-libs (1.6.3-r0)
(5/16) Installing libverto (0.3.2-r0)
(6/16) Installing krb5-libs (1.18.4-r0)
(7/16) Installing libtirpc (1.3.2-r0)
(8/16) Installing rpcbind (1.2.6-r0)
Executing rpcbind-1.2.6-r0.pre-install
(9/16) Installing libblkid (2.37-r0)
(10/16) Installing libcap (2.50-r0)
(11/16) Installing device-mapper-libs (2.02.187-r1)
(12/16) Installing libevent (2.1.12-r2)
(13/16) Installing libmount (2.37-r0)
(14/16) Installing libnfsidmap (2.5.3-r0)
(15/16) Installing sqlite-libs (3.35.5-r0)
(16/16) Installing nfs-utils (2.5.3-r0)
Executing busybox-1.33.1-r3.trigger
OK: 12 MiB in 30 packages

NFSサーバからマウントする
参考) 注意 1 : マウントが出来ない場合の対処

/ # mkdir /mnt/nfs
/ # mount -t nfs 192.168.1.203:/backups /mnt/nfs/

minidlna : https://wiki.archlinux.jp/index.php/ReadyMedia

注意 1 : マウントが出来ない場合の対処

/ # mount -t nfs4 192.168.1.203:/backups /mnt/nfs
mount.nfs4: Operation not permitted
mount: permission denied (are you root?)

作成時の特許モードが必要

特権モード : Enable