何か見落としているかもしれませんが、USEDDISKSPACE の -l 引数は、Windows レター システムでマウントされたボリュームにのみ適用されるようです。-l に次の引数を使用してみました。
ボリュームラベル
マウントされたフォルダへのパス
check_nt がサブフォルダとしてマウントされたボリュームの監視を処理できないだけなのかもしれません。どなたか知見をお持ちの方がいらっしゃれば幸いです。
編集：
明確に言うと、Windows は通常、ドライブ文字 C をメインのマウント ドライブとして構成します。他のボリュームを他のドライブ文字としてマウントすることはできません。これは、GPO を含むオフィス ポリシーにより、これ以上ボリュームをマウントするためのドライブ文字が不足しているためです。GPO ポリシーを変更したり、ポリシーを作成したシステム管理者を解雇したりすることはできません。この問題を回避するには、新しいボリュームをドライブ文字 d、e、f などにマウントする代わりに、C:\SQLDatabasefiles などにボリュームをマウントします。Nagios は、C:\SQLDatabasefiles にマウントされたボリュームが実際にはボリュームであることを認識できず、このボリュームのディスク使用率を報告する方法はないようです。
これは、フォルダー共有メカニズムである SMB とは関係ありません。
答え1
最良の方法は、SMB マウントされた共有を持つ Windows ホストで check_nt を使用するのではなく、SMB 共有を直接チェックすることだと思います。SMB 共有は、システム全体のサービスとしてではなく、ログインしたユーザーのコンテキストに存在するため、check_nt プラグインはそれらを見つけることができません。
Nagios Exchange の check_disk_smb_spaces プラグインをご覧ください。
http://exchange.nagios.org/directory/Plugins/System-Metrics/File-System/SMB/check_disk_smb_spaces/詳細