QNAP TS-462 で同期コピーしたフォルダにアクセスできなくなった問題と解決まで

はじめに

QNAP NAS のデータを、コピー元NASからコピー先NASへ HBS3 で一方向同期したところ、特定のフォルダにアクセスできなくなる問題が発生した。

原因の特定にはかなり時間がかかったが、根本はかなり昔、自宅 FreeBSD 環境で使っていた UID と、QNAP NAS の世代交代によるアカウント構成の変化だった。

いわば、20年越しの UID 問題が、今回の NAS 再構成で表面化した形である。

同じように、長年 NAS を使い続け、古い UNIX 系環境や複数世代の NAS からデータを引き継いできた人には参考になるかもしれないので、記録しておく。

今回の構成

今回実際に作業対象となった NAS は、以下の2台である。

コピー元NAS：TS-431P で使っていた HDD を移設して運用していた TS-462
コピー先NAS：新規セットアップした TS-462
同期方法：HBS3 による一方向同期（RTRR）

TS-431P は過去に使用していた NAS であり、今回の作業時点ではすでに現役ではない。

ただし、コピー元NASは TS-431P で使っていた HDD を引き継いでいるため、UID や権限の経緯を説明する上では TS-431P 時代の話が関係してくる。

また、この記事ではセキュリティ上の理由から、実際のアカウント名は伏せ、以下の仮名を使う。

AdminUser：コピー先NASで作成した管理者ユーザー
MyUser：通常利用する一般ユーザー

QNAP のデフォルト管理者ユーザーである admin については、そのまま admin と表記する。

発生した問題

HBS3 でコピー元NASからコピー先NASへ同期した後、特定のフォルダにアクセスできなくなった。

具体的には、以下のような症状だった。

File Station で特定フォルダだけ開けない
Windows PC から NAS にアクセスしても、当該フォルダを開けない
SSH で ls しても Permission denied
mv・cp も Permission denied
同じ階層の他のフォルダは正常に開ける
getfacl・getfattr の結果はコピー元NASとコピー先NASで一致
File Station の「詳細権限（ACL）」ボタンが表示されない
File Station 上でそのフォルダの削除・移動・コピーができない

当初は HBS3 の同期不具合、ACL、拡張属性、あるいはファイルシステム属性の問題を疑った。

しかし、切り分けを進めるうちに、問題はファイルシステムの破損や同期ミスではなく、所有者・権限・UID に起因している可能性が高くなった。

混乱の元：実際にファイルへアクセスしているユーザーが違っていた

今回の混乱の大きな原因は、コピー元NASとコピー先NASで、実際にファイルへアクセスしているユーザーの権限が異なっていたことだった。

コピー元NASでは、従来通り admin ユーザーが有効になっており、Web管理画面や File Station にも admin でログインしていた。

この admin は UID=0、つまり root 権限を持つユーザーだった。

そのため、コピー元NASの File Station では、UID=127 所有でパーミッションが drwx--x--x のフォルダも問題なく見ることができていた。

一方、コピー先NASは新規セットアップした TS-462 である。

この初期セットアップ時には、デフォルトの admin ユーザーでのログインを無効化し、代わりに別の管理者アカウントを作成する流れになっていた。

この記事では、この管理者アカウントを AdminUser と呼ぶ。

AdminUser は管理者権限を持つユーザーではあるが、UID=0 の root ではない。今回の環境では UID=1000 だった。

つまり、コピー先NASでは Web管理画面・File Station・SSH/CUI のいずれでも、従来の admin、すなわち UID=0 のユーザーとしてアクセスすることができなくなっていた。

整理すると、以下のようになる。

	コピー元NAS	コピー先NAS
Web管理画面 / File Station	admin	AdminUser（仮称）
SSH / CUI	admin	AdminUser（仮称）
UID	0	1000
root相当か	はい	いいえ

これが、コピー元NASの File Station では見えていたフォルダが、コピー先NASの File Station では見えない、という現象の大きな原因だった。

さらに、Windows PC から SMB 経由でアクセスする場合も、実際には NAS 上のいずれかのユーザー権限でアクセスすることになる。

そのユーザーは UID=127 の所有者ではなく、root でもなかったため、同じく当該フォルダを開けなかった。

つまり今回の問題は、SSH だけの問題ではなかった。

File Station、SSH、Windows PC からの SMB アクセスのいずれでも、実効ユーザーが UID=127 の所有者でも root でもないため、UID=127 所有で drwx--x--x のフォルダを開けない状態になっていた。

コピー元NASでは root 相当の admin で見ていたため問題が隠れており、コピー先NASでは root ではない AdminUser や SMB アクセスユーザーで見たため、古い UID とパーミッションの問題が表面化したのである。

調査の経緯：同期不具合ではなく権限問題に絞り込む

当初は、HBS3 の同期時に ACL・拡張属性・ファイルシステム属性のいずれかが崩れた可能性を疑った。

まず、コピー元NASとコピー先NASで getfacl・getfattr の結果を比較したが、両者に大きな差はなかった。

この時点で、少なくとも ACL や拡張属性が直接の原因である可能性は低そうだった。

次に、File Station 上の表示や SSH での挙動から、ファイルシステム属性の影響も疑った。

しかし、sudo ls では当該フォルダの中身が見えることがわかった。

この結果から、ファイルシステム属性そのものが壊れているというより、アクセスしているユーザーの実効権限の違いが原因である可能性が高くなった。

ここで問題フォルダの stat を確認すると、以下のようになっていた。

Access: (0711/drwx--x--x)  Uid: (127/ UNKNOWN)  Gid: (0/administrators)

所有者は UID=127 だが、コピー先NAS上には UID=127 のユーザーが存在しないため UNKNOWN と表示されている。

パーミッションは drwx--x--x だった。

つまり、UID=127 の所有者でも root でもないユーザーからは、ディレクトリの一覧表示ができない状態だった。

これにより、File Station、SSH、Windows PC からの SMB アクセスのいずれでも当該フォルダを開けなかった理由が説明できた。

UID=127 の正体

では、そもそも UID=127 とは何だったのか。

これは、20年以上前に使っていた自宅 FreeBSD 環境の個人ユーザー MyUser の UID だった。

当時、自宅 FreeBSD PC では MyUser の UID が 127 だった。

その後、FreeBSD で ZFS を使った自宅ファイルサーバを運用していた時期があり、この環境でも MyUser の UID=127 を使っていた。

その後、FreeBSD + ZFS の自宅ファイルサーバから TS-431P へデータを移行した。

このとき rsync によりファイル所有者の UID 情報も保持されたため、TS-431P 上にも UID=127 所有のファイルやフォルダが残ったと考えられる。

QNAP 側で MyUser を UID=127 に明示的に設定していたかどうかは記憶が曖昧だが、少なくとも TS-431P 上のデータには UID=127 所有のファイルやフォルダが残っていた。

一方、TS-431P 上で通常利用する一般ユーザー MyUser を作成した際には、UID=127 ではなく UID=500 になっていたと思われる。

つまり、TS-431P 上では次のような状態になっていた。

過去データの所有者：UID=127
QNAP 上の MyUser：UID=500
Web管理画面・File Station・SSH で使っていた admin：UID=0

ただし、TS-431P では admin(uid=0) で運用していたため、UID=127 所有のフォルダも問題なく見えており、この UID 不整合に気づきにくかった。

UID がずれていった経緯

今回の経緯をまとめると、以下のようになる。

自宅 FreeBSD PC
  MyUser = UID 127
  ↓
FreeBSD + ZFS の自宅ファイルサーバ
  MyUser = UID 127 のまま運用
  ↓
TS-431P へ移行
  FreeBSD + ZFS ファイルサーバから rsync でデータをコピー
  過去データの所有者 UID=127 が保持される

  一方、TS-431P 上で MyUser を通常作成した結果、
  MyUser = UID 500 になっていたと思われる

  ただし admin(uid=0) で運用していたため、
  UID=127 所有のフォルダも見えており、問題に気づきにくかった
  ↓
TS-431P で使っていた HDD を TS-462 に移設
  既存環境を引き継いだコピー元NASとして運用
  引き続き admin(uid=0) で Web管理画面・File Station・SSH を使っていたため、
  UID=127 所有のフォルダも見えていた
  ↓
新規セットアップした TS-462
  初期セットアップ時に admin ログインを無効化し、
  代わりに管理用アカウント AdminUser（仮称）を作成
  AdminUser は UID=1000 であり、root ではない
  Web管理画面・File Station・SSH/CUI でも admin(uid=0) としてはアクセスできない

  一般ユーザー MyUser は UID=1001 で作成された
  ↓
HBS3 でコピー先NASへ同期
  UID=127 所有・drwx--x--x のフォルダが、
  File Station・SSH・Windows/SMB から見えない問題として表面化
  ↓
今回の対処
  コピー先NASの MyUser=UID1001 に合わせて、
  コピー元NAS側の MyUser も UID=1001 に変更
  UID=127 および UID=500 のファイル・ディレクトリを MyUser 所有に整理

要するに、昔の運用ミスというより、FreeBSD 時代からの UID がデータ側に残り続け、さらに TS-431P 以降のユーザー UID とずれていたにもかかわらず、admin(uid=0) で見えていたため問題が長らく隠れていた、ということになる。

そして MyUser=UID1001 への統一は、TS-462 の初期セットアップ時点の設計ではなく、今回の問題を調査した結果として決めた整理方針である。

根本原因のまとめ

根本原因は、単に「QNAP の UID が古かった」という話ではない。

正確には、以下の複合要因だった。

自宅 FreeBSD PC で、MyUser の UID が 127 だった
その後、FreeBSD + ZFS の自宅ファイルサーバでも UID=127 のまま運用していた
FreeBSD + ZFS のファイルサーバから TS-431P へ rsync で移行した際、UID=127 の所有者情報が保持された可能性が高い
TS-431P 上にも UID=127 所有の古いフォルダやファイルが残り続けていた
一方で、TS-431P 上の MyUser は UID=500 になっていたと思われる
TS-431P および、TS-431P で使っていた HDD を移設したコピー元NASでは admin(uid=0) で運用していたため、問題が見えにくかった
コピー先NASでは初期セットアップ時に admin ログインを無効化し、代わりに AdminUser を作成していた
AdminUser は UID=1000 であり、UID=0 の root ではなかった
コピー先NASで作成した一般ユーザー MyUser は UID=1001 だった
Windows PC から SMB 経由でアクセスする場合も、実効ユーザーが UID=127 の所有者でも root でもなかった
問題フォルダのパーミッションが drwx--x--x で、UID=127 の所有者でも root でもないユーザーからは一覧表示できなかった

結果として、コピー先NASの File Station、SSH、Windows PC からのアクセスのいずれでも、特定フォルダの中身が見えなくなっていた。

対処した内容

1. コピー先NASに一般ユーザーを作成

コピー先NASの QTS 管理画面で一般ユーザー MyUser を作成した。

このとき、コピー先NASでは MyUser の UID は 1001 になった。

また、MyUser を administrators グループに追加した。

2. コピー元NASの MyUser UID を 1001 に統一

今回の問題が発覚した後、最終的な対処方針として、コピー先NASで作成された MyUser(uid=1001) に合わせ、コピー元NAS側の MyUser も UID=1001 に統一することにした。

コピー元NASでは MyUser が UID=500 になっていたため、QTS 管理画面の GUI から UID=1001 に変更し、コピー先NASと揃えた。

そのうえで、過去データに残っていた UID=127 と、TS-431P 時代の MyUser に対応していたと思われる UID=500 のファイル・ディレクトリを、MyUser 所有に変更する方針にした。

3. コピー元NASで chown を一括実行

コピー元NAS側で、過去の UID=127 および UID=500 のファイル・ディレクトリを MyUser 所有に変更した。

ここでは所有者のみを MyUser に変更し、グループは原則として既存のまま維持した。

通常ファイル・ディレクトリと、シンボリックリンクは分けて処理した。

# uid=500 → MyUser（通常ファイル・ディレクトリ）
find /share/CACHEDEV1_DATA/ -user 500 ! -type l -exec chown MyUser {} \; > /tmp/chown_500.log 2>&1 &

# uid=500 → MyUser（シンボリックリンク）
find /share/CACHEDEV1_DATA/ -user 500 -type l -exec chown -h MyUser {} \; > /tmp/chown_500l.log 2>&1 &

# uid=127 → MyUser（通常ファイル・ディレクトリ）
find /share/CACHEDEV1_DATA/ -user 127 ! -type l -exec chown MyUser {} \; > /tmp/chown_127.log 2>&1 &

# uid=127 → MyUser（シンボリックリンク）
find /share/CACHEDEV1_DATA/ -user 127 -type l -exec chown -h MyUser {} \; > /tmp/chown_127l.log 2>&1 &

シンボリックリンクに対しては chown -h が必要だった。

-h を付けないと、シンボリックリンクそのものではなくリンク先を変更しようとするため、リンク先が存在しない場合などにエラーになる。

対象件数が多かったため、実行にはそれなりに時間がかかった。

通常の Linux 環境であれば find ... -exec chown ... {} + のようにまとめて実行する方法もあるが、QNAP の環境ではコマンドやオプションの挙動が一般的な Linux と異なる場合がある。

今回は対象件数が多かったため、ログを取りながら、環境上で確実に動作する形で実行した。

4. Windows 関連フォルダに chmod を実施

所有者を MyUser に変更しただけでは、フォルダによってはグループに読み取り権限がない状態が残る。

ただし、すべてのフォルダに一律で chmod するのは避けた。

FreeBSD 時代のホームディレクトリバックアップなど、UNIX 由来のフォルダについては、元のパーミッションをなるべく維持したかったためである。

一方、Windows 由来で共有前提のフォルダについては、グループに読み取り・実行権限を付与した。

以下は対象フォルダ名も記事用に伏せた例である。

for dir in Directory1 Directory2 Directory3 Directory4; do
    find /share/CACHEDEV1_DATA/share_root/$dir -user MyUser -type d ! -perm -g+r -exec chmod g+rx {} \;
    find /share/CACHEDEV1_DATA/share_root/$dir -user MyUser -type f ! -perm -g+r -exec chmod g+r {} \;
done

ここでの方針は、全体を雑に開放するのではなく、Windows 関連フォルダに限定して、共有利用に必要な権限を付与することだった。

5. HBS3 で再同期

コピー元NAS側で chown・chmod を行った後、HBS3 でコピー先NASへ再同期した。

ここで重要なのは、修正をコピー元NAS側で行ったことだ。

コピー先NAS側で直接修正しても、次回の一方向同期でコピー元NAS側の状態に上書きされてしまう可能性がある。

そのため、同期元であるコピー元NASを正とし、コピー元NAS側で所有者・権限を修正してから、コピー先NASへ反映させた。

6. コピー先NASで残存 UID=127 を直接 chown

一部、HBS3 の同期対象外だったフォルダに UID=127 が残っていた。

このフォルダについては、コピー先NAS側で直接処理した。

以下はフォルダ名を記事用に伏せた例である。

sudo find /share/CACHEDEV1_DATA/share_root/OldBackup/ -user 127 ! -type l -exec chown MyUser {} \;
sudo find /share/CACHEDEV1_DATA/share_root/OldBackup/ -user 127 -type l -exec chown -h MyUser {} \;

コピー元NASでは admin、つまり root 権限で SSH ログインしていたため sudo なしで実行していた。

一方、コピー先NASでは AdminUser で SSH ログインしていたため、必要に応じて sudo を付けて実行した。

結果

対処後、以下の状態になった。

File Station で問題のフォルダを正常に開けるようになった
SSH での ls も正常に実行できるようになった
Windows PC からのアクセスも正常になった
コピー元NASとコピー先NASで MyUser の UID を 1001 に統一できた

これで、今回の同期コピー先でも問題なくファイルにアクセスできるようになった。

教訓

1. UID の棚卸しは重要

長年 NAS を使い続けていると、昔の UID がファイル所有者として残り続けることがある。

特に、UNIX 系 OS、自宅サーバー、rsync、NAS マイグレーションなどを組み合わせて使ってきた場合、現在のユーザー一覧には存在しない UID が残っていることがある。

今回の UID=127 は、まさにその例だった。

2. 当時は自然だった状態が、後年問題化することがある

FreeBSD 環境で MyUser の UID が 127 だったこと自体は、当時の環境では自然なことだった。

また、FreeBSD + ZFS のファイルサーバから TS-431P へ rsync で移行したことで、過去データの所有者 UID が保持された可能性が高い。

それ自体はデータ移行としては自然な挙動だが、その後の NAS 世代交代やユーザー管理仕様の変化により、現在のユーザー UID と過去データの UID がずれていった。

その結果、かつては問題になっていなかった UID の不整合が、20年後に表面化した。

3. admin と AdminUser は別物

QNAP の admin と、コピー先NASで作成した AdminUser は、どちらも管理者ユーザーのように見えるが、UID が異なる。

今回のコピー元NASでは admin が UID=0 であり、Web管理画面、File Station、SSH のいずれでも root 相当の権限でアクセスできていた。

一方、コピー先NASの AdminUser は UID=1000 であり、root ではなかった。

さらに、コピー先NASでは初期セットアップ時に admin ログインを無効化していたため、Web管理画面・File Station・SSH/CUI のいずれでも admin(uid=0) としてアクセスできなかった。

そのため、コピー元NASの File Station では見えていたファイルが、コピー先NASの File Station では見えないという事態が起きた。

これは SSH だけの問題ではなく、Web管理画面や File Station でどのユーザーとしてアクセスしているかにも関係する問題だった。

さらに、Windows PC から SMB 経由でアクセスする場合も、実際には NAS 上のどのユーザーとして認証され、そのユーザーが対象フォルダに対してどの権限を持つかが効いてくる。

そのため、File Station、SSH、Windows PC からのアクセスのいずれでも、UID=127 所有で drwx--x--x のフォルダを開けない状態になった。

4. File Station で見えるからといって、権限問題がないとは限らない

コピー元NASでは admin(uid=0) で File Station を使っていたため、UID=127 所有のフォルダも問題なく見えていた。

しかし、それは権限設定が正しかったからではなく、root 相当のユーザーで見ていたため問題が隠れていただけだった。

コピー先NASでは admin ログインが無効化され、AdminUser(uid=1000) や SMB アクセスユーザーでアクセスすることになったため、古い UID とパーミッションの問題が表面化した。

NAS の移行時には、File Station で見えるかどうかだけでなく、どのユーザー権限で見えているのかも確認した方がよい。

5. シンボリックリンクの chown には `-h` が必要

シンボリックリンクの所有者を変更する場合は、chown -h が必要である。

-h を付けないと、シンボリックリンクそのものではなくリンク先を変更しようとする。

リンク先が存在しない場合などにはエラーになるため、通常ファイル・ディレクトリとシンボリックリンクは分けて処理した方が安全である。

6. QNAP の BusyBox 環境には制約がある

QNAP の SSH 環境では、一般的な Linux で使えるコマンドやオプションが使えないことがある。

たとえば、環境によっては以下のような機能が制限される。

nohup
fuser
find -printf

そのため、QNAP 上で作業する場合は、実際にその環境で使えるコマンドを確認しながら進める必要がある。

7. 同期中に chown しない

HBS3 の同期中に chown や chmod を行うと、不整合が起きる可能性がある。

大量のファイルを処理する場合は、同期ジョブを止めた状態で所有者・権限を修正し、その後で再同期する方が安全である。

8. 一方向同期では、修正は同期元で行う

一方向同期の場合、コピー先NASで直接修正しても、次回同期時にコピー元NASの内容で上書きされる可能性がある。

そのため、原則として修正は同期元であるコピー元NAS側で行い、その結果をコピー先NASへ反映させるのが安全である。

今回も、基本的にはコピー元NAS側で chown・chmod を行い、その後 HBS3 でコピー先NASへ再同期した。

補足：TS-431P から TS-462 へのシステム移行について

なお、現在 QNAP の「NAS システム移行の互換性」ページで確認すると、TS-431P から TS-462 へのシステム移行は対応外と表示される。

当時の確認状況は記憶が曖昧だが、少なくとも現在の案内では、ファイルおよびデータを別の NAS に移動するには、HBS を使用してバックアップ・復元する方法が示されている。

もし TS-431P で使っていた HDD をそのまま TS-462 に移設するのではなく、このタイミングで HBS によるバックアップ・復元を行っていれば、UID や所有者情報の不整合に気づき、整理する機会になっていたかもしれない。

ただし、今回の直接原因はあくまで、UID=127 所有のデータと、コピー先NASでの実効ユーザー権限の違いである。

確認に使えそうなコマンド

今後、同じような問題を確認するには、以下のようなコマンドが役に立つ。

特定 UID のファイル・ディレクトリを探す場合。

find /share/CACHEDEV1_DATA/ -user 127 -ls
find /share/CACHEDEV1_DATA/ -user 500 -ls

ユーザー名に解決できない所有者を探す場合。

find /share/CACHEDEV1_DATA/ -nouser -ls

グループ名に解決できないグループを探す場合。

find /share/CACHEDEV1_DATA/ -nogroup -ls

ただし、QNAP の BusyBox 環境では、find のオプションが一般的な Linux と異なる場合がある。

実行前に、対象環境で使えるか確認した方がよい。

おわりに

今回の問題は、単純な QNAP の設定ミスや HBS3 の同期ミスではなかった。

自宅 FreeBSD 環境の UID、FreeBSD + ZFS の自宅ファイルサーバ、TS-431P への rsync 移行、TS-431P で使っていた HDD を移設したコピー元NAS、そして新規セットアップしたコピー先NASへの同期が重なった結果、20年越しに表面化した問題だった。

昔の FreeBSD 環境で使っていた UID が、データの所有者情報として残り続けていたこと自体は自然なことだった。

しかし、NAS の世代交代やユーザー管理仕様の変化により、いつの間にか現在のユーザー UID と過去データの UID がずれていた。

さらに今回、コピー元NASでは root 相当の admin で File Station を使っていた一方、コピー先NASでは root ではない AdminUser で File Station を使っていたため、問題が一気に見える形になった。

また、Windows PC から SMB 経由でアクセスする場合も、実効ユーザーの権限が対象フォルダに対して不足していたため、同じようにフォルダを開けなかった。

長年使っている NAS ほど、こうした古い UID や権限情報が残っている可能性がある。

NAS のマイグレーションや再構成を行うときは、データのコピーだけでなく、所有者 UID・GID・パーミッション、そして File Station や SMB など各アクセス経路で実際に使われるユーザーの権限も一度棚卸しした方がよさそうだ。

今回の件は、まさに「20年越しに現れた UID の亡霊」のような問題だった。

QNAP TS-462 で同期コピーしたフォルダにアクセスできなくなった問題と解決まで

はじめに

今回の構成

発生した問題

混乱の元：実際にファイルへアクセスしているユーザーが違っていた

調査の経緯：同期不具合ではなく権限問題に絞り込む

UID=127 の正体

UID がずれていった経緯

根本原因のまとめ

対処した内容

1. コピー先NASに一般ユーザーを作成

2. コピー元NASの MyUser UID を 1001 に統一

3. コピー元NASで chown を一括実行

4. Windows 関連フォルダに chmod を実施

5. HBS3 で再同期

6. コピー先NASで残存 UID=127 を直接 chown

結果

教訓

1. UID の棚卸しは重要

2. 当時は自然だった状態が、後年問題化することがある

3. admin と AdminUser は別物

4. File Station で見えるからといって、権限問題がないとは限らない

5. シンボリックリンクの chown には `-h` が必要

6. QNAP の BusyBox 環境には制約がある

7. 同期中に chown しない

8. 一方向同期では、修正は同期元で行う

補足：TS-431P から TS-462 へのシステム移行について

確認に使えそうなコマンド

おわりに

コメントを残すコメントをキャンセル

アーカイブ

メタ情報

QNAP TS-462 で同期コピーしたフォルダにアクセスできなくなった問題と解決まで

はじめに

今回の構成

発生した問題

混乱の元：実際にファイルへアクセスしているユーザーが違っていた

調査の経緯：同期不具合ではなく権限問題に絞り込む

UID=127 の正体

UID がずれていった経緯

根本原因のまとめ

対処した内容

1. コピー先NASに一般ユーザーを作成

2. コピー元NASの MyUser UID を 1001 に統一

3. コピー元NASで chown を一括実行

4. Windows 関連フォルダに chmod を実施

5. HBS3 で再同期

6. コピー先NASで残存 UID=127 を直接 chown

結果

教訓

1. UID の棚卸しは重要

2. 当時は自然だった状態が、後年問題化することがある

3. admin と AdminUser は別物

4. File Station で見えるからといって、権限問題がないとは限らない

5. シンボリックリンクの chown には -h が必要

6. QNAP の BusyBox 環境には制約がある

7. 同期中に chown しない

8. 一方向同期では、修正は同期元で行う

補足：TS-431P から TS-462 へのシステム移行について

確認に使えそうなコマンド

おわりに

コメントを残す コメントをキャンセル

アーカイブ

メタ情報

5. シンボリックリンクの chown には `-h` が必要

コメントを残すコメントをキャンセル