家に小さなネットワークがあり、Windowsに共有フォルダがあります。他のWindowsコンピュータではWindows共有の一覧を表示できますが、Linuxデバイスではこれを行うことはできません。
「Windows共有」をクリックするとノーチラス示す:
Failed to retrieve share list from server: No such file or directory
しかし、驚くべきことに接続することができます。smb://192.168.1.2/SharedFolder
私はテストしましたFedora 23ライブ、ダーバン8そしてDebian テストすべてが同じです。
ポート136、137、138、および445が開いていることも確認しました。
答え1
初期の WannaCry マルウェア感染の後、Microsoft は元の計画よりも早く Windows ディスクとプリンタ共有プロトコル SMB 1.0 の以前のバージョンを使用しなくなりました。
残念ながら、WindowsシステムがActive Directory以外のドメインでネットワーク共有を検索して参照する従来の方法は、依然として以前のプロトコルの一部を使用しています。
非ADネットワーク用の新しいWindows共有検索プロトコルWS-Discovery、SMBプロトコルとは全く別個に、Sambaはまだそのサポートを統合していません。
WindowsシステムにSMB 1.0が無効になっている(セキュリティ上の理由から強くお勧めします)、Active Directoryを使用していない場合、Linuxシステムに新しいプロトコルを使用して利用可能な共有を通知するソフトウェアがない場合、WindowsシステムはSMB 1.0を使用します。できます。 Linux共有は自動的に検出されますが、ユーザーが共有ホストの名前/ IPと共有名を知っている場合は、引き続き接続できます。
Sambaが新しいプロトコルを正常に統合するまで、この問題を軽減するためのいくつかのプロジェクトがあります。
https://github.com/christgau/wsdd- WS-DiscoveryレスポンダのPython 3スクリプト実装。
https://github.com/Andy2244/wsdd2そしてhttps://github.com/kochinc/wsdd2- Netgear ReadyNAS OS 6のオープンソースコードに基づくさまざまなバージョンのC実装。
彼らはSambaの設定を読み、ローカルネットワークのWS-Discoveryクエリに応答します。これを使用するには、ポート5357で着信TCP接続を許可し、ポート3702でマルチキャスト(UDP)トラフィックを許可する必要があります。プロトコルのマルチキャスト部分は、IPv4マルチキャストアドレス239.255.255.250とIPv6マルチキャストアドレスfe02::cを使用します。
クライアント側では、Debian 8 はクライアントツールに新しい検索プロトコルを含めるには古すぎるかもしれません。
答え2
[ipcs]暗黙の共有権限がゲストを許可していることを確認してください。
編集:「サーバー」システムはWindowsシステムなので、Windowsクライアントのデフォルトの動作は現在の資格情報を使用してサーバーにログインしようとしていることを指摘したいと思います。それでも機能しない場合は、ユーザーに代替案を求めるメッセージが表示されます。 WindowsシステムのIPC $共有は、他の共有オブジェクトのリストを取得するために使用される共有であるため、ゲスト(つまり匿名)アクセスを許可する必要があります。したがって、まずWindowsシステムのIPC $に実際に匿名でアクセスできることを確認してください。何も機能しない場合は、Linuxシステムの端末で「smbclient -L 192.168.1.2」を試して、プロンプトでEnterキーを押します。これしなければならないすべてが正しく設定されている場合は機能します。それ以外の場合、運が悪くなり、Windows クライアントのユーザー アカウントが「サーバー」の (一部) アカウントと同じように構成されます。
答え3
この問題が発生し、パッケージをインストールして解決しましたgvfs-bin
。 、、、およびを除くほとんどgvfs-bin
のgvfs
パッケージがインストールされます。gvfs
-common
-libs
-daemons
-backends