なぜSMBファイル共有はWindowsでは動作するのにmacOSでは失敗するのですか？

SMBファイル共有がWindowsで動作しmacOSで失敗する場合、サーバーは完全にオフラインではない可能性が高いです。Windowsはすでに共有が存在し、少なくとも1つのクライアントが到達可能であることを示しています。違いは使用されているアドレス、保存された資格情報、アカウントの識別、SMB交渉、署名要件、共有権限、またはFinderのネットワークフォルダーの扱い方にある可能性が高いです。

最も安全なトラブルシューティング方法は、両方のコンピューターで同じターゲットをテストすることです。正確なサーバーIPと共有名から始め、次にホスト名解決、認証、セキュリティ交渉、権限、Samba互換性、Finderのパフォーマンスへと進みます。Mac全体でレガシーSMBを有効にしたり署名を無効にしたりすることから始めないでください。

まずWindowsとmacOSが同じ共有を開いていることを確認する

Windowsはすでに \\192.168.1.50\Documents、一方でMacユーザーはFinderのサーバーアイコンをクリックしたり、単に smb://server-nameこれらのテストは異なるアドレス、アカウント、または共有パスを示すことがあります。

Windowsコンピューターで動作するサーバーアドレス、共有名、ユーザー名、および接続がIPアドレスかホスト名かを記録します。次にFinderでCommand + Kを押し、smb://192.168.1.50/Documentsのような同等のパスを入力します。

Macが正確なIPと共有パスを開ける場合、SMBサービスと共有は基本的に到達可能です。残る問題は検出、DNS、保存された資格情報、または元のパス形式の可能性が高いです。

Finderの検出に頼る前にサーバーのIPを使用してください

WindowsとmacOSはネットワークデバイスの検出方法が常に同じとは限りません。サーバーはWindowsのファイルエクスプローラーには自動的に表示される一方で、Finderのネットワークビューには表示されないことがあります。

これは必ずしもmacOSがSMBを使用できないことを意味しません。自動検出はDNS、mDNS、NetBIOS互換の動作、ルーターの名前解決、およびファイルサーバーによるアナウンスに依存します。直接アクセスは smb://IP/share ほとんどの検出レイヤーをバイパスします。

IPが機能する場合はSMB設定を変更せず、名前の問題を調査します。ホスト名が正しいアドレスに解決されるか、サーバーがmDNSで自身を広告しているか、Macが古いアドレスをキャッシュしていないかを確認します。

サーバーパスワードをリセットする前に保存された資格情報をクリアする

macOSはキーチェーンに保存されたSMB資格情報を再利用できます。パスワードが変更された場合、同じサーバーにIPとホスト名の両方でアクセスした場合、またはユーザーが以前にゲストアクセスを選択した場合に混乱が生じます。

マウントされた共有を切断し、キーチェーンアクセスを開いてサーバーのホスト名、IPアドレス、共有名を検索します。古いエントリを削除し、再接続してSMBサーバーに実際に存在するアカウントを入力します。

Appleのトラブルシューティング手順は正しいユーザー名、パスワード、ホスト名、共有アクセスの確認から始まります。そのページはmacOSホストのSMB環境に関するものですが、ここでも同じ区別が有用です：認証の成功と特定の共有を使用する権限は異なるチェックです。

Macが正しいアカウントIDを送信していることを確認する

Windowsコンピューターはサインイン済みアカウントで自動的に接続することがあります。macOSでは、ログインダイアログがMacのユーザー名をデフォルトにすることがあり、それはWindows、NAS、またはSambaサーバーに存在しない場合があります。

サーバーはローカルサーバーアカウント、Sambaユーザー、Microsoftアカウント、Active DirectoryのID、またはマシン、ワークグループ、ドメイン名で修飾されたアカウントを期待している場合があります。環境によっては、有効な形式には以下が含まれます username, SERVER\usernameまたは DOMAIN\username.

SMBパスワードとしてWindows Hello PINを使用しないでください。PINは通常、Windowsデバイスをローカルで解除しますが、ファイルサーバーは基盤となるアカウントパスワードまたは他のサポートされている認証方法を必要とします。

Macからポート445に到達可能か確認する

ログインプロンプトが表示される前に正確なSMBパスが失敗する場合は、MacがTCPポート445でサーバーに到達できるか確認してください。Windowsは異なるネットワークインターフェース、VLAN、ファイアウォールプロファイル、または保存されたルートを使用している可能性があります。

macOSでは、次のような簡単なテストがあります nc -vz 192.168.1.50 445 ポートが接続を受け入れるかどうかを示すことができます。タイムアウトはルーティング、VLANの分離、ファイアウォールルール、または期待されるインターフェースでリッスンしていないサーバーを示唆します。

ポート445に到達できるが認証に失敗する場合、物理的なネットワーク経路はもはや主な疑いではありません。資格情報、SMB方言、署名、共有権限に移って調査してください。

SMB方言の交渉は両クライアント間で異なることがあります

古いルーター、レガシーNASデバイス、古いSambaインストールは、あるWindowsコンピューターが受け入れるプロトコルの組み合わせを提供する一方で、最新のMacでは正常に交渉できない場合があります。

長期的な解決策は、SMB1やクライアント側の互換性例外に頼るのではなく、サーバーをSMB2およびSMB3用に設定することです。最新のSamba設定ではSMB2を最小、SMB3を最大プロトコルとして明示的に使用でき、WindowsとmacOSにより明確な交渉範囲を提供します。

Windowsの互換性がサーバー設定が最新であることを証明するとは限りません。SMB1やレガシー認証がそのWindowsマシンで手動で有効になっている可能性があり、Macは異なるセキュリティ基準を使用している場合があります。

署名と認証の要件は一致している必要があります

SMB署名はメッセージが転送中に改ざんされていないことを検証します。クライアントとサーバーがSMBのセキュリティ機能、認証、署名、または検証交渉の動作について意見が合わない場合、接続は失敗することがあります。

Appleは、SMB 3がmacOSのデフォルト接続方法であり、認証されたSMB 3セッションは署名を使用し、特定のディレクトリバウンド環境ではSMB 3の検証交渉およびセッション署名チェック中に失敗することがあると指摘しています。これは特定のOpen Directoryのケースですが、基本的なネットワークではなくセキュリティ交渉中に「接続失敗」の一般的なメッセージが発生する理由を示しています。

設定しないでください signing_required=no または validate_neg_off=yes 最初の応答として。検証や署名を無効にすると、傍受に対する保護が低下します。まずサーバーが最新のSMBバージョンをサポートし、一貫した署名ポリシーを持っていることを確認してください。

ゲストアクセスはWindowsが実際に使用しているものとは限りません

Windowsの共有はパスワードの入力を求められずに開くことがあり、そのためユーザーはゲスト共有だと誤解することがあります。実際には、WindowsはCredential Managerやサインインしているアカウントからキャッシュされた資格情報を再利用している可能性があります。

WindowsクライアントでアクティブなSMBセッションを確認するか、マップされた共有を切断して明示的に再接続してください。その後、Macで同じサーバー側アカウントを使用します。

共有が意図的に匿名の場合、サーバーがゲストアクセスを許可し、ゲストユーザーを適切なファイルシステム権限を持つアカウントにマッピングしていることを確認してください。未解決の認証情報問題を回避するために広範なゲストアクセスを有効にするのは避けてください。

共有の権限とファイルシステムの権限は別物です

Macは認証に成功しても、空の共有を見たり、「アクセス拒否」を受けたり、フォルダを読み取り専用でマウントすることがあります。その場合、SMB接続は成功していますが、ファイルの認可ができていません。

ほとんどのファイルサーバーは少なくとも2層で評価を行います。共有の設定はどのユーザーが共有に入れるかを決め、NTFSの権限、POSIXの所有権、またはファイルシステムのACLがそのユーザーが何を読み取り、作成し、変更し、削除できるかを決定します。

同じサーバーアカウントでWindowsとmacOSをテストしてください。片方のクライアントが異なるユーザーやグループを使っている場合、その結果は直接比較できません。また、Macが誤ってゲストとして接続し、Windowsが認証済みアカウントを使っているかどうかも確認してください。

SambaはmacOSメタデータのサポートを強化する必要があるかもしれません

サーバーがSambaを使用している場合、基本的なWindows互換性があっても理想的なmacOSの動作を保証するわけではありません。FinderやMacアプリは拡張属性、Finderメタデータ、代替データストリーム、リソースフォークを使用しますが、Windowsクライアントはこれらを要求しないことがあります。

WindowsとmacOSの混在利用を想定したSamba設定では、macOSのメタデータをfruitとstreams_xattrで保存することができます。典型的な設定には、Apple固有のメタデータを表現しつつ通常のWindowsアクセスを壊さないようにvfs objects = catia fruit streams_xattrが含まれます。

これらのモジュールは、共有がマウントされているがファイル名、拡張属性、リソースフォーク、Time Machineの動作、またはFinderのメタデータに不整合がある場合に最も関連します。パスワードの誤りやサーバーに到達できない問題を修正する代わりにはなりません。

Finderのパフォーマンス問題は接続失敗のように見えることがある

共有は接続されていることがあるものの、Finderが空のディレクトリを表示したり、大きなフォルダを開く際に数秒間読み込み中の状態が続いたり、応答しなくなることがあります。ユーザーはこれを「SMBが壊れている」と感じますが、実際にはマウント自体は成功しています。

Finderはファイルのメタデータ、権限、プレビュー、リソース情報、ディレクトリの更新を要求することがあります。これらの操作は、特に大きなフォルダやApple向けメタデータ処理がないサーバーでは、基本的なWindowsのディレクトリ一覧とは異なる影響をMacに与えます。

Terminalで同じマウントされた共有をlsなどのコマンドでテストします。 ls大きなディレクトリを先に閲覧せずに大きなファイルをコピーするか、またはTerminalアクセスが機能してFinderが遅い場合は、認証ではなくメタデータやディレクトリ列挙のトラブルシューティングを行ってください。

遅い共有は失敗した共有とは異なります。

認証失敗と転送速度の問題を一つの診断にまとめないでください。共有をマウントできないMacは、マウントは成功するが書き込みが遅いMacとは異なる問題を抱えています。

あるUnraidコミュニティの事例では、読み取り速度が約180 MB/sに達した一方で、書き込みは約2 MB/sに落ち込みました。ローカルディスクやネットワークのテストはもっと高速でした。これは症状のパターンとして有用ですが、署名が普遍的な原因であることを証明するものではありません。ストレージのレイアウト、キャッシュの挙動、小さなファイル、クライアントのインターフェース、Sambaの設定が同様の非対称性を生むことがあります。

ネットワークスループット、大きなファイルの読み取り、大きなファイルの書き込み、多数の小さなファイルの処理を個別に測定します。どのテストが遅いか特定してからSMBのパフォーマンス設定を調整してください。

DockerベースのSambaはユーザーおよびボリュームのマッピング問題を引き起こすことがあります。

SambaコンテナはWindowsからの接続を受け入れつつ、macOSからの接続を拒否することがあります。これは両クライアントが同じIDを提示していないためです。また、コンテナはポート445を正しく公開していても、マウントされたボリュームの所有権やACLが不適合な場合があります。

コンテナ内のSambaアカウント、マウントされたストレージに使用されているホストのUIDとGID、ボリュームの読み書き権限、公開されているポート、および有効な設定を確認します。 smb.confMacが接続を試みている間にコンテナのログを確認します。

リクエストがコンテナに到達し認証に成功した場合、Dockerのネットワーク設定の変更をやめてください。ユーザーマッピング、共有設定、ファイルシステムの所有権、Appleのメタデータサポートに集中しましょう。

クライアント側のSMB調整は最後の層として扱う

オンラインの修正はしばしば長い説明を提供します /etc/nsmb.conf 署名を無効にしたり、ディレクトリキャッシュを変更したり、プロトコルを強制したり、マルチチャネル動作を変更するファイル。これらの設定を一度にすべてコピーすると、どの変更が効果的だったか分からなくなります。

コミュニティでテストされたディレクトリキャッシュと有線マルチチャネル動作に関する変更は、特定のmacOS、ネットワーク、Unraidの組み合わせに役立つ場合があります。同じ議論にはセキュリティを低減するオプションや矛盾する結果も含まれているため、普遍的な設定ではなく実験的なトラブルシューティングとして扱うべきです。

編集前に nsmb.conf現在の状態を保存し、一度に一つのパラメータを変更します。変更ごとに同じフォルダとファイル転送を再テストします。速度のためだけに署名を無効にするのは避けてください。セキュリティのトレードオフを理解し、共有が信頼できるネットワークに限定されている場合のみです。

階層的なトラブルシューティングの順序に従う

最も効果的な手順は正確なターゲットから始め、徐々に特定のクライアント動作へと進みます。Samba、キーチェーン、DNS、署名、Finderの設定を同時に編集しないでください。

動作するWindowsパスから始めてテストします smb://IP/share macOS上でポート445を確認します。その後、保存された認証情報をクリアし、アカウントの本人確認を行い、SMB2/3のサポートを確認します。その後、署名、共有権限、ファイルシステムのACL、SambaのApple拡張機能、Finderのパフォーマンスを調べます。

この手順は各テストの証拠を保持します。IP対ホスト名の結果は検出の問題を特定し、ログインプロンプトは接続可能なSMBサービスを示し、マウントされたが読み取り専用の共有は権限を示し、動作するターミナルセッションと遅いFinderウィンドウはクライアント側の閲覧動作を示します。

最終的な結論

SMBがWindowsで動作しmacOSで失敗する場合、すべてのサーバー設定が正しい証拠としてではなく、Windows接続を参照として使用してください。両クライアントは異なるアドレス、ユーザー名、キャッシュされた資格情報、プロトコル機能、権限を使用している可能性があります。

正確な smb://IP/share パス。IPが機能してホスト名が失敗する場合は検出をトラブルシュートしてください。ログインが失敗する場合はKeychainの資格情報をクリアし、サーバーアカウントを確認してください。認証は成功するがファイルアクセスができない場合は、共有権限とファイルシステムのACLを調査してください。共有はマウントできるがFinderが遅い場合は、メタデータ、SambaのApple拡張機能、性能テストに進んでください。

署名や交渉チェックを無効にするクライアント側のオプションは最後の手段として残すべきです。最新のSMB2/3サーバー、明確なアカウントマッピング、正しい権限、意図的なmacOSメタデータサポートは、説明のつかない設定不一致に対応するためにセキュリティを弱めるよりも信頼性の高い解決策を提供します。

よくある質問

なぜWindowsは私のSMBサーバーを見つけられるのに、Finderは見つけられないのですか？

WindowsとmacOSは異なる検出方法を使うことがあります。正確なサーバーIPと共有パスを使って試してください。 smb://192.168.x.x/shareそれが機能するなら、問題はSMB自体ではなくホスト名の解決や検出にあります。

なぜMacはWindowsで使えるパスワードを何度も拒否するのですか？

MacはKeychainから古いパスワードを再利用しているか、サーバーアカウントではなくローカルのmacOSユーザー名を送信している可能性があります。保存されたSMB資格情報を削除し、ファイルサーバーで定義されたアカウントで再接続してください。

macOSでSMB署名を無効にすべきですか？

最初の対処としては推奨しません。署名を無効にするとメッセージ整合性保護が低下し、古いまたは不整合なサーバー設定が隠れる可能性があります。まずSMB2/3のサポート、資格情報、権限、サーバー署名ポリシーを確認してください。

なぜMacは共有をマウントできるのに、ファイルの作成や編集ができないのですか？

接続と認証は成功しましたが、ユーザーがSMB共有の設定や基盤となるNTFS/POSIXファイルシステムの権限で書き込みアクセス権を持っていない可能性があります。

なぜFinderは遅いのに、Windowsのファイルエクスプローラーは速いのですか？

Finderは追加のメタデータを要求し、大きなディレクトリの列挙により多くの時間を費やすことがあります。セキュリティ設定を変更する前に、直接の大容量ファイル転送をテストし、FinderとTerminalを比較してください。