& ldquo; Не удалось получить список общих ресурсов с сервера & rdquo; ошибка при просмотре общего ресурса с Nautilus

Это верный ответ на ваш вопрос. У меня тоже была такая же проблема.

Запустите терминал и введите эту команду

gksudo gedit /etc/hosts

и добавьте IP-адрес и имя компьютера в файл hosts. Сохраните и выйдите.

Пример ip и имени:

192.168.120.65    blablaPcName

Вот и все.

Возможно, что это - общая ошибка при соединении с системой:

• 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}
• Можно ли смонтироваться от других систем?

Отредактируйте свой вопрос, если Вы делаете больше поиска и устранения неисправностей.

Я обнаружил, что этот совет от Горда Никерсона сработал для меня: сообщение об ошибке «Не удалось получить список общих ресурсов с сервера», поэтому он не может просматривать компьютер с 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

Works! Это ужасная ошибка в обновлении. Обновление не должно нарушать работоспособность, особенно такую ​​важную вещь, как сетевое взаимодействие. Хорошо, что я вспоминаю ручную работу, которую вы должны были выполнить, чтобы вернуть самбу обратно в redhat 5 и 6.

В 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

ИМЯ-ПК должно содержать не более 15 символов.

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

У меня были очень хорошие результаты в смешанных сетевых средах (Windows / Ubuntu) с этим методом:

1. Нажмите Alt + F2 < / kbd> и введите: 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

   (Или через Центр программного обеспечения или Synaptic ].)

5. Перезагрузите или перезапустите сеть.

Моя проблема была связана с /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.

Просто добавьте «allow out» в брандмауэр:

• Порт 137 / UDP - используется nmbd
• Порт 138 / UDP - используется nmbd
• Порт 139 / TCP - используется smbd
• Порт 445 / TCP - используется smbd

И он будет работать, и если вы не знаете, как это сделать, просто установите "gufw" и используйте «+», а затем «простую вкладку».

Я мог видеть свой сервер Samba только по IP-адресу.

Переключение bcast на 1-е в «Порядок разрешения имен = bcast lmhosts hosts winins». И перезапуск самбы. Кстати, эта 1 строка перезапускает самбу.

sudo service samba restart

Это тоже не сработало.

Я пошел посмотреть в /etc/samba/lmhosts, чтобы проверить его & amp; Нет файла! Итак, я сделал имосты.

$ sudo nano /etc/samba/lmhosts   
10.0.2.2   server_name 

Я все еще не могу найти имя сервера. Тогда я подумал, подождите, имя компьютера & amp; имя самбы разные. Поэтому я отредактировал hosts & amp; имя хоста, меняя их на имя сервера samba. Тщательное имя хоста содержит только одно слово. На компьютере нет ни одного комментария.

/etc/hosts    
/etc/hostname    
$ sudo reboot 

Теперь это просто работает. Я могу просто нажать сеть в nautilus или caja, и сервер просто всплывает! На всех клиентах все Linux или Android. Даже на старом Debian сжать машину.

Попробуйте войти в Windows-систему из Ubuntu с помощью Files. Перейдите в «Другие места» и «Подключиться к Сереру» внизу. Используйте smb: // username @ 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, но Вы никогда не знаете.

Это, вероятно, небезопасно, потому что исходящий порт может имитироваться, но давайте не будем параноиками.

Это зафиксировало его для меня.

​​У меня была такая же проблема в Ubuntu 18.04, и это решение работало для меня.

1. Отредактируйте /etc/samba/smb.conf и добавьте строку client max protocol = NT1 после записи workgroup = WORKGROUP .
2. Перезапустите службу samba, запустив sudo service smbd restart .