Freebsd настройка файлового сервера
Прежде чем начать настройку samba4, у вас должен быть сервер с установленной FreeBSD 10 и настроенной сетью с доступом к сети Интернет.
Подготовка сервера
Заходим в систему под суперпользователем:
Устанавливаем часовой пояс (у меня московское время) и синхронизируем его с сервером времени:
Настраиваем задание в cron для автоматической синхронизации времени каждый день в 00:00:
pkg update && pkg upgrade |
Установка и настройка Samba4
Устанавливаем с использованием пакетов:
Создаем конфигурационный файл и вносим в него следующее:
ee /usr/local/etc/smb4.conf |
mkdir /data && chmod 777 /data |
Создаем учетную запись smbuser в системе FreeBSD:
pw useradd smbuser |
Теперь создаем учетную запись в samba4:
smbpasswd -a smbuser |
Будет запрошен новый пароль для создаваемого пользователя — введите его два раза. Он не будет виден при вводе — это нормально.
Разрешаем запуск демона samba-server:
echo 'samba_server_enable="YES"' >> /etc/rc.conf |
service samba_server start |
Если все настроено правильно, при попытке подключиться к общей папке, система потребует ввести логин и пароль — воспользуйтесь данными созданной учетной записи smbuser. После вы увидите общую папку DATA.
В этой статье я опишу создание файл-сервера с установленной FreeBSD 9.2 (Samba-3.6) с авторизацией в домене Windows 2003.
Когда я впервые поднимал файл-сервер на FreeBSD, наткнулся на множество проблем, решение которых приходилось долго искать по тематическим сайтам и форумам. Поэтому здесь на каждом этапе будут описаны типичные проблемы и их решения. Думаю, многим эта статья поможет разрешить некоторые вопросы.
Итак, начнём с начальных данных:
Отмечу лишь некоторые нюансы:
- 1. Во время инсталяции ОС при настройке сетевого интерфейса я осознанно выбрал DHCP, для чего на самом DHCP-сервере было сделано резервирование IP по MAC. Узнать MAC-адрес интерфейса можно с помощью утилиты dmesg.
- 2. Для правильного резолва я сделал соответствие в DNS-сервере на файл-сервер, а также на самом файл-сервере в файл /etc/hosts добавил следующие строки:
Переходим к установке Samba (вот здесь первой моей ошибкой была установка порта Heimdal, который, как оказалось, вообще ставить не нужно):
Ставил с параметрами:
Все необходимые пакеты установщик подтянет автоматически согласно зависимостям. Во время установки каждого дополнительного пакета система часто будет спрашивать о параметрах установки. Я всё оставлял по дефолту, только лишь отключал поддержку протокола IPv6, т.к. он нам не нужен.
Далее забиваем конфиги, размещённые в конце статьи. Отмечу, что соблюдение регистра букв обязательно. Если используете Putty, то можно копипастить прямо из вложенных мной конфигов.
smb.conf должен лежать в /usr/local/etc/. Остальные конфиги — в /etc.
Если файла по какому-то недоразумению нет, то создаём его простой командой и тут же забиваем:
Проверить конфиг самбы можно утилитой testparm, которая укажет на неверные записи. Опять же, неверные записи не всегда являются таковыми. Тут нужно знать тонкости.
После того, как конфиги забиты запускаем службу samba:
Хорошим ответом будет:
После любого изменения в конфиге самбы нужно обязательно её перезапустить.
Итак, система стоит, ПО скомпилировано, конфиги забиты. Пришло время ввода машину в домен.
Получаем билет:
Вводим самбу, а соответственно и сам сервер в Active Directory:
На этом, собственно, можно и закончить, но чтобы не было проблем с записью в расшаренный каталог, рекомендую назначить админа домена в качестве владельца для расшары с указанием группы юзеров:
Довольно часто возникает вопрос о внедрении своего ДНС сервера, который мог бы не только обслуживать запросы внешних пользователей к приобретенным ДНС именам, но и обслуживать запросы пользователей в локальной сети. Такая задача относительно просто решается средствами ОС FreeBSD.
Настроить DNS сервер Bind под управлением FreeBSD для обслуживания запросов клиентов внутренней сети и обслуживания прямой и обратной зон DNS с функцией их пересылки на вторичный DNS сервер. Тип всех зон на сервере — Master, то есть данный сервер предоставляет авторитетные ответы за все зоны.
1. Внутренний IP адрес DNS сервера — 192.168.0.1/24
2. Внешний IP адрес DNS сервера — 10.10.10.1/24
3. IP адрес вторичного сервера — 10.10.10.2/24
4. Прямая DNS зона — test.dom
5. Обратная DNS зона — 10.10.10.in-addr.arpa
1. В файле /etc/rc.conf прописываем запуск DNS сервера при старте системы
2. Приводим конфигурационный файл /etc/namedb/named.conf к следующему виду:
options directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on < 127.0.0.1; 10.10.10.1; >;
allow-recursion < ACCESS; >;
allow-transfer < 10.10.10.2; >;
transfer-source 10.10.10.1;
version "Bind DNS Server";
>;
logging category lame-servers < null; >;
>;
zone "." type hint;
file "named.root";
>;
zone "localhost" type master;
file "master/localhost";
>;
zone "0.0.127.in-addr.arpa" type master;
file "master/0.0.127.in-addr.arpa";
>;
zone "test.dom" type master;
file "master/test.dom";
allow-query < any; >;
>;
zone "10.10.10.in-addr.arpa" type master;
file "master/10.10.10.in-addr.arpa";
allow-query < any; >;
>;
acl — список доступа с именем ACCESS и описанием в нем сетей, которым разрешено использовать наш DNS сервер.
directory – Рабочая директория Bind
pid-file — Место размещения PID файла
dump-file – Место размещения DUMP файла
statistics-file – Место размещения файла статистики
listen-on – Указываем IP адреса интерфейсов, на которых Bind будет «слушать» запросы
allow-recursion – Указываем списки доступа, кому разрешены рекурсивные запросы к серверу
allow-transfer – Указываем IP адрес вторичного DNS сервера, которому будем пересылать наши зоны
transfer-source – Указываем IP интерфейса, через который будет разрешено проведение трансфера зон
version – Указываем свою версию DNS сервера
logging – Указываем ограничение журналирования
zone "." — Зона, описывающая корневые DNS сервера, необходима для работы. Хранится в файле /etc/namedb/named.root
zone «localhost» — Прямая зона, описывающая локальный сервер, необходима для работы. Хранится в файле /etc/namedb/master/localhost
zone «0.0.127.in-addr.arpa» — Обратная зона, описывающая локальный сервер, необходима для работы. Хранится в файле /etc/namedb/master/0.0.127.in-addr.arpa
zone «test.dom» — Наша прямая зона. Хранится в файле /etc/namedb/master/test.dom Так как на нашем сервере хранится мастер копия зоны, при помощи allow-query, разрешаем всем ее опрос.
zone «10.10.10.in-addr.arpa» — наша обратная зона. Хранится в файле /etc/namedb/master/10.10.10.in-addr.arpa. Так как на нашем сервере хранится мастер копия зоны, при помощи allow-query, разрешаем всем ее опрос.
3. Настраиваем файлы зон
3.1. Зона "." — оставляем по умолчанию
3.2. Зона «localhost». Конфигурационный файл /etc/namedb/master/localhost приводим к следующему виду:
@ IN SOA localhost. root.localhost. (
2009070601 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS localhost.
3.3. Зона «0.0.127.in-addr.arpa». Конфигурационный файл /etc/namedb/master/0.0.127.in-addr.arpa приводим к следующему виду:
@ IN SOA localhost. root.localhost. (
2009070601 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
3.4. Зона «test.dom». Конфигурационный файл /etc/namedb/master/test.dom приводим к следующему виду:
$TTL 3600
@ IN SOA ns1.test.dom. hostmaster.test.dom. (
2009082801 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS ns1.test.dom.
IN NS ns2.test.dom.
ns1 IN A 10.10.10.1
ns2 IN A 10.10.10.2
3.5. Зона «10.10.10.in-addr.arpa». Конфигурационный файл /etc/namedb/master/10.10.10.in-addr.arpa приводим к следующему виду:
$TTL 3600
@ IN SOA ns1.test.dom. hostmaster.test.dom. (
2009082801 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS ns1.test.dom.
IN NS ns2.test.dom.
1 IN PTR ns1.test.dom.
2 IN PTR ns2.test.dom.
Где, например, для зоны test.dom сверху вниз:
— Время, указывающее длительность в секундах, сколько запись должна быть сохранена в кеше.
— @ — имя зоны — заменяющий символ, IN – класс записи INTERNET — значение по умолчанию, SOA – описание глобальных переменных зоны, ns1.test.dom. — имя DNS сервера для этой зоны, hostmaster.test.dom. — почтовый адрес администратора DNS сервера для этой зоны. Вместо знака @, в качестве разделителя используется знак «.»
— Серийный номер изменения записи. Для перечитывания зоны вторичным сервером, при каждом изменении, необходимо последнюю цифру увеличивать на 1
— Время через которое вторичный DNS сервер попытается перечитать зону
— Время через, которое вторичный сервер будет пытаться перечитать зону если ему не удалось связаться с первичным DNS сервером в период указанный в Refresh
— Указывает через какое время данные зоны больше не авторитетны для этого сервера. Используется вторичными серверами.
— Устаревший атрибут, указывающий на время жизни сохранения данных зоны в кеше.
— Указание DNS основного DNS сервера для данной зоны
— Указание вторичного DNS сервера для данной зоны
— Описание узлов в данной зоне
4. Управляем DNS сервером при помощи следующих команд:
Дополнительно:
Наиболее часто используемые типы записей в DNS:
A – запись на IP адрес узла в сети
NS — запись на DNS сервер
CNAME – запись на каноническое имя для узла
PTR – запись указатель на доменное имя, используется в обратных зонах
MX — запись для определения маршрутизации почты
Для проверки работоспособности можно использовать такие средства как dig или nslookup
Пример использования dig:
Команда означает — вывести записи типа ANY в зоне test.dom, используя сервер localhost
; > DiG 9.4.3-P2 > @localhost test.dom ANY
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;test.dom. IN ANY
;; ANSWER SECTION:
test.dom. 3600 IN A 10.10.10.1
test.dom. 3600 IN SOA ns1.test.dom. hostmaster.test.dom. 2009082801 3600 600 2419200 86400
test.dom. 3600 IN NS ns1.test.dom.
test.dom. 3600 IN NS ns2.test.dom.
;; ADDITIONAL SECTION:
ns1.test.dom. 3600 IN A 10.10.10.1
ns2.test.dom. 54886 IN A 10.10.10.2
Пример использования nslookup:
Name: test.dom
Address: 10.10.10.1
>
На мой взгляд использование dig для диагностики более гибко, хотя те кто знает полностью как использовать nslookup, скажут то же самое про него. Также рекомендую замечательное пособие по настройке DNS.
В этой инструкции я хочу пролить свет на то, насколько просто и элегантно возможно устанавливать FreeBSD в серверном окружении — на арендованном железе или в собственном датацентре, вручную или средствами оркестрации вроде Ansible. Шифрование дисков, удобное управление пространством, гипервизор для контейнеров и полных VM, удобный и понятный firewall — это всё и не только это доступно из коробки и занимает мало времени в настройке при правильном подходе.
Установка
Начнём с самого простого сценария. У нас стоит железяка или она где-то там стоит, но мы можем на CD-диске или средствами IPMI скормить .iso (или .img). Или даже еще проще — хостер предлагает образ mfsbsd прямо из интерфейса. В любом случае загружаемся с mfsbsd.
Linux rescue CD
Бывает, что хостер не дает FreeBSD ни в каком виде, но дает Linux Rescue. Загружаемся в линукс, скачиваем mfsbsd образ диска и накатываем на харды:
Настройка сетевого адаптера
Всё хорошо, когда у нас есть непосредственный доступ к монитору или получение сигнала по сети через IPMI/VNC/web. Но что делать если такой возможности нет и возможно только подключение по сети? Для этого нам нужен образ mfsbsd с уже выставленными настройками сети. Давайте соберем наш индивидуальный образ с настройками сетевого адаптера и демона SSH. Для этого нам нужен какой-то FreeBSD хост для сборки образа.
Скачиваем оригинальный .iso
Меняем конфигурационные файлы. Для конфигурации IP достаточно изменить создать conf/rc.conf из conf/rc.conf.sample . Так же следует создать conf/authorized_keys и добавить свой ключ.
Почему mfsbsd?
Это компактная сборка ОС FreeBSD которая загружается прямо в память, а значит мы можем свободно делать что хотим со всеми доступными носителями. Что-то вроде Linux rescue CD. Вся прелесть этой сборки в том, что она позволяет установить FreeBSD буквально в одну команду.
После Linux rescue CD или загрузки с .iso/.img мы попадаем в шелл mfsbsd.
затем устанавливаем нашу систему.
т.к. на хостах до 3 дисков я предпочитаю ставить систему в зеркале на все диски на небольшой раздел. Благодаря ZFS оставшеесе пространство можно конфигурировать как душе угодно, но об этом позже. Вот она одна единственная команда, которой устанавливается вся система.
для установки системы на трёх дисках в зеркале
После установки, файловая система установленной ОС доступна в /mnt/ , поэтому мы производим некоторую конфигурацию перед уходом в ребут:
Копируем уже добавленный в образ mfsbsd ключ в систему
Редактируем конфиг SSH (например меняем порт и разрешаем логин рутом )
редактируем файл "загрузчика" системы
Обратите внимание на производителя вашего сетевого адептера, т.к. от этого зависит имя интерфейса. В некоторых случаях можно сделать так:
ifconfig_DEFAULT="DHCP" в /etc/rc.conf
Ну и можно вообще можно сделать так
и добавлять пользователя и вообще делать все из окружения уже свеже-установленной ОС.
ну а мы поехали дальше
Больше красноглазия
Перед тем как приступить к конфигурации установленной ОС, я хочу отметить еще два способа загрузки в mfsbsd.
Стандартный установщик FreeBSD:
Выбираем Live CD
Диск в памяти на необходим для работы с файлами mfsbsd, более того, mfsbsd использует /tmp/ в процессе инсталяции, поэтому там должно быть достаточно свободного места.
ну а дальше уже тоже самое — ./destroygeom и ./zfsinstall
Установка из предустановленного образа Linux:
Если провайдер сервера дает уже установленный линукс, то мы так же можем "заинсталиться" по-своему, изменив конфигурацию загрузчика GRUB. Для этого на действующей системе нужно добавить grub.cfg следующие строки:
Ну и положить соответственно .iso в /boot/boot-isos/
Сам так никогда не делал, поэтому если найдете ошибку или недочет в конфиге — дайте знать.
Пожалуй как еще можно извернуться что бы установить FreeBSD я не знаю.
Конфигурация системы
Ну вот мы всё установили, загружаемся… Для начала работы нам нужно установить и настроить сеть — в нашем случае главную роль будет выполнять pf, мне нравится это решение за простоту и понятность. Нам нужно настроить файловую систему сервера — мы используем ZFS, потому что это невероятно гибкая и эффективная файловая система. Когда настроена сеть и ФС, мы установим гипервизор. Если нам необходим повышенный уровень безопасности, можно настроить дополнительные утилиты, я опущу их описание в этом туториале. В качестве демонстрации гибкости ZFS я опишу конфигурацию двух серверов, одного с 2-мя дисками и одного с 3-мя дисками. Так же не забываем провести апгрейд системы после установки, порой выходит так, что доступно для установки только что-то древнее.
freebsd-update -r 12.1-RELEASE upgrade
На момент написания этого руководства 12.1 является последней версией
Сервер с двумя дисками
Мы его создали в следующей конфигурации:
Что всё это значит? У нас железка с двумя дисками, эти два диска оба объемом 3ТБ. Мы на сервере собираемся запустить несколько приложений, часть из них условно критичны, часть "для поиграться", поэтому не жалко утратить данные. Для найболее эффективной конфигурации дискового пространства. Что мы получаем в результате недолгих манипуляций?
Пул appdata (зеркало из разделов /dev/ada0p4.eli и /dev/ada1p4.eli) для данных приложения критической важности, пул miscdata ("страйп", т.е. просто последовательно расположены данные на /dev/ada0p5.eli и /dev/ada1p5.eli) для всякой ерунды. Так же есть системный пул и своп, это так же зеркала из разделов обоих дисков.
Итого мы имеем для наших приложений 1ТБ зеркалированного пространства и 3.2ТБ для экспериментов.
Как всё это настроить? Несложно. После начальной установки наш диск выглядит как-то так:
Добавляем разделы на диски, сначала тот что будем зеркалировать
а затем всё остальное
теперь у нас есть разделы /dev/ada0p4, /dev/ada0p5, /dev/ada1p4 и /dev/ada0p5. Т.к. мы не имеем физического доступа к серверу у хостера в ДЦ, целесообразно разделы с нашими данными зашифровать.
вводим пароль шифрования, затем расшифровываем разделы:
теперь у нас есть разделы /dev/ada0p4.eli, /dev/ada0p5.eli, /dev/ada1p4.eli и /dev/ada0p5.eli, можем построить пулы из этих разделов
Можно это заскриптить:
и для данных без зеркалирования
Ну вот и готов к бою наш сервер. Мы имеем пулы, которые в дальнейшем можем расширать посредством добавления доп. дисков. А еще есть снапшоты, как их применять опишу чуть ниже.
Сервер с тремя дисками
Тут немного другой конфиг. У нас есть железка с тремя SSD дисками по 450ГБ. Этот сервер будет использоваться в основном для полной виртуализации, поэтому нам нужно как можно больше пространства, но при это возможно продолжать работать после утраты одного из дисков. После начальной установки наши диски выглядят так:
Создаем разделы по 420 ГБ (до конца диска не создаем, т.к. при замене диска, его фактический размер может немного отличаться)
Что за Metadata backup?
Это файл, при помощи которого можно сбросить пароль шифрования на тот, что мы ввели. Ну это на случай если потом поменял и забыл. В любом случае стоит иметь ввиду этот нюанс.
Аттачим диски и создаем пул
и на выходе мы получаем пул с 820 ГБ дискового пространства
Собирать ZFS пулы и разных дисков разных конфигураций возможно как угодно. Это своего рода конструктор хранилища, которое можно вечно увеличивать. ZFS создаёт слой абстракции над устройствами, который позволяет достигать крайне удивительных конфигураций.
Установка и настройка гипервизора
FreeBSD предлагает из коробки два решения для "гостевых ОС" — jails и bhyve. Есть cbsd, это враппер для FreeBSD Jails, bhyve и XEN. В данном руководстве я последний затрагивать не буду, т.к. никогда им сам не пользовался.
Клетки это клоны системы FreeBSD. Очень удобный инструмент для изоляции процессов. Хост система может хостить клетки любой версии ниже своей. Клетки можно переносить между хостами, снапшотить и откатывать хоть на лету. Стоит использовать клектки когда это возможно, таким образом оптимально использовать ресурс системы, не тратя его на полную виртуализацию.
bhyve в свою очередь это полноценный гипервизор, которым можно поднимать всякие Ubuntu и докеры.
Стоит отметить, что на момент написания руководства cbsd тянет всего 11 зависимостей размеров 35 МБ.
создаем отдельный раздел на пуле для клеток
Запускаем cbsd демона. Запускаем onestart, т.к. мы не добавили cbsd в автозапуск при загрузке системы, т.к. у нас зашифрованы разделы с данными гостевых ОС.
При загрузке сервера нужно к нему подключится по SSH (именно поэтому системный раздел не зашифрован, что бы загрузка системы происходила успешно без всяких там VNC/IPMI вводов паролей) и расшфифровать наши дисковые разделы скриптом ./root/attach_disks.sh .
При инициализации cbsd мы указали что 192.168.0.0/24 будет подсетью для наших клеток. Ту же подсеть я планирую использовать и для полной виртуализации. Закрутим пару клеток на хосте, но перед этим настроим огненную стену, что бы NAT для клеток работал через хоста.
создаем файл правил для фаервола
Ну а теперь создаем клетки
Выбираем скачивание с репозитория базы для клеток
затем клетки запускаем
и внутри уже делаем что хотим
Вот так выглядит типичный зоопарк клеток:
В webapp клетке у нас слушает nginx , а доступен он извне как раз засчет записи в /etc/pf.conf
Полная виртуализация
Для полной виртуализации нужно подключить доп. модули ядра. Возьмем наш сервер с тремя дисками
В /etc/rc.conf включим режим роутера и настроим ИП хоста в подсети клеток и виртуалок
Теперь настроим фаервол, похожим образом как с хостом только для клеток.
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
IP_JAIL="192.168.0.2"
PORT_JAIL="< 80, 443 >"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL
Такс, теперь создаем виртуалку
Затем нам надо подключится по VNC к порту хоста 5900, я для этого использую проброс портов SSH
ssh hyperhost -L 5900:localhost:5900
Устанавливаем систему. IP адрес можно выбрать что-то вроде 192.168.0.100.
Добавим в /etc/pf.conf форвардинг SSH
И вот мы можем подключится к нашему дебиану. Но перед этим, сделаем одну вещь.
Виртулка дебиана сейчас занимает неполный гигабайт. Сделали снапшот свежей системы.
Чайная пауза — Ansible
Мы ведь хотим управлять нашим виртуальным хозяйством будь то 3, будь то 1300 инстансов. Для универсального управления нашими инстансами мы напишем простые сценарии.
Вот так и получился свой маленький, но удаленький TerraForm
Ну а теперь всё можно красиво управлять
Внутри нашего дебиана теперь можем запустит наше приложение или любой произвольный сервис в докере, например почтовый комплекс iRedMail.
Ну а зачем нам нужен был снапшот? А что бы мы могли опять что-нибудь развернуть на чистом Debian.
Я опустил другие фишки гипервизора как учет потребления ресурса и клонирование инстансов, может я выделю время под написание еще одной части руководства.
Первым делом – обновляем порты:
Далее, находим актуальную версию Samba:
Приступаем к установке:
Из опций можно добавить With Syslogd:
LDAP – поддержка LDAP.
ADS -поддержка Active Directory. Отключаем.
CUPS – поддержка сервера печати CUPS.
WINBIND – обьединение пользвателей Windows/Unix. Почитать можно тут>>>.
ACL_SUPPORT – поддержка Access Control List.
AIO_SUPPORT – поддержка возможности асинхронного ввода-вывода.
FAM_SUPPORT – API для мониторинга за состоянием файла или группы файлов/директорий.
SYSLOG – поддержка логирования syslog. Включаем.
QUOTAS – поддержка квотирования. Поскольку диски не резиновые, а пользователи жадные до дискового пространства – включаем.
UTMP – включаем поддержку уникального идентификатора для каждого вновь подключенного пользователя. Поскольку понижает производительность – выключаем.
PAM_SMBPASS – поддержка синхронизации системных пользователей и пользователей samba. В нашем случае неактуально, поэтому оставляем выключеным.
DNSUPDATE – поддержка динамического обновления DNS. Поскольку данный вариант работает с поддержкой Active Directory, что нам не нужно, то оставляем отключенным.
EXP_MODULES – поддержка експериментальных модулей. А нам нужна стабильность в работе.
POPT – поддержка системной библиотеки анализа коммандной строки.
PCH – предкомпиляционная оптимизация заголовков.
MAX_DEBUG – включение режима максимальной отладки.
SMBTORTURE – утилита для стресс-тестирования серверов.
Добавляем автозапуск при старте сервера. В файл /etc/rc.conf добавляем:
Теперь – добавим пользователя:
Для каждого созданного пользователя – выполняем следующую команду, что бы SAMBA добавил его в собственную базу (в случае, если не используется MySQL или LDAP)
Проверить, какие пользователи есть в SAMBA можно командой:
Теперь – пробуем запустить сервер:
В целом, мой файл конфигурации получился таким:
[public]
comment = Public Stuff
path = /home/samba
public = yes
writable = yes
guest ok = yes
write list = @wheel
[homes]
comment = Home Directories
browseable = no
read only = no
Краткое пояснение к опциям:
Читайте также:
- Digma freedrive 108 обзор видеорегистратора
- Яндекс дзен тормозит компьютер
- Mackie dl1608 подключение к компьютеру
- Тонер попал в глаза
- Что такое номер файла при поиске багажа