Подготовка сервера: минимальная установка и обновление
Задача - получить чистую систему, на которой инструкция отработает без сюрпризов. Руководство проверено на Ubuntu Server 24.04 LTS и Debian 12. Если у вас другая версия, несовпадения возможны только в именах пакетов, логика настройки остаётся неизменной.
Требования к серверу:
- Свежеустановленная ОС с минимальным набором пакетов.
- Статический IP-адрес, настроенный через netplan (Ubuntu) или /etc/network/interfaces (Debian).
- Доступ с правами root или пользователя с sudo.
- Сетевая связность с клиентами, которые будут подключаться к шарам.
Первым делом обновите индексы пакетов и установите обновления безопасности. Это исключает проблемы совместимости, с которыми сталкиваются при использовании устаревших репозиториев.
sudo apt update && sudo apt upgrade -y
Установите минимальный набор утилит для диагностики сети и редактирования конфигураций:
sudo apt install -y net-tools nano curl wget
Проверьте, что IP-адрес назначен корректно и сервер видит локальную сеть:
ip a show
ping -c 4 192.168.1.1
На этом подготовительный этап завершён. Система готова к установке файловых служб.
Установка и базовая настройка Samba для доступа из Windows
Samba - мост между Linux и Windows. Она реализует протокол SMB/CIFS и позволяет клиентам Windows работать с общими папками так же, как с локальными дисками. На минимальном сервере без графического окружения это основной способ обеспечить совместимость с парком Windows-машин.
Установите пакеты Samba и клиентскую утилиту для проверки:
sudo apt install -y samba smbclient
Создайте каталог, который станет общей папкой. Стандартная практика - размещать шары в /srv, отделяя их от домашних каталогов пользователей:
sudo mkdir -p /srv/samba/share
Настройте права файловой системы. Для простоты в этом примере используется группа sambashare, в которую вы добавите пользователей позже:
sudo groupadd sambashare
sudo chgrp -R sambashare /srv/samba/share
sudo chmod -R 2775 /srv/samba/share
Бит setgid (2775) гарантирует, что все новые файлы и папки наследуют группу sambashare, а не основную группу создателя. Это решает проблему «создал файл, а коллега не может его открыть».
Конфигурация smb.conf: детальный разбор параметров
Основной конфигурационный файл - /etc/samba/smb.conf. Перед редактированием сохраните оригинал:
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
Приведите файл к следующему виду. Это минимальная рабочая конфигурация, которую вы доработаете под свои задачи:
[global]
workgroup = WORKGROUP
server string = File Server
security = user
map to guest = never
hosts allow = 192.168.1.0/24 127.0.0.1
hosts deny = 0.0.0.0/0
log file = /var/log/samba/log.%m
max log size = 1000
[Share]
path = /srv/samba/share
browseable = yes
read only = no
valid users = @sambashare
create mask = 0664
directory mask = 2775
force group = sambashare
Разбор ключевых параметров секции [global]:
- security = user - каждый клиент аутентифицируется по логину и паролю. Гостевой доступ отключён директивой map to guest = never. Это базовый уровень безопасности для офисной среды.
- hosts allow/deny - белый список IP-адресов и подсетей. Сервер принимает подключения только от 192.168.1.0/24 и localhost, всё остальное отбрасывается на уровне Samba до попытки аутентификации.
- log file = /var/log/samba/log.%m - отдельный лог-файл для каждого клиента (%m - имя машины). При проблемах с конкретным хостом вы сразу видите его ошибки, не продираясь через общий лог.
Параметры секции общего ресурса [Share]:
- valid users = @sambashare - доступ разрешён только членам группы sambashare. Символ @ обозначает группу.
- create mask = 0664 - новые файлы получают права rw-rw-r--. Владелец и группа могут писать, остальные только читают.
- directory mask = 2775 - новые папки создаются с битом setgid и правами rwxrwxr-x.
- force group = sambashare - любой файл, созданный через Samba, принудительно получает группу sambashare независимо от того, какой пользователь его создал.
Проверьте синтаксис конфигурации перед применением:
sudo testparm
Утилита выводит разобранную конфигурацию и предупреждает о несоответствиях. Если ошибок нет, перезапустите службы:
sudo systemctl restart smbd nmbd
sudo systemctl enable smbd nmbd
Управление пользователями и правами в Samba
Пользователь Samba должен существовать как системный пользователь Linux. Создайте его и добавьте в группу sambashare:
sudo useradd -M -s /sbin/nologin ivanov
sudo usermod -aG sambashare ivanov
Флаг -M означает, что домашний каталог не создаётся, -s /sbin/nologin запрещает интерактивный вход по SSH. Это пользователь только для файлового доступа.
Задайте пароль для Samba. Он хранится отдельно от системного пароля в базе /var/lib/samba/private/passdb.tdb:
sudo smbpasswd -a ivanov
После ввода пароля пользователь готов. Проверьте доступ с этого же сервера:
smbclient -L localhost -U ivanov
Команда выводит список общих ресурсов. Если ресурс Share отображается, серверная часть настроена верно. Теперь с любой Windows-машины в подсети 192.168.1.0/24 можно подключиться, нажав Win+R и введя \\192.168.1.X\Share, где X - IP вашего сервера.
Частая ошибка на этом этапе - «Отказано в доступе» при правильном пароле. Причина в 90% случаев - несоответствие прав файловой системы и параметров Samba. Проверьте, что пользователь состоит в группе sambashare и что каталог /srv/samba/share имеет права 2775.
Если вам нужна более глубокая настройка сетевого доступа к файлам с детальным разбором ACL и интеграцией в доменную среду, обратитесь к руководству по настройке SMB, NFS и FTP в TrueNAS - принципы управления доступом там разобраны на уровне, применимом и к голому Linux.
Настройка NFS-сервера для Linux-клиентов
NFS (Network File System) - нативный протокол для UNIX-подобных систем. В гомогенной Linux-среде он обеспечивает минимальные накладные расходы и максимальную пропускную способность. В отличие от Samba, NFS оперирует системными UID/GID, а не собственной базой пользователей, что упрощает администрирование в средах с централизованной аутентификацией.
Установите серверный пакет:
sudo apt install -y nfs-kernel-server
Создайте каталог для экспорта:
sudo mkdir -p /srv/nfs/share
sudo chown nobody:nogroup /srv/nfs/share
sudo chmod 755 /srv/nfs/share
Назначение владельца nobody:nogroup - стандартная практика для NFS-шар, доступных на запись. При параметре all_squash (разберём ниже) все клиентские запросы маппятся в этого пользователя.
Синтаксис /etc/exports и важные опции безопасности
Файл /etc/exports определяет, какие каталоги экспортируются и кому. Каждая строка - это путь, список разрешённых клиентов и опции. Отредактируйте файл:
sudo nano /etc/exports
Пример минимальной безопасной конфигурации:
/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)
Разбор опций:
- rw - клиенты могут читать и писать. Альтернатива ro - только чтение.
- sync - сервер подтверждает запись только после фактического сброса данных на диск. Это снижает риск потери данных при сбое питания ценой небольшого падения скорости. Для некритичных данных с высокими требованиями к скорости можно использовать async, но с пониманием риска.
- no_subtree_check - отключает проверку принадлежности файла к экспортированному поддереву. Повышает надёжность при работе с переименованиями файлов и снижает нагрузку на сервер.
- root_squash - запросы от root на клиенте маппятся в nobody на сервере. Это критически важная опция безопасности: без неё root на клиенте получает root-доступ ко всем файлам шары. Отключайте её (no_root_squash) только для доверенных административных машин.
Дополнительные опции для точного контроля:
- all_squash - все пользователи клиента маппятся в анонимного пользователя (nobody). Удобно для публичных шар, где не важна идентификация.
- anonuid=1000,anongid=1000 - задают конкретные UID/GID для анонимного пользователя. Позволяет назначить владельца файлов, отличного от nobody.
- secure - требует, чтобы клиентские запросы приходили с привилегированных портов (<1024). Включено по умолчанию, отключается опцией insecure для клиентов, которые не могут использовать привилегированные порты.
Примените экспорт:
sudo exportfs -ra
Флаг -r перечитывает /etc/exports, -a экспортирует все записи. Проверьте, что шара опубликована:
sudo exportfs -v
Монтирование NFS-ресурсов на клиенте Linux
На клиентской машине установите пакет nfs-common:
sudo apt install -y nfs-common
Проверьте доступность экспортированных ресурсов с сервера (192.168.1.X замените на IP вашего сервера):
showmount -e 192.168.1.X
Временное монтирование для теста:
sudo mount -t nfs -o vers=4.2,proto=tcp 192.168.1.X:/srv/nfs/share /mnt/nfs
Опция vers=4.2 форсирует использование NFSv4.2 - самой современной версии с поддержкой расширенных атрибутов и серверного копирования. proto=tcp использует TCP вместо UDP по умолчанию, что критически важно для стабильности в сетях с потерями пакетов.
Для автоматического монтирования при загрузке добавьте строку в /etc/fstab:
192.168.1.X:/srv/nfs/share /mnt/nfs nfs defaults,_netdev,noatime,nofail 0 0
Ключевые опции fstab:
- _netdev - система ждёт поднятия сети перед попыткой монтирования. Без этой опции возможна ошибка загрузки, если сетевой интерфейс ещё не активен.
- nofail - загрузка продолжается, даже если шара недоступна. Предотвращает зависание системы при перезагрузке, когда сервер NFS выключен.
- noatime - не обновлять время последнего доступа к файлам. Снижает количество операций записи и увеличивает производительность.
Проверьте монтирование:
sudo mount -a
df -h | grep nfs
Если команда mount -a отработала без ошибок и df показывает шару, постоянное монтирование настроено корректно.
Детальный разбор параметров экспорта и тюнинга для production-сред - в практическом руководстве по настройке NFS в Ubuntu. Там же рассмотрены частые ошибки конфигурации и методы их исправления.
Обеспечение безопасности файлового сервера
Файловый сервер в локальной сети - цель для атак при компрометации любого хоста в этой сети. Минимальный уровень защиты включает брандмауэр с белыми списками, отключение неиспользуемых протоколов и корректную настройку прав.
Настройка брандмауэра для NFS и Samba
UFW (Uncomplicated Firewall) - надстройка над iptables, которая упрощает управление правилами. Установите и активируйте его:
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
Политика по умолчанию: всё входящее запрещено, всё исходящее разрешено. Теперь откройте порты только для нужных служб и только с доверенных подсетей.
Правила для Samba (порты 137-139 UDP/TCP для NetBIOS и 445 TCP для прямого SMB):
sudo ufw allow from 192.168.1.0/24 to any port 137,138 proto udp
sudo ufw allow from 192.168.1.0/24 to any port 139,445 proto tcp
Правила для NFS требуют фиксации портов вспомогательных служб. По умолчанию statd, mountd и lockd используют случайные порты, что делает невозможным создание точных правил. Зафиксируйте их в файлах конфигурации.
Отредактируйте /etc/default/nfs-common, добавив строки:
STATDOPTS="--port 32765"
Отредактируйте /etc/default/nfs-kernel-server:
RPCMOUNTDOPTS="--port 32767"
Создайте файл /etc/modprobe.d/lockd.conf для фиксации порта lockd:
options lockd nlm_tcpport=32768 nlm_udpport=32768
Перезагрузите службы и откройте порты в UFW:
sudo systemctl restart nfs-common nfs-kernel-server
sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 111 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 32765:32768 proto tcp
Включите брандмауэр и проверьте правила:
sudo ufw enable
sudo ufw status numbered
Важно: включайте UFW только после того, как добавили правило для SSH (если управляете сервером удалённо), иначе вы потеряете доступ:
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
Для доступа к файловому серверу извне локальной сети используйте VPN (WireGuard или OpenVPN). Выставлять порты SMB и NFS в интернет напрямую недопустимо - протокол SMBv1 содержит известные уязвимости, а NFS без Kerberos не обеспечивает шифрование трафика.
Оптимизация производительности и решение типичных проблем
Тюнинг параметров NFS для скорости
Параметры монтирования на клиенте влияют на производительность сильнее, чем настройки сервера. Для сценария с большими файлами (видео, бэкапы, образы виртуальных машин) используйте увеличенные размеры блоков чтения и записи:
sudo mount -t nfs -o vers=4.2,proto=tcp,rsize=1048576,wsize=1048576,noatime 192.168.1.X:/srv/nfs/share /mnt/nfs
rsize и wsize по 1 МБ (1048576 байт) увеличивают пропускную способность на порядок по сравнению со стандартными 64 КБ. Это работает при условии, что сеть и диски справляются с крупными блоками. В сетях с потерями или на медленных дисках уменьшите значения до 262144 (256 КБ).
На серверной стороне в /etc/exchanges можно использовать async для некритичных данных:
/srv/nfs/share 192.168.1.0/24(rw,async,no_subtree_check,root_squash)
async позволяет серверу подтверждать запись до фактического сброса на диск. Это даёт прирост скорости в 2-5 раз на операциях с мелкими файлами. Риск: при внезапном отключении питания данные, находящиеся в буфере, теряются. Для домашнего файлового сервера этот риск часто приемлем, для баз данных - нет.
Готовые конфигурации для разных сценариев - работа с видео, логами и базами данных - собраны в руководстве по настройке NFS для максимальной скорости.
Диагностика и устранение неисправностей
Системный подход к диагностике экономит часы. При любой проблеме с файловым сервером выполняйте проверки в этом порядке:
Шаг 1. Сетевая доступность. Пинг от клиента до сервера и обратно:
ping 192.168.1.X
Если пинг не проходит, проблема на уровне сети или брандмауэра. Проверьте, что UFW не блокирует ICMP (по умолчанию не блокирует) и что клиент и сервер в одной подсети.
Шаг 2. Открытые порты. На сервере проверьте, какие службы слушают порты:
sudo ss -tulpn | grep -E '445|139|2049|111'
Вы должны увидеть smbd на 445, nmbd на 139 и rpcbind на 111. Если какого-то порта нет, служба не запущена или её конфигурация ошибочна.
Шаг 3. Логи. Для Samba основной источник - /var/log/samba/log.%m, где %m - имя клиентской машины. Для NFS - системный журнал:
sudo journalctl -u nfs-server -f
sudo tail -f /var/log/samba/log.192-168-1-100
Шаг 4. Проверка конфигурации. Для Samba - testparm, для NFS - exportfs -v. Обе утилиты показывают, как служба интерпретирует ваши настройки.
Типичные ошибки и их причины:
- «Network name not found» (Samba) - клиент не может разрешить NetBIOS-имя сервера. Используйте IP-адрес вместо имени или настройте WINS-сервер.
- «Permission denied» (NFS) - несоответствие UID/GID на клиенте и сервере. Проверьте id пользователя на обеих машинах командой id username. При несовпадении используйте all_squash с anonuid или настройте централизованную аутентификацию.
- «Access denied by server» (Samba) - пользователь не входит в valid users или его нет в базе Samba. Проверьте членство в группах и вывод sudo pdbedit -L.
- Монтирование NFS зависает на старте системы - отсутствует опция nofail в fstab. Добавьте её, и система продолжит загрузку даже при недоступном NFS-сервере.
Для тех, кто только начинает работать с Linux и хочет системно разобраться в администрировании, включая файловые системы и сетевую подсистему, полезно пройти практическое руководство по Linux от установки до базового администрирования.
Заключение: ваш минимальный файловый сервер готов
Вы развернули файловый сервер на минимальной Linux-системе, настроили Samba для Windows-клиентов и NFS для Linux-машин. Сервер принимает подключения только с доверенной подсети, брандмауэр блокирует всё лишнее, права доступа разграничены на уровне файловой системы и сетевых служб.
Ключевые точки контроля, которые стоит проверить в вашей среде:
- Доступ к Samba-шаре с Windows-машины с корректным логином и паролем.
- Монтирование NFS-шары на Linux-клиенте с записью и чтением тестового файла.
- Правила UFW активны и разрешают подключения только с заданной подсети.
- Логи не содержат повторяющихся ошибок аутентификации или доступа.
Дальнейшие шаги для усиления инфраструктуры: настройка Kerberos-аутентификации для NFSv4, интеграция Samba в домен Active Directory, использование ZFS в качестве файловой системы с автоматическими снапшотами и проверкой целостности данных. Для готовых решений на базе ZFS с веб-интерфейсом управления обратите внимание на руководство по экспорту ZFS dataset через NFS в TrueNAS Scale - принципы настройки NFS там те же, но управление выполняется через графический интерфейс.
Если вам нужна облачная инфраструктура для тестирования подобных конфигураций без развёртывания физического оборудования, Timeweb Cloud предоставляет VDS и выделенные серверы с гибким изменением ресурсов. Для автоматизации рутинных задач администрирования можно использовать AiTunnel - агрегатор API для нейросетей, который помогает генерировать скрипты и конфигурации по текстовому описанию.