Ошибка samba отказано в доступе

Samba нет прав на запись

Данная статья в первую очередь касается новичков, которые только начали изучать Linux системы. И так вы установили Samba сервер, создали общею папку настроили к ней доступ. Но пользователи не могут записать в неё файлы папки. Мы сейчас говорим о самом простом доступе к общему ресурсу без настройки учетных данных. Т.е у них нет прав на запись. Решить эту проблему достаточно просто.

Если вы совсем недавно начали изучать Linux системы, то рекомендую прочитать вот эти статьи.

Вообще можете перейти в раздел Linux и почитать статьи там достаточно много всего интересного.

Почему пользователь не может создать файл или папку

И так общей ресурс создан настроен по всем правилам. Его видно в сети и зайти в него может любой пользователь. Но при попытке что-то скопировать в него или создать новую папку вы видите сообщение.

Вам необходимо разрешение на выполнение этой операции.

Другими словами у пользователей нет прав на запись в эту папку.

Первое что нужно проверить это настройки Samba.

Вот минимальный набор который должен у вас быть.

Дальше смотрим права доступа на саму папку. Для этого лучше воспользоваться файловым менеджером MC. Выбираем пупку, далее нажимаем F9, переходим в меню «Файл» и выбираем «Права доступа».

И видим что «Запись для группы» и «Запись для других» отключены.

Настраиваем эти права и пробуем создать папку.

Как видим все получилось, в каждой созданной папке по умолчанию отключены права на запись для пользователей.

Источник

Samba. Поиск и устранение неисправностей в работе системы

Эта статья по сути будет подборкой «Best practiсe» для системных администраторов Samba. Основой статьи является глава Troubleshooting Techniques из книги Sam’s Teach Yourself Samba in 24 Hours. Мы постараемся рассмотреть наиболее распространенные ошибки при настройке Samba.

Согласитесь, ужасно поменять двигатель в машине, а потом выяснить, что не ехала она из-за отсутствия бензина! Может, это и не лучшая метафора, но многие системные администраторы тратят время зря, не проверив в первую очередь самые очевидные вещи. Посмотрите, как примерно должен выстраиваться процесс поиска и решения проблем с Samba:

Проблемы, представленные на нижних уровнях этой «пирамиды», являются «фундаментом» для более высоких уровней. Не удивительно, что Windows-клиент не может получить доступ к файловому северу на Samba, если сервер отключен от сети. Конечно, не стоит воспринимать этот рисунок буквально, как руководство к действию (скажем, лог-файлы можно посмотреть всегда), но начинать стоит все-таки с проблем нижних уровней. Чем выше мы поднимаемся, тем больше углубляемся в принципы работы Samba.
В поисках решения проблемы с Samba стоит в первую очередь обратиться к следующим ресурсам:
•HOWTO, опубликованные на сайте;
•тематические сайты и форумы, например: http://samba-doc.ru/, http://citforum.ru/operating_systems/linux/samba/;
•разделы документации по Samba для того или иного дистрибутива (например, http://help.ubuntu.ru/wiki/samba, http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-samba.html или http://wiki.russianfedora.ru/index.php?title=Samba);
•http://stackoverflow.com/ — не забывайте про этот сайт, если у вас есть конкретный вопрос или проблема;
•вспомогательные утилиты, входящие в состав Samba, а также различные программы-анализаторы трафика (например, Wireshark).
Мы в первую очередь рассмотрим самостоятельное решение возникающих проблем, но не стоит забывать про возможную помощь сообщества. Это может серьезно сэкономить вам время и силы.

Описание тестовой среды
Для начала — несколько слов о тестовой среде. Условия следующие:
•Samba-сервер называется TROUBLE и имеет IP-адрес 192.168.7.75 и маску 255.255.255.0.
•smbd и nmbd запускаются как демоны.
•Windows-клиент называется win-client.
•Windows-клиент использует адрес 192.168.7.135 с сетевой маской 255.255.255.0.
•И win-client, и TROUBLE находятся в одной подсети, так что широковещательный запрос дойдет с одного хоста на другой.
•И win-client, и TROUBLE являются членами рабочей группы LAB.
•Samba-сервер использует следуюший smb.conf:

УРОВЕНЬ 1

Работоспособность сетевого соединения и файла конфигурации

Основание нашей «пирамиды» составляют три основных проблемы:
•корректно работающее TCP/IP подключение;
•соответствие маски и широковещательных адресов на серверах и клиентах;
•работоспособность файла smb.conf.

TCP/IP
Для проверки TCP/IP в первую очередь используется команда ping. Если описать протокол ICMP очень упрощенно, то хост отправляет запрос на сервер и спрашивает «Ты жив?». Если сервер не отвечает, хост приходит к выводу, что тот не подключен к сети и, следовательно, недоступен.

Также очень важным является правильное функционирование DNS. Если не удастся разрешить имя, появится сообщение вроде этого:

Если такое происходит, первое, что стоит сделать — это повторить команду ping, но используя уже не имя, а адрес:

Если команда выполнится успешно, то стоит обратить внимание на конфигурацию DNS. Наиболее распространенные причины ошибки:
•неверное содержание файла конфигурации DNS /etc/resolv.conf;
•на сервере DNS нет записи, связанной с win-client;
•сервер DNS недоступен в данный момент.
Если же ping по IP-адресу успешно не выполняется, то стоит проверить работоспособность сетевого оборудования на сервере, клиенте и между ними.

Широковещательный адрес на сервере и клиенте
Возможно, ping выполнится и успешно, но при этом сетевая маска (netmask) и широковещательный адрес (broadcast address) будут сконфигурированы неверно.
В NetBIOS крайне важно для правильного разрешения имени и поиска машин в сетевом окружении, чтобы сервер и клиент находились в одной подсети, т.е. использовали одну маску подсети и широковещательный адрес.
В нашем случае сетевая маска должна быть 255.255.255.0, а широковещательный адрес — 192.168.7.255.
Если вы используете Linux, то можно проверить, какие используются широковещательный адрес и маска, при помощи команды ifconfig с именем интерфейса в качестве аргумента:

Если в выводе этой команды вы увидите, что широковещательный адрес или сетевая маска заданы неверно, следует зайти под учетной записью root и установить верные значения, используя команду ifconfig:

В Windows аналогичную информацию можно получить информацию, выполнив команду ipconfig /all.

Проверка корректности файла smb.conf
Так как Samba использует огромное количество параметров из файла smb.conf, разработчики создали утилиту командной строки, которая проверяет синтаксис этого файла. Утилита называется testparm, она очень полезна при поиске ошибок в конфигурационном файле.
Можно использовать утилиту testparm с параметром -s для анализа конкретного конфигурационного файла. Эта опция очень хорошо подходит для проверки файла конфигурации перед его «боевым» использованием.

После анализа заданного конфигурационного файла testparm выводит все значения файла smb.conf, включая значения по умолчанию. Это помогает убедиться, что используются ожидаемые значения параметров конфигурации smbd и nmbd.
Стоит отметить, что значения по умолчанию меняются от версии к версии, так что необходимо использовать версию Samba, соответствующую версии testparm.

УРОВЕНЬ 2

Серверное и клиентское ПО

Второй уровень подразумевает проверку конфигурации клиентского и серверного ПО. Наша цель — убедиться, что и клиент, и сервер корректно отвечают на запросы NetBIOS и CIFS. Пока мы рассматриваем изолированно каждый из хостов. (На третьем уровне мы уже начнем рассматривать их взаимодействие.)

smbd
В первую очередь, smbd должен быть запущен. Проверить это можно, используя команду ps. Аргументы этой команды могут отличаться в зависимости от версии Linux.

Убедившись, что smbd запущен (или, при необходимости, запустив его), используем утилиту smbclient для проверки работоспособности сервера. Параметр -L используется для вывода списка ресурсов сервера. Ключ -N используется для анонимного подключения к серверу, чтобы не создавать лишних проблем с авторизацией. Все эти действия должны выполняться локально на Samba-сервере.

Существуют две распространенные ошибки, которые могут возникнуть при выполнении этой проверки.
Первая ошибка выглядит следующим образом:

Она возникает, если smbd не запущен или не может подключиться к порту 139. Причиной этому могут быть ранее установленные и некорректно удаленные компоненты Samba. Прежде всего следует убедиться, что smbd стартует как демон и не завершается тут же с ошибкой. Особенность в том, что nmbd не выводит ошибки в консольное окно, так что следует посмотреть последние несколько строк log-файла. Позже мы рассмотрим анализ логов более подробно.
Вторая часто встречающаяся ошибка выглядит так:

Можно подумать, что причиной этой ошибки является неверное NetBIOS-имя, но это не так. Эта ошибка не может быть вызвана «битой» установкой nmbd, nmbd в данном случае даже не обязательно должен быть запущен.
Причиной возникновения этой ошибки при локальном подключении чаще всего являются неверно сконфигурированные параметры hosts allow или hosts deny в файле smb.conf. Сервер разрывает создающуюся NetBIOS-сессию.
Если нам удалось увидеть список общих ресурсов, мы можем проверить возможность Samba авторизовать пользователей. В этом тесте аккаунт с именем пользователя user1 и паролем secret подключается к общему ресурсу [public].

Если Samba не сможет авторизовать пользователя, вы увидите сообщение об ошибке:

Причин этой ошибки может быть много. Это может быть неверное имя или пароль, или отсутствующая запись smbpasswd для пользователя, если задан параметр encrypt password = yes, или недействительная учетная запись guest, если разрешен доступ без аутентификации.
Если пользователь корректно авторизовался, но не смог получить доступ к запрошенной службе, smbclient выведет следующее сообщение:

Это может быть вызвано неверно написанным именем службы, настройками доступа к общему ресурсу или неверным выражением path в описании общего ресурса в файле smb.conf.

nmbd
Чтобы проверить, запущен ли nmbd, мы снова используем команду ps.

Если nmbd при этом не запущен, результатом будет ошибка:

Также причиной ошибки может быть тот факт, что loopback-интерфейс не включен в smb.conf при включенном параметре bind interfaces only = yes.
После этого мы проверим, может ли nmbd зарегистрировать имя TROUBLE.

Сообщения об ошибках, например, “name query failed”, скорее всего, вызваны неудачным запросом к имени _Samba_. Другой причиной может быть то, что сервер не может зарегистрировать имя NetBIOS. В этом случае стоит найти сервер, которому принадлежит данное имя, отправив широковещательный запрос.

Например, в данном случае это имя принадлежит сторонней машине, а не нашему Samba-серверу. Очевидно, решением данной проблемы является переименование этой машины или сервера.

NetBIOS-интерфейс Windows

Утилита, использующаяся в Windows для NetBIOS-запросов — nbtstat.exe — имеет еще несколько опций, которых нет в nmblookup. Одна из них (-n) позволяет «спросить» у NetBIOS-интерфейса, какие имена он успешно зарегистрировал:

Если компонент “Client for Microsoft Networks” не был установлен, nbtstat.exe сообщит следующее:

Более тонкая ошибка возникает, когда Windows-клиент сообщает что он зарегистрировал имя рабочей группы, хотя это должно быть уникальное имя рабочей станции.

Часто причиной этого является наличие машины с таким же NetBIOS-именем. Windows-клиенту необходимо уникальное имя, чтобы установить NetBIOS-сессию с сервером. Пока клиент не сможет зарегистрировать имя рабочей станции, он будет неспособен, скажем, просматривать сетевое окружение или подключать сетевые диски.

УРОВЕНЬ 3

Удаленный доступ к общим ресурсам

Итак, мы уже выяснили, что и клиент, и сервер имеют доступ к сети, и локально ПО на них работает. На данном уровне мы переходим к диагностике работоспособности их взаимодействия.

Разрешение имен
Мы вновь будем использовать утилиты nmblookup и nbstat.exe, чтобы выяснить, может ли клиент разрешить имя сервера и наоборот. Тест будет состоять из двух фаз. В первой мы будем использовать широковещательный запрос, чтобы протестировать отклики сервера и клиента. Это делается путем задания широковещательного адреса (-B 192.168.7.255) в утилите nmblookup при запросе, что задействует сетевое взаимодействие между сервером и клиентом.
Сначала мы попробуем разрешить имя сервера:

После этого мы попробуем разрешить имя клиента, используя тот же широковещательный адрес.

Если до сих пор все шло хорошо, этот тест, скорее всего, отработает корректно. Если же результатом будет ошибка, стоит еще раз поверить соответствие широковещательного адреса на всех машинах.
После этого мы выполним NetBIOS Node Status Lookup, проверим статус узла. На этом шаге делается прямое обращение к IP-адресу, в котором запрашивается список уникальных и групповых NeBIOS имен, зарегистрированных этим хостом. Начнем с запроса к Samba-серверу от Windows-клиента.

Можно выполнить те же действия на Samba-сервере, чтобы собрать информацию о клиенте. Опции для запроса через утилиту nmblookup, в целом, такие же как и в nbtstat.exe.

Если какой-то из этих запросов не выполняется, следует еще раз провести проверки сетевого подключения и NetBIOS-интерфейсов, которые мы рассматривали раньше.

Удаленное подключение к общим ресурсам
На самом деле, этот шаг является не столько тестом, сколько целью всего процесса. Если мы зашли в консоль с правильным именем и паролем, то следующая команда подключит диск P: локального клиента к общему ресурсу [public] на сервере TROUBLE.

Чтобы определить, под каким именем подключаться, можно использовать опцию
Существует огромное количество проблем, связанных с аутентификацией. Зачастую они могут быть обнаружены только путем анализа лог-файлов, что будет рассмотрено позже.

УРОВЕНЬ 4

Сетевое окружение

Решение проблем с корректной работой Сетевого окружения — очень сложная тема. Скорее всего, если вы добрались до этого уровня, а сетевое окружение не работает или работает некорректно, вам следует еще раз проверить маску подсети и широковещательный адрес, и снова повторить все тесты нижних уровней: ошибка вероятно кроется там.

УРОВЕНЬ 5

Лог-файлы и анализ трафика

Иногда корень проблемы сложно определить даже с помощью специализированных диагностических утилит. Тогда на помощь приходят логи. Первые четыре уровня нашей «пирамиды» можно использовать для подтверждения правильности начальной установки Samba и решения простых проблем. Начиная с пятого уровня, начинается решение серьезных проблем. Рано или поздно вы столкнетесь с проблемой, которая потребует работы с логами.

Лог-файлы Samba
Ниже приведена таблица, в которой описаны уровни детализации логов.

Чтобы узнать текущий уровень логирования smbd (например, с pid 1234), выполним следующую команду из-под учетной записи root:

Если мы хотим увеличить уровень логирования до 10, чтобы получить всю возможную информацию, используем следующую команду:

Следующий вопрос: «Что же делать с логами?»
Вот пример, в котором логи помогли решению проблемы. Мы пробуем подключиться с Windows-клиента к общему дисковому ресурсу. Однако smbd не принимает пароль для соединения. Когда мы используем smbclient для теста, мы получаем ошибку:

Мы совершенно уверены, что значение smbpasswd верно, и пароль — test. Попробуем подключиться еще раз, добавив

в секцию [global] файла smb.conf, и мы увидим новые строчки в файле log.TROUBLE:

Последняя строка и есть ответ на наш вопрос. Samba не смогла найти учетную запись testuser. А это произошло, так как кто-то закомментировал строку в файле /etc/passwd:

После того, как мы уберем знак комментария (#) перед строкой с учетной записью, попробуем подключиться снова. И на этот раз успешно.

Это всего лишь один пример. Вывод в логах может быть запутанным, но можно использовать grep, чтобы находить следующие ключевые слова:
• fail
• error
• unsuccessful
• corrupt
• unknown

Мониторинг сетевого трафика
Еще один способ найти корень проблемы — это просматривать содержимое пакетов, ходящих по сети между сервером и клиентом. Для этого можно использовать такие программы-анализаторы, как Wireshark. С их помощью можно просмотреть и проанализировать в достаточно читаемом виде содержимое пакетов.

УРОВЕНЬ 6

Внутренние проблемы Samba

Если ничего из вышеприведенного не помогло — возможно, вы столкнулись с каким-либо багом Samba. Список известных можно посмотреть на официальном сайте. Чтобы свести к минимуму вероятность появления подобного рода проблем, используйте актуальную и стабильную версию Samba, а также следите за выходом исправлений: исправляются разведанные баги достаточно быстро.

Источник

Не удается подключиться к общей папке Linux Samba из Windows 10

У меня есть сервер Samba версии 4.1.11, работающий на Ubuntu 14.04. Я не могу подключиться из Windows 10 (но я могу из Windows 7).

Сервер и клиенты не находятся в одной локальной сети.

Windows выдает сообщение об ошибке: сервер подключен к сети, но не отвечает. Однако журналы самбы говорят об обратном.

Я приложил журналы для неудачной попытки подключения из Windows 10 и для успешной попытки из Windows 7 (для сравнения).

Вкратце, в отличие от успешной попытки, неудачная начинается с:

Успешная попытка выбрать протокол SMB2_10 с самого начала, но Windows 10 даже не запрашивает этот протокол.

Я добавил свой комментарий в файл smb.conf (не более 2 ссылок с репутацией linux windows ubuntu samba

В моем случае закомментирование моей строки «smb ports 139» помогло.

Я использую FreeBSD 10 с Samba 4.4.5

Вот копия моего SMB4.conf. Надеюсь, это кому-нибудь поможет.

Это решило мою проблему:

Дальнейшее чтение:

Я обнаружил, что это будет работать и без необходимости редактировать реестр или отключать службы SMB 2/3, я смог подключиться к своему raspi 3, использующему Samba-4.2.10-Debian, вручную введя адрес, а также набрав настройка имени netbios в файле smb.conf распи в адресной строке проводника в Windows 10.

Я бы щелкнул по вкладке сети, но я не смог найти свой общий ресурс samba, хотя общий доступ к сети был включен, а что нет, но после ввода //192.168.0.22 (адрес моего pi) или // SAMBA (имя netbios Я установил в smb.conf) Затем я смог подключиться и поделиться с Samba.

Моя Windows 10 в то время все еще не подключалась к SMB 4.x, но это, похоже, помогло. После этого просто подключите диск, и вам больше не нужно вручную вводить адрес.

Надеюсь, что это поможет кому-то еще в будущем.

В Windows 10 Fall Creators Update и Windows Server версии 1709 (RS3) сетевой протокол Server Message Block версии 1 (SMBv1) больше не устанавливается по умолчанию.

У меня была такая же проблема, моя рабочая станция Windows 10 не могла подключиться к Sambashare после обновления win, ошибки были ошибкой 53, и отсутствующие протоколы, отсутствующие настройки выигрышей в реестре, ничего действительно не помогли в моем случае!

Что сработало для меня:

Теперь в службах прокрутите вниз до рабочей станции, служба запущена? Если нет, у вас может быть та же проблема, что и у меня.

на моих 3-х рабочих ПК теперь все есть в зависимостях + драйвер поддержки браузера + служба интерфейса сетевого магазина + SMB 1.x Miniredirector + SMB 2.0 Miniredirector

Способ, которым я исправил свою проблему, был:

удалить сервис: sc.exe удалить lanmanworkstation

Пересоздать сервис: sc.exe config lanmanworkstation depen = bowser / mrxsmb10 / mrxsmb20 / nsi

а затем запустить службу

И мой ресурс Samba был доступен даже без перезагрузки.

Источник

Windows не может получить доступ к SAMBA серверу, возможные причины

Приведу файл конфига smb.conf, рассматривал далеко не один конфиг, но расшарить папки так и не получилось, подскажите в чем проблема может быть? Где я неправ?

А возможных причин слишком много, начиная от банального отсутствия подключения к сети и настроек фаервола, заканчивая (но не ограничиваясь) солнечной активностью. Телепаты сегодня в отпуске.

В iptables причина, инфа 146%

Хорошо, спасибо. Просто везде где я смотрел про таблицы ни слова, мол, пишите смб.конф и будет вам счастье. Наверное плохо искал.

service iptables stop
chkconfig iptables off

Подозреваю, тебе и так сойдет.

что значит «не получилось»?

Вывод этой команды

Да, отключив iptables заработало, спасибо. Но их отключать нежелательно. И «и так сойдет» не тот подход в данном случае. Подскажите, почему не работает как в этом мануале??

Из официального мана же.

Так нельзя понять почему не работает, нужно видеть как минимум всю цепочку INPUT вместе с политикой.

winbind у меня не стоит, попытался вчитаться что это и с чем едят, но на это нужно гораздо больше времени. Этот демон необходим для корректной работы самба? или на начальных этапах можно без него?

и команда эта не прошла, пишет, что не находит smbd && nmbd && winbind, выполнилась только для samba

Вот смотри, по цепочке

Это значит, что второе правило никогда не сработает.
Нужно, чтобы разрешающее правило было выше, чем то которое запрещает.

я исправил, но доступа нет все равно. Не пускает.

Попробуйте подключение по IP адресу вместо имени хоста.

я так и делал всегда. По имени не подключался, только по ip.

Если вы скинули вывод iptables после попыток подключения, то судя по выводу не было даже попыток этих самых подключений. Все подключения были только на 22 порт ssh.

Ну и как вариант может в цепочке output злое правило которое блокирует.

Не понял по поводу подключения, потому что попытки точно были. Хорошо, спасибо Вам большое за советы. Буду искать.

я думал это локалхост, сеть другая, 10.20.ххх.ххх. Спасибо за мысль. В этом еще не много понимаю, прошу прощения за чайничество, только учусь.

телепаты должны были уже давно исчезнуть с лица планеты как вид, т.к. всю жизнь в отпуске и не работав ни дня умерли с голоду.

Изменил на свою сеть, не работает тоже. В чем проблема теперь вообще непонятно, правила по идее последовательно идут, запрет стоит в конце.

так же нужен ip компьютера с которого происходит подключение.

Источник

Прежде всего, что такое ошибка Samba 255? Что ж, это ошибка, которую мы получаем, когда в Ubuntu (например), мы пытаемся предоставить общий доступ к папке и не можем, потому что он сообщает нам:

«Сетевая папка» вернула ошибку 255: net usershare: не удалось открыть каталог / var / lib / samba / usershares. Ошибка Разрешение отклонено У вас нет разрешения на создание общего доступа. Попросите администратора предоставить вам разрешения на создание общего ресурса.

Это случилось со мной, когда я попытался создать общую папку на одном из компьютеров моих пользователей, чтобы я мог удобно обмениваться файлами с виртуальной машиной Windows XP, работающей на Virtualbox.

В случае Ubuntu решение простое, потому что я все решил, выполнив в терминале:

sudo chmod 777 /var/lib/samba/usershares

Но это может не быть решением для других. Например, в случае с Debian это можно легко решить, добавив нашего пользователя в группу sambashare.

# addgroup usuario sambashare

Депутат только что сказал мне, что еще одно возможное решение — добавить в файл /etc/самба/smb.conf параметр: Только владелец доли пользователя = Ложь

Но допустим, мы хотим чего-то большего. В этом случае мы не хотим, чтобы он запрашивал у нас имя пользователя и пароль для доступа к общей папке. Что ж, для этого мы создаем папку в / media:

# mkdir /media/compartir
# chmod -R 777

А потом добавляем в конец файла /etc/samba/smb.conf:

[документы] комментарий = Путь к общим документам = / media / share public = да для записи = да

И что ж, в некоторых случаях нам нужно перезапустить Samba:

# /etc/init.d/samba restart

Теперь с виртуальной машины мне просто нужно ввести Windows Explorer:

\192.168.X.Xcompartir

И готово ..