CentOS（RHEL系）からUbuntuサーバーに移行した際、パーミッションやアクセス制御周りで仕様の違いに戸惑ったポイントを技術メモとしてまとめます。

1. SELinuxとAppArmorの制御思想の違い

CentOSでWebサーバーを構築する際、パーミッションを755に設定しても403 Forbiddenになる主な原因はSELinux（ラベル/コンテキストベースの強制アクセス制御）でした。
UbuntuではSELinuxはデフォルトで無効化されており、代わりにAppArmorが標準で動作しています。

項目	CentOS (SELinux)	Ubuntu (AppArmor)
制御単位	ファイルやプロセスへの「ラベル（コンテキスト）」	「パス（ファイルパス）」ベースのプロファイル
主な設定ファイル・コマンド	`chcon`, `restorecon`, `setenforce`	`/etc/apparmor.d/`
Web公開時の挙動	ドキュメントルート外や特定操作で403多発	`/var/www/` 配下なら基本干渉しない

SELinuxが「システム全体の要素に細かくタグ付けして監視する」のに対し、AppArmorは「指定したプログラム（プロセス）がアクセス可能なディレクトリの壁を作る」アプローチを取っています。

2. Ubuntu移行時によくあるハマりどころと対処法

① DBのデータ保存先（datadir）変更時に起動しなくなる

Webサーバー自体はAppArmorの干渉を受けにくいですが、MySQL / MariaDB などは厳格なプロファイルが適用されています。

例えば、ストレージ逼迫などでデータディレクトリを /mnt/volume/mysql/ などデフォルト外に変更した場合、Linuxのディレクトリ権限（chown）を正しく設定していても、AppArmorに遮断されてサービスが起動しなくなります。

対処手順

ローカル用のプロファイル設定ファイルに追記してリロードします。

# 1. ローカルプロファイルを開く（MariaDB/MySQL）
sudo nano /etc/apparmor.d/local/usr.sbin.mysqld

# 2. 変更先ディレクトリへのアクセス権限を追記
/mnt/volume/mysql/ r,
/mnt/volume/mysql/** rwk,

# 3. AppArmorの設定を再読み込み
sudo systemctl reload apparmor

# 4. DBサービスを再起動
sudo systemctl restart mariadb

② Web実行ユーザーが nginx / apache ではなく www-data

CentOSでは nginx:nginx や apache:apache で指定していた所有権ですが、Ubuntu（Debian系）では標準で www-data が使用されます。

# Ubuntu環境でのドキュメントルート権限付与
sudo chown -R www-data:www-data /var/www/[example.com/html](https://example.com/html)
sudo find /var/www/[example.com/html](https://example.com/html) -type d -exec chmod 755 {} +
sudo find /var/www/[example.com/html](https://example.com/html) -type f -exec chmod 644 {} +

まとめ

UbuntuはAppArmorがパス単位でプロセスを保護しているため、Web公開周りの403エラーで詰まる頻度は大幅に減る
ただし、DB等のミドルウェアで保存先パスを変更した場合は /etc/apparmor.d/ のプロファイル更新が必要
Web実行ユーザーは www-data を指定する

※ブログ側でも、CentOSからUbuntuへの移転にまつわる環境構築手順や周辺設定のTipsをまとめています。

👉 【Stream9ユーザーが送る】SELinuxの呪文から解放？Ubuntu標準「AppArmor」とアクセス制御のハマりどころ（ブログ記事URL）