У меня серьёзные проблемы со стабильностью моего нового UNAS Pro 4 NAS, которые сводят меня с ума и, по сути, делают устройство непригодным к использованию. Я изучил множество постов в соцсетях, перепробовал кучу разных конфигураций SMB и NFS — всё безрезультатно. Я подключал несколько ИИ-инструментов для отладки, но все они пришли к одному и тому же выводу, и я дошёл до того момента, что мне некомфортно применять предложенные изменения без подтверждения от @UI-Team или других пользователей, которые сталкивались с этой же проблемой и решили её. У меня открыт тикет в поддержку, но хотелось бы узнать, сталкиваются ли другие участники сообщества с той же проблемой, чтобы, надеюсь, однажды мы смогли поделиться решением.
Проблема
У меня часто происходят разрывы соединений NFS и SMB на моём UNAS Pro 4, из-за чего Plex (и другие клиенты) теряют доступ к медиафайлам. Проблема возникает как с протоколом NFS, так и с SMB, что заставило меня копать глубже в поисках первопричины, а не винить конкретный протокол.
Симптомы:
Plex останавливает воспроизведение медиа на середине потока или не может загрузить библиотеки
Клиенты NFS сообщают об устаревших файловых дескрипторах (stale file handles)
Смонтированные SMB-шары перестают отвечать
Переподключение (перемонтирование) временно решает проблему, но она повторяется в течение нескольких часов
Моя конфигурация:
UNAS Pro 4 под управлением UniFi Drive (ядро 5.10.216-alpine-unas, aarch64)
2x WD Ultrastar 16 ТБ (WUH721816ALE6L4) в UNAS
Клиенты: хост Proxmox (LXC-контейнер Plex через SMB bind mount), сервер Ubuntu (Docker-контейнеры через NFS)
Сеть: коммутация UniFi, подключение 1GbE (также тестировал с SFP+ DAC — та же проблема)
Анализ первопричины
1. Обрывы сокетов NFS в dmesg
rpc-srv/tcp: nfsd: sent 92928 when sending 131200 bytes - shutting down socket
rpc-srv/tcp: nfsd: got error -11 when sending 120 bytes - shutting down socket
rpc-srv/tcp: nfsd: sent 128892 when sending 131200 bytes - shutting down socket
Эти ошибки указывают на то, что демон NFS пытается отправить данные, но буфер отправки TCP переполнен. Вместо повторной попытки ядро закрывает сокет, отключая клиента. Ошибка -11 — это EAGAIN (буфер временно заполнен).
2. Значительные потери пакетов на сетевом интерфейсе
После свежей перезагрузки, примерно через 25 минут:
enp0s0: 7347675 28335 0 1705 0 0 0 4821 ...
Это 1705 потерянных RX-пакетов за меньше чем полчаса. Это было стабильно как на порту 1GbE (enp0s0), так и на порту SFP+ (enp0s1), что исключает проблему с кабелем или портом.
3. Исследование параметров ядра
Я проверил стандартные настройки ядра на UNAS и обнаружил три параметра, которые значительно занижены для NAS-нагрузок:
Кольцевой буфер (очередь приёма/передачи сетевого адаптера):
# ethtool -g enp0s0
Pre-set maximums:
RX: 8192
TX: 8192
Current hardware settings:
RX: 1024 <-- Только 12.5% от максимума
TX: 1024
Сетевой адаптер поддерживает 8192 записей, но по умолчанию стоит 1024. Это означает, что буфер сетевой карты заполняется до того, как ядро успевает обработать пакеты, что приводит к потерям. Это напрямую объясняет количество потерянных пакетов.
Максимальные размеры TCP-буферов сокетов:
net.core.wmem_max = 262144 (256 КБ — слишком мало для размеров блоков NFS)
net.core.rmem_max = 262144 (256 КБ)
net.ipv4.tcp_wmem = 65536 131072 16777216
net.ipv4.tcp_rmem = 65536 131072 134217728
Значение wmem_max в 256 КБ — это жёсткий потолок для TCP-буферов отправки. NFS пытается отправлять блоки размером 131200 байт и упирается в этот потолок под нагрузкой, что и вызывает ошибки "shutting down socket".
Потоки демона NFS:
# cat /proc/fs/nfsd/threads
8
Всего 8 потоков NFS для обслуживания нескольких одновременных потоковых клиентов. Когда все потоки заняты, новые запросы ставятся в очередь, усугубляя давление на буферы.
Предлагаемое исправление
Это стандартные параметры настройки ядра Linux, а не хаки. Указанные ниже значения широко рекомендуются для нагрузок NAS/файловых серверов:
Увеличить кольцевые буферы:
ethtool -G enp0s0 rx 4096 tx 4096
Увеличить максимальные размеры TCP-буферов:
sysctl -w net.core.wmem_max=16777216
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_default=1048576
sysctl -w net.core.rmem_default=1048576
Увеличить количество потоков NFS:
echo 16 > /proc/fs/nfsd/threads
Вопросы сообществу
Сталкивался ли кто-нибудь ещё с подобными разрывами соединений NFS/SMB на UNAS Pro или UNAS Pro 4? Мне было бы интересно узнать, видят ли другие такие же потери пакетов и стандартные размеры кольцевых буферов.
Сохраняются ли эти параметры ядра после обновлений прошивки? Я подозреваю, что обновление UniFi Drive сбросит /etc/sysctl.conf и настройки кольцевых буферов. Кто-нибудь нашёл постоянный способ применения кастомных настроек ядра на UNAS?
Может ли Ubiquiti рассмотреть возможность установки более подходящих значений по умолчанию для этих параметров? UNAS создан специально как NAS — ядро должно быть настроено для постоянной работы с файлами, а не для стандартных настроек. Увеличение кольцевого буфера с 1024 до 4096 и повышение wmem_max хотя бы до 4 МБ, скорее всего, устранило бы эти проблемы для большинства пользователей.
Есть ли у кого-то UNAS Pro (7-отсеков) и желание проверить свои значения? Мне хотелось бы знать, отличаются ли настройки по умолчанию между моделями Pro и Pro 4. Проверить можно так:
ethtool -g enp0s1
cat /proc/sys/net/core/wmem_max
cat /proc/fs/nfsd/threads
Детали окружения
Модель: UNAS Pro 4
Прошивка: UniFi Drive (актуальная на март 2026)
Ядро: 5.10.216-alpine-unas (aarch64)
Диски: 2x WD Ultrastar HC550 16 ТБ (7200 RPM), SMART здоров, 432 часа работы
Сеть: Тестировалось как на 1GbE (enp0s0), так и на 10GbE SFP+ (enp0s1) на UDM Pro SE и на USW Pro Max 16 POE — поведение одинаковое
Память: 8 ГБ, около 5 ГБ доступно в buff/cache, минимальное использование swap
Средняя загрузка: 1.08, 1.19, 1.25
SMART: Нет ошибок, нет переназначенных секторов, нет отложенных секторов
Проблема
У меня часто происходят разрывы соединений NFS и SMB на моём UNAS Pro 4, из-за чего Plex (и другие клиенты) теряют доступ к медиафайлам. Проблема возникает как с протоколом NFS, так и с SMB, что заставило меня копать глубже в поисках первопричины, а не винить конкретный протокол.
Симптомы:
Plex останавливает воспроизведение медиа на середине потока или не может загрузить библиотеки
Клиенты NFS сообщают об устаревших файловых дескрипторах (stale file handles)
Смонтированные SMB-шары перестают отвечать
Переподключение (перемонтирование) временно решает проблему, но она повторяется в течение нескольких часов
Моя конфигурация:
UNAS Pro 4 под управлением UniFi Drive (ядро 5.10.216-alpine-unas, aarch64)
2x WD Ultrastar 16 ТБ (WUH721816ALE6L4) в UNAS
Клиенты: хост Proxmox (LXC-контейнер Plex через SMB bind mount), сервер Ubuntu (Docker-контейнеры через NFS)
Сеть: коммутация UniFi, подключение 1GbE (также тестировал с SFP+ DAC — та же проблема)
Анализ первопричины
1. Обрывы сокетов NFS в dmesg
rpc-srv/tcp: nfsd: sent 92928 when sending 131200 bytes - shutting down socket
rpc-srv/tcp: nfsd: got error -11 when sending 120 bytes - shutting down socket
rpc-srv/tcp: nfsd: sent 128892 when sending 131200 bytes - shutting down socket
Эти ошибки указывают на то, что демон NFS пытается отправить данные, но буфер отправки TCP переполнен. Вместо повторной попытки ядро закрывает сокет, отключая клиента. Ошибка -11 — это EAGAIN (буфер временно заполнен).
2. Значительные потери пакетов на сетевом интерфейсе
После свежей перезагрузки, примерно через 25 минут:
enp0s0: 7347675 28335 0 1705 0 0 0 4821 ...
Это 1705 потерянных RX-пакетов за меньше чем полчаса. Это было стабильно как на порту 1GbE (enp0s0), так и на порту SFP+ (enp0s1), что исключает проблему с кабелем или портом.
3. Исследование параметров ядра
Я проверил стандартные настройки ядра на UNAS и обнаружил три параметра, которые значительно занижены для NAS-нагрузок:
Кольцевой буфер (очередь приёма/передачи сетевого адаптера):
# ethtool -g enp0s0
Pre-set maximums:
RX: 8192
TX: 8192
Current hardware settings:
RX: 1024 <-- Только 12.5% от максимума
TX: 1024
Сетевой адаптер поддерживает 8192 записей, но по умолчанию стоит 1024. Это означает, что буфер сетевой карты заполняется до того, как ядро успевает обработать пакеты, что приводит к потерям. Это напрямую объясняет количество потерянных пакетов.
Максимальные размеры TCP-буферов сокетов:
net.core.wmem_max = 262144 (256 КБ — слишком мало для размеров блоков NFS)
net.core.rmem_max = 262144 (256 КБ)
net.ipv4.tcp_wmem = 65536 131072 16777216
net.ipv4.tcp_rmem = 65536 131072 134217728
Значение wmem_max в 256 КБ — это жёсткий потолок для TCP-буферов отправки. NFS пытается отправлять блоки размером 131200 байт и упирается в этот потолок под нагрузкой, что и вызывает ошибки "shutting down socket".
Потоки демона NFS:
# cat /proc/fs/nfsd/threads
8
Всего 8 потоков NFS для обслуживания нескольких одновременных потоковых клиентов. Когда все потоки заняты, новые запросы ставятся в очередь, усугубляя давление на буферы.
Предлагаемое исправление
Это стандартные параметры настройки ядра Linux, а не хаки. Указанные ниже значения широко рекомендуются для нагрузок NAS/файловых серверов:
Увеличить кольцевые буферы:
ethtool -G enp0s0 rx 4096 tx 4096
Увеличить максимальные размеры TCP-буферов:
sysctl -w net.core.wmem_max=16777216
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_default=1048576
sysctl -w net.core.rmem_default=1048576
Увеличить количество потоков NFS:
echo 16 > /proc/fs/nfsd/threads
Вопросы сообществу
Сталкивался ли кто-нибудь ещё с подобными разрывами соединений NFS/SMB на UNAS Pro или UNAS Pro 4? Мне было бы интересно узнать, видят ли другие такие же потери пакетов и стандартные размеры кольцевых буферов.
Сохраняются ли эти параметры ядра после обновлений прошивки? Я подозреваю, что обновление UniFi Drive сбросит /etc/sysctl.conf и настройки кольцевых буферов. Кто-нибудь нашёл постоянный способ применения кастомных настроек ядра на UNAS?
Может ли Ubiquiti рассмотреть возможность установки более подходящих значений по умолчанию для этих параметров? UNAS создан специально как NAS — ядро должно быть настроено для постоянной работы с файлами, а не для стандартных настроек. Увеличение кольцевого буфера с 1024 до 4096 и повышение wmem_max хотя бы до 4 МБ, скорее всего, устранило бы эти проблемы для большинства пользователей.
Есть ли у кого-то UNAS Pro (7-отсеков) и желание проверить свои значения? Мне хотелось бы знать, отличаются ли настройки по умолчанию между моделями Pro и Pro 4. Проверить можно так:
ethtool -g enp0s1
cat /proc/sys/net/core/wmem_max
cat /proc/fs/nfsd/threads
Детали окружения
Модель: UNAS Pro 4
Прошивка: UniFi Drive (актуальная на март 2026)
Ядро: 5.10.216-alpine-unas (aarch64)
Диски: 2x WD Ultrastar HC550 16 ТБ (7200 RPM), SMART здоров, 432 часа работы
Сеть: Тестировалось как на 1GbE (enp0s0), так и на 10GbE SFP+ (enp0s1) на UDM Pro SE и на USW Pro Max 16 POE — поведение одинаковое
Память: 8 ГБ, около 5 ГБ доступно в buff/cache, минимальное использование swap
Средняя загрузка: 1.08, 1.19, 1.25
SMART: Нет ошибок, нет переназначенных секторов, нет отложенных секторов
