この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
SE時代、複数人で同じ開発サーバーを使う案件を任されたとき、新規作成したファイルの権限がメンバーごとにバラバラになるという現象に悩まされました。原因はumask（アンマスク。新規作成時の権限からデフォルトで差し引かれる値）の設定がサーバーごと・ユーザーごとに揃っていなかったことでした。
この記事では、その体験をもとに、20年以上Linuxサーバーを運用・指導してきた経験から、umaskの仕組みと「なぜファイルは644で作られ、ディレクトリは755で作られるのか」を実務目線で解説します。
この記事のポイント
・umaskは「初期権限777・666からどれだけ差し引くか」を決める値
・umask 022なら新規ファイルは644、ディレクトリは755になる
・チーム開発ではumaskの統一がPermission deniedの再発を防ぐ
・恒久化は~/.bashrcまたは/etc/profileへの設定が基本
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ新規ファイルの権限がバラバラになるのか｜umaskの仕組み
Linuxで新しくファイルやディレクトリを作ると、権限は自動的に決まります。この「自動的に決まる権限」を制御しているのがumaskです。Linuxの基本仕様として、ファイルの初期権限は666（所有者・グループ・その他すべてに読み書き可能）、ディレクトリの初期権限は777（すべてに読み書き実行可能）からスタートします。ここからumaskで指定した値を差し引いた結果が、実際にファイルやディレクトリが作られたときの権限になります。
差し引くという表現は正確には「ビット単位で反転させたumaskの値とAND演算する」処理ですが、実務でよく使う組み合わせに限れば「666からumaskを引けばファイルの権限、777からumaskを引けばディレクトリの権限」とほぼ一致すると覚えておけば十分です。umaskのデフォルトが022であれば、ファイルは644（所有者は読み書き、グループとその他は読み取りのみ）、ディレクトリは755（所有者は読み書き実行、グループとその他は読み取りと実行のみ）になります。
私が最初にこの仕組みでつまずいたのは、「なぜ自分が作ったファイルだけ644になり、同僚が作ったファイルは640になるのか」という素朴な疑問からでした。答えは単純で、サーバーやユーザーごとにumaskの設定値が違っていたからです。デフォルト値は環境依存であり、「Linuxなら必ずこうなる」という固定値ではありません。
共有サーバーで実際に何が起きたのか｜権限バラバラ事件の顛末
1. ある日突然、他のメンバーが作ったファイルが編集できなくなった
複数人で同じ開発サーバーにSSH接続し、共有ディレクトリ配下でスクリプトを作成・修正する案件がありました。ある朝、前日に同僚が作成した設定ファイルを編集しようとしたところ、書き込み権限がなくエラーになりました。ファイル自体は存在していて、自分のアカウントもグループには所属している。それでも書き込めない。原因の見当がまったくつきませんでした。まずやったのは
ls -lで対象ファイルの権限を確認することでした。すると、自分が作ったファイルは644（グループに読み取り権限あり）、同僚が作ったファイルは640ではなく600（所有者以外は一切読み書きできない）になっていることに気づきました。同じサーバー、同じグループで作業しているのに、なぜここまで違うのかが最初の謎でした。
2. 原因はumaskのデフォルト値のズレだった
調べていくと、同僚のアカウントには過去の別案件でumask 077が個人の設定ファイルに書き込まれたまま残っていたことがわかりました。umask 077は「グループにもその他にも一切権限を渡さない」という、個人専用サーバー向けの厳しい設定です。共有作業をするサーバーでこの値のままだと、本人以外は誰も編集どころか閲覧すらできないファイルばかりが生まれてしまいます。一方で自分のアカウントはumask 022のままでした。デフォルトのまま特に意識せず使っていただけなのですが、結果として「グループに読み取りは許可するが書き込みは許可しない」644のファイルばかりを作っていたことになります。どちらも「間違い」ではなく、それぞれの用途に合った設定ではあるのですが、チーム作業の前提が揃っていなかったことが問題でした。
3. サーバーごとにumaskがバラバラだった理由
さらに調べを進めると、サーバーによって/etc/profileやログインシェルの初期設定でumaskの既定値が異なっていることもわかりました。ディストリビューションや構築時の設定次第で、rootユーザーはumask 022、一般ユーザーはumask 002という組み合わせもあれば、その逆のケースもあります。「Linuxのumaskは022が標準」という思い込みだけで運用していると、こうしたサーバーごとの差異に足をすくわれます。セミナーで3,100名以上を指導してきた中でも、umaskを一度も意識せずにサーバーを使い続けている受講生を数多く見てきました。困った経験がなければ気づく機会がないのも当然で、私自身もこの共有サーバーの一件がなければ、umaskをきちんと理解しないまま現場に出ていたと思います。
umaskを実務で使いこなすための3つのポイント
現在の値を確認するだけならumaskコマンドを引数なしで実行するだけです。# umask 0022 # touch sample.txt # mkdir sample_dir # ls -l sample.txt -rw-r--r-- 1 miyazaki devteam 0 8月 26 10:15 sample.txt # ls -ld sample_dir drwxr-xr-x 2 miyazaki devteam 4096 8月 26 10:15 sample_dir
このコマンドで確認したumaskはログインシェルを閉じると失われる一時的な値です。共同作業をするサーバーでチーム全体の値を揃えたい場合は、ユーザー個別の設定ファイルに恒久化して記述します。
# ~/.bashrcにumaskを追記して恒久化する $ vi ~/.bashrc umask 002 $ source ~/.bashrc $ umask 0002
もうひとつ実務で重要なのは、umaskは「あくまで新規作成時にだけ効く」という点です。すでに存在するファイルの権限には一切影響しません。過去に作られた大量のファイルの権限を一括で揃えたい場合は、umaskではなくfindとchmodを組み合わせる必要があります。この違いを理解していないと、「umaskを変えたのに古いファイルの権限が変わらない」と混乱する人を何人も見てきました。
「Permission denied」でハマった時のトラブル対処法
umask設定を疑うべき典型的なエラーが、共有ディレクトリでの「Permission denied」です。以下は実際に発生した状況を再現したものです。# 共有ディレクトリでよくあるPermission denied $ vi /shared/deploy/config.yml E212: Can't open file for writing $ ls -l /shared/deploy/config.yml -rw-r----- 1 sato devteam 512 8月 20 09:12 config.yml $ groups miyazaki devteam
このようなエラーに遭遇したときのトラブルシュートの手順は次のとおりです。まず
ls -lで対象ファイルの現在の権限を確認します。次にgroupsコマンドで自分が本当にそのグループに所属しているかを確認します。ここで所属していなければ話は別問題（グループ追加が必要）になります。所属しているのに書き込めない場合は、作成者側のumaskが厳しすぎることが原因である可能性が高いので、chmodでその場を解決しつつ、恒久対応として共有ディレクトリを使う全ユーザーのumaskを002に揃えることを提案します。なお、chmodによるその場対応はあくまで応急処置です。umaskを揃えないまま放置すると、新しいファイルが作られるたびに同じ「Permission denied」が再発します。根本原因はファイル単位ではなく設定単位にあることを忘れないようにしてください。
本記事のまとめ
| 体験・気づき | 学んだこと |
|---|---|
| 同僚のファイルだけ権限が厳しく編集できなかった | umaskはサーバー・ユーザーごとに値が異なることがある |
| umaskの仕組みを知らずchmodで都度対応していた | 666・777から差し引く仕組みを理解すれば予測できる |
| umaskを変えても古いファイルの権限が変わらなかった | umaskは新規作成時のみ有効。既存ファイルはfind+chmodで対応 |
| 共有ディレクトリでPermission deniedが再発していた | チームでumask 002に統一することが根本対策になる |
| umaskの確認・変更方法を知らなかった | umaskコマンドで確認し、~/.bashrcで恒久化する |
umaskのような「地味だけど事故を防ぐ知識」を体系的に身につけませんか？
権限まわりのトラブルは、原因さえわかれば防げるものがほとんどです。でも、その「原因の見当をつける力」は断片的な知識のコピペでは身につきません。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxのシンボリックリンクを「ただのショートカット」だと思っていた日の話｜ln -sの仕組みを本当に理解するまでにあった3つの誤解
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます