ZabbixでPostgreSQLログがpermission deniedになる対処

Minory コメントを残す

ZabbixでPostgreSQLのログを監視すると、Zabbix PostgreSQL permission denied のように Item が unsupported になることがあります。
ファイル自体に chmod 644 や親ディレクトリに chmod 755 を付けても直らないケースも少なくありません。

原因は1つに限りません。
親ディレクトリの横断権限、Agent実行ユーザー、ACL、SELinux、ログパスと Item 設定の不一致など、確認順に事実を集めるのが安全です。

ポイント

権限を安易に 755 / 777 へ広げず、zabbix ユーザーに必要な読み取りとディレクトリ横断だけを付与します。

切り分けは「確認 → 仮説 → 最小変更 → 再確認」の順で進め、原因を先に断定しないでください。

想定する症状と切り分けの順番

ここでは、次のような状況を想定します。
パスやユーザー名は環境に合わせて読み替えてください。

項目例
症状ログ監視 Item が Permission denied / unsupported
監視対象PostgreSQL のログファイル
Agentzabbix_agentd（実行ユーザーは多くの場合 zabbix）
よくある誤対応ファイルだけ chmod 644、ディレクトリだけ chmod 755

推奨する確認順は次のとおりです。
途中で直ったら、以降の項目は実施不要です。

  1. PostgreSQL の実際のログパスと Zabbix Item のパスが一致しているか
  2. namei -l でパス全体の権限を確認する
  3. zabbix ユーザーとしてファイルが読めるか
  4. ACL で必要最小限の権限を付与する
  5. SELinux が拒否していないか（該当環境のみ）

chmod 755 や 644 でも直らない典型原因

ファイルの権限を直しても読めないとき、多くの場合は親ディレクトリの横断権限が足りていません。
Linux ではファイルに到達するまでに、パス上の各ディレクトリに対して実行（探索）権限 x が必要です。

たとえばログファイルが 0644 でも、途中のディレクトリが 0700（所有者のみ）だと、他ユーザーの zabbix はそこを通れません。
逆に、ディレクトリを広く開けても、PostgreSQL のログは既定で所有者のみ読めるモードになることがあり、ファイル側の読み取りが別問題として残ります。

PostgreSQL の log_file_mode の既定は 0600 です。
サーバー所有者以外が読めない設定のまま、ファイルだけを一時的に 644 にしても、ローテーション後に再び読めなくなることがあります。

PostgreSQL Documentation
19.8. Error Reporting and Logging 19.8. Error Reporting and Logging # 19.8.1. Where to Log 19.8.2. When to Log 19.8.3. What to Log 19.8.4. Using CSV-Format …

したがって「ファイルを 644」「ディレクトリを 755」だけで終わらせず、パス全体とローテーション後の権限まで見る必要があります。
他ユーザー全員に開ける変更は、監視のためだけなら過剰になりやすいです。

namei -l で親ディレクトリ権限を確認する

パス全体を一度に見るには namei -l が便利です。
各階層の所有者・権限が一覧になるため、permission denied の候補箇所を特定しやすくなります。

# 例: 実際のログパスに置き換える
namei -l /var/lib/pgsql/data/log/postgresql-2026-10-23.log

出力例では、途中に drwx------ のような行があれば、そこで zabbix ユーザーが止まる可能性が高いです。
-l は長い形式、-m を付けるとモード中心の表示になります（環境によってオプション表記は namei -mo など）。

namei -mo /path/to/postgresql.log
ls -ld /var/lib/pgsql /var/lib/pgsql/data /var/lib/pgsql/data/log
ls -l /path/to/postgresql.log

確認の観点は次の2点です。
ディレクトリには探索用の x、対象ファイルには読み取りの r が、zabbix ユーザーの実効権限として付いているか。

ここで「others に広く開ける」以外の選択肢として、後述の ACL やグループ所属を検討します。
事実としてどの階層で止まっているかを控えてから変更してください。

Zabbix Agentの実行ユーザーと読み取り確認

Zabbix のログ監視は Agent が対象ホスト上でファイルを開きます。
公式のログ監視手順でも、zabbix ユーザーに読み取り権限が必要だと明記されています。

あわせて読みたい
3 Log file monitoring

まず Agent がどのユーザーで動いているかを確認します。

ps -o user,group,cmd -C zabbix_agentd
# または Agent 2 の場合
ps -o user,group,cmd -C zabbix_agent2
id zabbix
grep -E '^(User|Group)=' /etc/zabbix/zabbix_agentd.conf 2>/dev/null

次に、そのユーザーとして実際に読めるかをテストします。
GUI や Item の再チェックより先に、OS 上で再現できるかが重要です。

sudo -u zabbix test -r /path/to/postgresql.log && echo readable || echo not readable
sudo -u zabbix head -n 1 /path/to/postgresql.log
sudo -u zabbix cat /path/to/postgresql.log >/dev/null

Permission denied が出るなら、まだパス権限かファイル権限が不足しています。
読めるのに Zabbix だけ失敗する場合は、Item のパス誤り、Active チェック未設定、Agent 再起動不足などを疑います。

ログ監視 Item は Zabbix agent (active) である必要があります。
log[] やローテーション向けの logrt[] を使い、ファイル欠如や権限不足だと Item は unsupported になります。

# 固定ファイル名の例
log[/var/lib/pgsql/data/log/postgresql.log]

# 日付などでファイル名が変わる場合の例（正規表現は環境に合わせる）
logrt[/var/lib/pgsql/data/log/^postgresql-.*\.log$]

ACLで必要最小限の権限を付与する

他ユーザー全体へ chmod o+rx するより、ACL で zabbix ユーザーだけに付与する方が安全です。
パス上の各ディレクトリには探索 x、ログファイルには読み取り r を付けます。

# 必要ならパッケージを導入（ディストリビューションにより異なる）
# RHEL 系: sudo dnf install acl
# Debian/Ubuntu 系: sudo apt install acl

# 親ディレクトリへ横断権限（例）
sudo setfacl -m u:zabbix:x /var/lib/pgsql
sudo setfacl -m u:zabbix:x /var/lib/pgsql/data
sudo setfacl -m u:zabbix:x /var/lib/pgsql/data/log

# 現在のログファイルへ読み取り
sudo setfacl -m u:zabbix:r /var/lib/pgsql/data/log/postgresql-2026-10-23.log

# 確認
getfacl /var/lib/pgsql/data/log
getfacl /var/lib/pgsql/data/log/postgresql-2026-10-23.log
sudo -u zabbix head -n 1 /var/lib/pgsql/data/log/postgresql-2026-10-23.log

ログが日次などで作り直される場合は、ディレクトリの default ACL も検討します。
新規ファイルへ読み取りを継承させつつ、再帰オプションの乱用は避けてください。

# ログディレクトリに default ACL（新規ファイルへ r を継承する例）
sudo setfacl -m d:u:zabbix:r /var/lib/pgsql/data/log
# 既存ファイルにも付与したい場合は個別または慎重な一括適用
sudo setfacl -m u:zabbix:r /var/lib/pgsql/data/log/*.log
あわせて読みたい
setfacl(1) – Linux manual page

setfacl -R でツリー全体へ広く付けると、意図しないファイルまで読める状態になりやすいです。
監視に必要な階層とファイルに限定してください。

別案として、postgres グループなど既存の読み取り可能グループへ zabbix を追加する方法もあります。
グループの意味と影響範囲を確認してから行い、本番では変更前に影響範囲を関係者と共有してください。

あわせて読みたい
Chapter 5. Access Control Lists | System Administrator’s Guide | Red Hat Enterprise Linux | 7 | Red … Chapter 5. Access Control Lists | System Administrator’s Guide | Red Hat Enterprise Linux | 7 | Red Hat Documentation

SELinuxの状態確認と監査ログ調査

DAC（通常のファイル権限）を直しても拒否が続く場合、SELinux などの MAC を疑います。
まずモードを確認し、Enforcing のときだけ監査ログを追います。

getenforce
# Enforcing / Permissive / Disabled のいずれか

拒否の有無は ausearch で AVC を調べます。
再現操作の直後に実行すると、関係する拒否を拾いやすいです。

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
# 必要に応じて
sudo journalctl -t setroubleshoot --since "10 minutes ago"
あわせて読みたい
Chapter 5. Troubleshooting problems related to SELinux | Using SELinux | Red Hat Enterprise Linux | … Chapter 5. Troubleshooting problems related to SELinux | Using SELinux | Red Hat Enterprise Linux | 10 | Red Hat Documentation

AVC に zabbix や対象ログパスが含まれるなら、SELinux が関与している仮説が立ちます。
恒久対応は、ポリシーモジュールや適切なコンテキスト変更が原則です。

切り分けのために一時的に Permissive へ落とす方法はありますが、本番では影響と復旧手順を決めてからにしてください。
Permissive でも症状が残るなら、SELinux 以外を優先して再確認します。

# 切り分け用の一時変更例（本番では慎重に）
# sudo setenforce 0
# getenforce
# 再現テスト後、必要なら
# sudo setenforce 1

PostgreSQLのログパスとZabbix監視設定の確認

権限が正しいのに読めないとき、監視しているパスが実ログと違うことがあります。
PostgreSQL 側の設定値を先に確定してください。

# 例: psql が使える場合
sudo -u postgres psql -c "SHOW log_directory;"
sudo -u postgres psql -c "SHOW log_filename;"
sudo -u postgres psql -c "SHOW logging_collector;"
sudo -u postgres psql -c "SHOW data_directory;"
sudo -u postgres psql -c "SHOW log_file_mode;"

log_directory が相対パスなら、データディレクトリ配下の意味になります。
絶対パスに直して、Zabbix の Item キーと一致させます。

# 相対 log_directory=log の場合の実体確認例
sudo -u postgres psql -tAc "SELECT setting FROM pg_settings WHERE name='data_directory';"
ls -l "$(sudo -u postgres psql -tAc "SELECT setting FROM pg_settings WHERE name='data_directory';")/log"

Zabbix 側では次を確認します。
Item タイプが Active か、キーが log[] / logrt[] か、パスと正規表現が実ファイル名に合うか、Agent の ServerActive と Hostname がフロントと一致しているかです。

# Agent 設定の要点確認例
grep -E '^(Hostname|ServerActive|Server)=' /etc/zabbix/zabbix_agentd.conf
# 変更後は Agent 再起動
sudo systemctl restart zabbix-agent
# または
sudo systemctl restart zabbix-agent2

log_file_mode を永続的に緩める場合は、PostgreSQL のセキュリティ方針と相談してください。
監視用途なら ACL やグループ読み取りの方が、全体の others 開放より説明しやすいことが多いです。

PostgreSQL Documentation
24.3. Log File Maintenance 24.3. Log File Maintenance # It is a good idea to save the database server’s log output somewhere, rather than just …

対処後の再確認チェックリスト

変更したら、次の順で結果を確認します。
GUI 上の Item 状態だけを見ず、OS 上の読み取り成功を先に取ってください。

  • sudo -u zabbix head で対象ログが読める
  • namei -l でパス途中に拒否要因が残っていない
  • getfacl で意図した ACL だけが付いている
  • SELinux 環境なら新しい AVC が増えていない
  • Zabbix で Item が supported になり、新しいログ行が取れる
  • ログローテーション後も読める（default ACL やグループ方針の確認）
ファイルを 644、ディレクトリを 755 にしても直らないのはなぜですか？

パス途中の別ディレクトリに探索権限が無い、ローテーションで権限が戻る、SELinux が拒否している、Item のパスが実ログと違う、などの候補が残ります。
namei と zabbix ユーザーでの実読取から確認してください。

ACL と chmod、どちらを優先すべきですか？

監視目的なら、zabbix ユーザーだけに絞れる ACL を優先するのが安全です。
全員向けに権限を広げる chmod は、必要性が明確なときだけにしてください。

logrt と log のどちらを使いますか？

ファイル名が固定なら log[]、日付などで変わるなら logrt[] が適します。
どちらの場合も、Agent ユーザーが現在の実ファイルを読めることが前提です。

まとめ

Zabbix で PostgreSQL ログ監視が permission denied になるときは、ファイル単体の chmod だけでは足りないことが多いです。
実際のログパスを確定し、namei で親ディレクトリを見て、zabbix ユーザーで読めるかを確認してください。

権限付与は ACL など最小権限を優先し、SELinux がある環境では監査ログも併せて見ます。
原因を断定せず、確認と再確認を繰り返すことで、監視を安全に復旧できます。


Amazonベストセラー

Now loading...


返信を残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA