Mac の VPN 経由 SMB 共有: まず接続し、次に書き込みを試す
Finder が共有をマウントするのに保存を拒否する? 設定を変える前に VPN の経路、SMB アカウント、サーバーの権限を切り分けましょう。
Finder が VPN 経由で共有をマウントしたのにファイルの保存を拒否するなら、トンネルはすでに役割を果たしており、食い違いはファイルサーバー上の身元と権限にあります。マウント自体が現れないなら、その先は何も検証されていません。どちらも macOS ではよく似たダイアログで終わるため、人々は VPN が起こせない障害のために VPN プロファイルを作り直します。私はまず接続がどこで止まるかを正確に特定し、そのうえで編集しに来た文書ではなく使い捨てのファイルで書き込みを試します。
どこを見るかは三つの条件で決まる
設定に触れる前に三つの答えが必要です。名前がトンネルの通すプライベートアドレスに解決されるか、SMB サービスが指定した特定のアカウントを受け入れるか、そのアカウントがまさにその共有・フォルダ・操作に書き込み権を持つか、それぞれ失敗する場所が違い、VPN 管理者の担当は最初の一つだけです。
| What you see | What it establishes | Who fixes it |
|---|---|---|
| Name does not resolve, or resolves outside the tunnel | The path was never built | VPN or DNS administrator |
| Name resolves, port 445 times out | Route, firewall or overlapping address space | VPN and network owners |
| Server answers, the sign-in is rejected | The file-service account, not the VPN login | File-server owner |
| Share mounts, writing is refused | Share policy or directory rights | File-server owner |
この表に意味があるのは、Mac のログイン、VPN のログイン、SMB アカウントが三つの別々の身元だからです。VPN のパスワードを変えても、登録ユーザーを拒む共有は決して開きませんし、接続済みと報告するクライアントは、狙っているサーバーについて何も語りません。
参照ではなくアドレスで接続する
遠隔の共有は完全に到達可能でありながら、Finder のネットワーク一覧には見えないことがあります。オフィス LAN での検出はブロードキャストとマルチキャストの名前に依存し、多くの VPN はその通信をトンネル越しに運ばないため、空のネットワーク表示はリンク切れの証拠になりません。
目的の VPN を通常のクライアントで起動し、認証を完了します。
Finder で「移動」を選び、「サーバへ接続」を選ぶか、Command-K を押します。
渡されたアドレスを入力します。この例では
smb://files.corp.example/teamです。公開サービスではなく説明用の名前であり、サーバー名しかない場合はそれに接続し、返ってきた一覧から許可された共有を選びます。「登録ユーザ」を選び、ファイルサービスのアカウントを入力します。Mac のアカウントでも VPN のアカウントでもなく、ゲストが正しいのは所有者がそう言う場合だけです。
共有を開き、来た目的の一つの作業だけを行います。フォルダ一覧はマウントを証明するだけで、それ以上ではありません。
Apple の サーバへの接続ガイド はこの Finder の流れと、その背後のサービスログインを説明しています。アドレスをお気に入りに保存すれば次の接続を再現でき、項目名を変えても変わるのはラベルであって接続先ではないことを覚えておきましょう。
どこで止まるかの段階を読む
何かを変える前に、どの段階が失敗するかを Finder で入力した同じ名前で記録します。まず名前解決から: dscacheutil -q host -a name files.corp.example は macOS が使うアドレスを表示し、netstat -rn はそのアドレスがトンネルインターフェース経由か自宅のゲートウェイ経由の経路を持つかを示します。
次に到達性です。nc -vz files.corp.example 445 は SMB ポートがそもそも応答するかを示し、名前解決が通り 445 がタイムアウトするなら、経路・ファイアウォール・アドレス重複の領域で、共有の権限を変えても解決しません。ポートが応答するなら、そのアカウントに何を提供するかをサーバーに尋ねます: smbutil view //[email protected] は共有を一覧し、smbutil statshares -a はマウントされたセッションの交渉済み方言と署名状態を報告し、試しているマウントが思っているものかを教えてくれます。
身元は独自に確認する価値があります。人々が飛ばす手順であり、自分を登録ユーザーだと思っていても、マウントがゲストや古い保存アカウントとして生きていることがあり、その場合の書き込みテストはすべて誤ったアカウントを測っています。
書き込みアクセスには複数の関門がある
サーバー側では二つの層が拒否でき、どちらも Mac からは同じに見えます。共有が読み取り専用で書き出されていても下のフォルダが書き込み可能なことがあり、書き込み可能な共有でもあなたのアカウントを拒むファイルシステム ACL は覆せず、サブフォルダが独自のポリシーを持つこともあります。Windows サーバーでは共有アクセス許可と NTFS アクセス許可が別で、有効な権利は厳しいほうです。
ですから何が本当に拒否されているかを決めます。ファイルの作成、既存ファイルの編集、フォルダの作成、名前の変更、削除。これらは一つの許可ではなく、一覧が通るフォルダでも全部拒否されることがあり、マウントできることは許可ではありません。
身元が違う疑いがあるなら、共有を取り出し、キーチェーンアクセスの古い項目を削除し、登録アカウントで接続し直します。Finder は保存済みセッションを喜んで再利用し、サーバーがあなたと見なさないユーザーの権限を測らせます。
実際の文書に触れずに書き込みを試す
所有者の同意を得て、失敗するフォルダに新しい名前で小さなファイルを一つ作ります: touch /Volumes/team/qa-write-test.txt 共有がそこにマウントされている場合、または単にアプリから新しい名前で別名保存します。アクセス確認のために文書を上書きしてはいけず、VPN がコピーしないエラーの正確な文言を言い換えずに残してください。
次に、一般的な苦情ではなく試した操作を所有者に渡します。所有者は共有ポリシー、アカウントのグループ所属、その一つのフォルダの権限を確認し、どの層が拒否したかを教えられます。メッセージが容量、ロックされたファイル、名前の衝突に触れるなら、それは別の問題で独自の調査に値します。
修正を確認し、順序どおりに取り出す
所有者が何かを変えたら、同じ小さな書き込みを繰り返し、ファイルがサーバーから見え、後で削除できることを確認します。始まってから止まるコピーは転送量の問題で権限の問題ではなく、即座に返る拒否は権限の問題です。
VPN を切る前に共有をアンマウントし、開いている文書を閉じます。トンネルが消えてから取り出すと、Finder とアプリは死んだ経路で待ち続けます。SMB はプライベートネットワーク内に保ち、理論を試すためにファイアウォールを無効にせず、回避策としてフォルダを全員に開かないでください。チケットにはアドレス、アカウント名、失敗した操作、メッセージの正確な文言、時刻を含め、パスワードとプロファイルファイルは載せないでください。
- アドレスはトンネル経由でルーティングされるプライベートアドレスに解決されます。
- ポート 445 が応答し、
smbutil viewは目的のアカウントに対する目的の共有を一覧します。 - 必要だった書き込みは新しいファイルで証明され、既存の文書では証明されません。