Помилка "Не вдалося отримати список спільних ресурсів із сервера" під час перегляду спільної доступу до Nautilus

Трохи перед оновленням з 10.04 до 11.10 мій робочий стіл Ubuntu перестав дозволяти мені отримувати доступ до моїх спільних каталогів Windows. Я подумав, що я перейду до 11.10, і проблема буде виправлена, але ні.

Щоразу, коли я натискаю мережевий домен Windows за допомогою Nautilus, з'являється таке повідомлення:

Неможливо встановити місцеположення - Не вдалось отримати список спільного доступу до сервера

З чого почати вирішення цієї проблеми? Я зараз відчайдушно :(

я намагався

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 ...

Це справжня відповідь на ваше запитання. У мене теж була така ж проблема.

Запустіть термінал і введіть цю команду

gksudo gedit /etc/hosts

і додайте ip адресу та ім’я комп'ютера у файл хостів. Збережіть і вийдіть.

Зразок ip та ім’я:

192.168.120.65    blablaPcName

Це все.

Я знайшов цю пораду від Горда Нікерсона, який працював для мене: Повідомлення про помилку - "не вдалося отримати список спільного доступу з сервера", тому він не може переглядати ПК з Windows 7 або Ubuntu 10 ПК або ПК на робочому столі Mac.

Перш за все, демон Samba, smbdі вони nmbdповинні обидва працювати для перегляду мереж для роботи. Їх можна починати з serviceабо з systemctl startновіших випусків Ubuntu на основі системних даних.

smbtree перелічує всі акції з машин у мережі.

Отже, від /etc/sambaі ми sudo pico smb.conf.

У порядку вирішення імен спочатку використовуються файли хостів і передаються останні, і це коментується! Можливо, ми змінимо це на:

name resolve order = bcast host

а потім перезавантажте сервери за допомогою service smbd restartтаservice nmbd restart

Працює! Це жахлива помилка зробити оновлення. Оновлення не повинно порушувати те, що працює, особливо щось таке важливе, як мережа. Хороша річ, я пам'ятаю ручну роботу, яку вам довелося зробити, щоб повернути самбу на робочий шлях 5 і 6.

Можливо, це загальна помилка підключення до системи:

• http://forums.gentoo.org/viewtopic-t-895820-start-0.html

У наведеному вище випадку потоку виникла невідповідність між іменем та IP-адресою та nmblookupдопомогла визначити проблему. Також на цій сторінці, здається, є кілька хороших порад щодо усунення несправностей

• http://www.linuceum.com/Server/srvSambaTrouble.php

Це я копіюю:

• Перекладіть smbclient в режим налагодження, вихід повинен відображатися в dmesg (-d | --debuglevel = level)
• smbclient -L //<IP of Samba Server> -U <server user>
• nmblookup {name}
• Чи можете ви монтуватись з інших систем?

Відредагуйте своє запитання, якщо ви вирішите більше проблем.

З Ubuntu 14.04:

Ця помилка може бути викликана іменем netbios, розмір якого перевищує 15 символів. Він повинен генерувати журнали у файлі /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 символів.

Я мав дуже хороші результати в змішаних мережевих середовищах (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. Перезавантажте або перезавантажте вашу мережу.

Просто додайте "дозволити" в брандмауер:

• Порт 137 / UDP - використовується nmbd
• Порт 138 / UDP - використовується nmbd
• Порт 139 / TCP - використовується smbd
• Порт 445 / TCP - використовується smbd

І воно спрацює, і якщо ви не знаєте, як це зробити, просто встановіть "gufw", і використовуйте "+", а потім "просту вкладку".

Моя проблема була через /etc/samba/smb.conf. Шукали WORKGROUPта видаляли рядок після неї, в якій було вказано localhostім'я. Переконайтесь, що WORKGROUPпараметр однаковий для обох конфігураційних файлів на кожній машині. Всебічний шлях - це sudo apt-get purge samba(і / або remove?) І потім sudo apt-get install samba. Ось так я вирішував проблему в перший раз, після оновлення з 16.10 до 17.04 на одній із моїх машин (16.10 був для мене помилкою). Зараз у мене дві машини: 16.04 та 17.04.

У мене була ця проблема і її вирішено, встановивши пакет gvfs-bin . За винятком gvfs-bin, більшість пакетів gvfs уже встановлені: gvfs, -common, -libs, -daemons та -backends.

Спробуйте увійти у вікно Windows від Ubuntu за допомогою файлів. Перейдіть до пункту "Інші локації" та "Підключення до Serer" внизу. Використовуйте smb: // ім'я користувача @ serveraddress. Це працювало для мене.

Проблема (принаймні, в Ubuntu 18.04, де я спробував це) полягає в тому, що наступна команда:

sudo ufw allow Samba

додасть лише правила для Samba, що діє як сервер. Це не додасть жодних правил для Samba, яка виступає клієнтом. Але коли ви намагаєтесь змонтувати віддалену спільну спільну роботу, це те, що ви робите: у цьому сценарії ваша машина є клієнтом, а віддалена машина - сервером.

Крім того, помилка "без відповіді" - це натяк на те, що деякий брандмауер псує речі. Машини взагалі відповідають на запити. Вони можуть відповісти помилкою; у цьому випадку у вас є інші проблеми, але якщо вони взагалі не відповідають, тоді їх пакети зазвичай з'їдаються брандмауером.

Правила, які дозволяють Samba діяти як сервер, є недостатніми, щоб також дозволяти Samba виступати в якості клієнта, оскільки віддалені машини відповідають з власного порту 137, але локальний порт, на який надходять ці відповіді, не є 137, це деякі випадковий порт.

Щоб вирішити цю проблему, виконайте таку команду:

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

Це дозволить пакетам UDP надходити в будь-який локальний порт, якщо вони походять з порту 137 або 138 віддаленого комп'ютера. Порт 138, мабуть, не потрібен, оскільки я бачив лише пакети, які прибувають із 137, але ніколи не знаєш.

Це, мабуть, небезпечно, тому що вихідний порт може бути підробленим, але давайте не будемо параноїком.

Це зафіксувало це для мене.

Я міг бачити свій самб-сервер лише за ip адресою.

Перехід bcast до 1-го місця в "порядку вирішення імені = bcast lmhosts хости перемагає". І перезапуск самби. Btw цей 1 рядок перезапускає самбу.

sudo service samba restart

Це теж не вийшло.

Я пішов заглянути, /etc/samba/lmhostsщоб перевірити його та немає файлу! Тож я зробив примхи.

$ sudo nano /etc/samba/lmhosts   
10.0.2.2   server_name 

Я все ще не міг шукати ім'я сервера. Тоді я подумав чекати, ім'я комп’ютера та ім'я самби різні. Тому я редагував хости та ім’я хостів, змінюючи їх на ім’я сервера samba. У обережному імені хоста є лише одне слово. Назва комп’ютера немає # коментарів.

/etc/hosts    
/etc/hostname    
$ sudo reboot 

Зараз це просто працює. Я можу просто натиснути мережу в nautilus або caja, і сервер просто спливе! Усі клієнти - це Linux або Android. Навіть на старій машині віджимання Debian.