web-dev-qa-db-ja.com

Nautilusで共有を参照する際の「サーバーから共有リストを取得できませんでした」エラー

10.04から11.10にアップグレードする少し前に、UbuntuデスクトップでWindows共有ディレクトリにアクセスできなくなりました。 11.10にアップグレードすると、問題は修正されますが、修正されません。

Nautilusを使用してWindowsネットワークドメインをクリックすると、次のメッセージがポップアップ表示されます。

場所をマウントできません-サーバーから共有リストを取得できませんでした

この問題のトラブルシューティングはどこから始めますか？私は今絶望的になっています:(

私は試した

Sudo mount -t cifs //SomeMachine/SomeShare some_directory

そして私は得る

mount error(115): Operation now in progress

奇妙なことに、ポップアップが表示されました：

Could not display network:/// Error: Dbus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply ...
samba
40
jldupont

これはあなたの質問の本当の答えです。私も同じ問題を抱えていました。

ターミナルを実行し、このコマンドを入力します

gksudo gedit /etc/hosts

そして、hostsファイルにコンピューターのIPアドレスと名前を追加します。保存して終了。

サンプルのIPと名前：

192.168.120.65    blablaPcName

それで全部です。

14
Görkem SARI

Gord Nickersonからのこのアドバイスが役立ったことがわかりました：エラーメッセージは「サーバーから共有リストを取得できませんでした」ので、Windows 7 PC、Ubuntu 10 PC、またはMacデスクトップPCを参照できません。

まず、Sambaデーモンsmbdとnmbdの両方が、ネットワークブラウジングが機能するために実行されている必要があります。 Ubuntuの新しいsystemdベースのリリースでは、service、またはsystemctl startで開始できます。

smbtreeは、ネットワーク上のマシンからのすべての共有をリストします。

それで、/etc/sambaとSudo pico smb.confに進みます。

名前解決の順序は、最初にホストファイルを使用し、最後にブロードキャストし、コメント化されます！多分それを次のように変更します：

name resolve order = bcast Host

service smbd restartおよびservice nmbd restartを使用してサーバーを再起動します

動作します！これは、アップグレードで行うのはひどい間違いです。アップグレードは、特にネットワーキングと同じくらい重要な何かが機能していることを壊さないはずです。 Redhat 5および6でsambaを元に戻すためにあなたがしなければならなかった手動作業を思い出します。

12
Jeff King

これは、システムに接続する一般的なエラーである可能性があります。

上記のスレッドの場合、名前とIPアドレスの間に不一致があり、nmblookupが問題の特定に役立ちました。また、このページにはトラブルシューティングのヒントがいくつかあるようです

私がコピーしていること：

  • Smbclientをデバッグモードにすると、出力がdmesgに表示されます（-d | --debuglevel = level）
  • smbclient -L //<IP of Samba Server> -U <server user>
  • nmblookup {name}
  • 他のシステムからマウントできますか？

さらにトラブルシューティングを行う場合は、質問を編集してください。

3
dpb

buntu 14.04の場合：

このエラーは、サイズが15文字を超えるnetbios名が原因で発生する可能性があります。ファイル/var/log/samba/log.smbdに次のようなログを生成します。

register_name: NetBIOS name NAME-OF-PC-TOO-LONG is too long. Truncating to

このエラーは、ファイル/ etc/samba/smb.confを編集し、次の行を追加することで修正できます。

netbios name = NAME-OF-PC

NAME-OF-PCは15文字を超えてはなりません。

2
AizeLauna

ファイアウォールに「許可」を追加するだけです：

  • ポート137/UDP-nmbdで使用
  • ポート138/UDP-nmbdで使用
  • ポート139/TCP-smbdで使用
  • ポート445/TCP-smbdが使用

そして動作します。方法がわからない場合は、「gufw」をインストールし、「+」を使用してから「simple tab」を使用してください。

1
Joao

この方法では、混合ネットワーク環境（Windows/Ubuntu）で非常に良い結果が得られました。

  1. 押す Alt+F2 およびタイプ：gksu gedit /etc/nsswitch.conf

  2. この行を探してください：

    hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4

  3. winsを追加して、次のようにします。

    hosts:  files mdns4_minimal [NOTFOUND=return] wins dns mdns4

  4. 「winbind」パッケージをインストールします。Sudo apt-get install winbind

    （または Software Center または Synaptic 経由）

  5. ネットワークを再起動または再起動します。

1
nejode

問題（少なくとも私が試したUnbuntu 18.04では）は、次のコマンドです：

Sudo ufw allow Samba

サーバーとして機能するSambaのルールのみを追加します。クライアントとして動作するSambaのルールは追加されません。しかし、リモート共有をマウントしようとすると、それがあなたがしていることです。このシナリオでは、マシンはクライアントであり、リモートマシンはサーバーです。

また、「no reply」エラーは、ファイアウォールが混乱していることを示唆しています。通常、マシンはリクエストに応答します。エラーで応答する場合があります。この場合、他の問題がありますが、応答しない場合、通常、パケットはファイアウォールによって食いつぶされています。

Sambaがサーバーとして機能することを許可するルールは、Sambaがクライアントとして機能することを許可するのに十分ではありません。リモートマシンが独自のポート137から応答するためです。ランダムポート。

この問題を解決するには、次のコマンドを実行します。

Sudo ufw allow in proto udp from any port 137,138 to any

これにより、UDPパケットは、リモートコンピューターのポート137または138から発信されている限り、任意のローカルポートに到着できます。 137から到着するパケットを見ただけなので、ポート138はおそらく必要ありませんが、あなたは決して知りません。

発信元のポートがスプーフィングされる可能性があるため、これはおそらく安全ではありませんが、偏執的にならないようにしましょう。

これは私のためにそれを修正しました。

0
Mike Nakis

ファイルを使用して、UbuntuからWindowsボックスにログインしてみてください。下の「その他の場所」と「サーバーに接続」に移動します。 smb：// username @ serveraddressを使用します。これは私のために働いた。

0
Coconutdog

私の問題は/etc/samba/smb.confが原因でした。 WORKGROUPを検索し、localhostの名前に言及している行を削除しました。 WORKGROUPが各マシンの両方の設定ファイルで同じであることを確認してください。すべての方法は、Sudo apt-get purge samba（および/またはremove？）、そしてSudo apt-get install sambaです。これは、私のマシンの1つで16.10から17.04にアップグレードした後、最初に問題を解決する方法です（16.10はバグでした）。 16.04と17.04の2つのマシンがあります。

0
Pixel

この問題が発生したため、パッケージgvfs-binをインストールすることで解決しました。 gvfs-binを除き、gvfs、-common、-libs、-daemons、および-backendsのほとんどのgvfsパッケージが既にインストールされています。

0
Tom