Linux CIFS/SMB loopt vast bij langdurige schrijfacties naar

[the_killer_man]

Hallo allemaal,


Ik loop tegen een vreemd probleem aan waar ik inmiddels al een aantal dagen mee bezig ben. Ik ben benieuwd of iemand dit herkent of misschien een richting weet om verder te zoeken.

Omgeving

• Ubuntu Server 22.04.5 LTS
• Docker 29.1.3
• NZBGet, Sonarr, Radarr, Prowlarr
• Ubiquiti UNAS Pro
• SMB-share gemount via CIFS (SMB 3.1.1)

De UNAS is gemount op:

code:

//10.0.20.20/Videos -> /NAS

De Docker-containers gebruiken vervolgens /NAS als opslag.

Probleem

Bij langdurige schrijfacties (bijvoorbeeld een download van 30-40 GB via NZBGet) gebeurt na enige tijd het volgende:

• NZBGet hangt volledig.
• docker stop en docker kill werken niet meer.
• ls /NAS/downloads blijft hangen.
• Het proces komt in Linux in D-state (uninterruptible sleep).

ps laat zien:

code:

D smb2_r /app/nzbget/nzbget

In dmesg zie ik onder andere:

code:

CIFS: VFS: \\10.0.20.20 has not responded in 180 seconds. Reconnecting...
STATUS_FILE_CLOSED
CIFS: VFS: Send error in read = -9
CIFS: VFS: Send error in write = -9

Opvallend

Tijdens het probleem:

• Ping naar de NAS blijft werken.
• TCP-poort 445 blijft open.
• De webinterface van de UNAS blijft bereikbaar.
• De SMB-share herstelt zichzelf na enige tijd en daarna gaat NZBGet automatisch verder.

Het lijkt dus niet alsof de NAS volledig crasht.

Wat ik al getest heb

• Docker opnieuw geïnstalleerd.
• Portainer opnieuw geïnstalleerd.
• Server en UNAS in hetzelfde VLAN geplaatst.
• Verschillende netwerkconfiguraties getest.
• De Linux-host hangt aantoonbaar in smb2_r.

Extra informatie

Wat ik opvallend vind is dat ik de UNAS al sinds februari gebruik. De eerste maanden werkte alles zonder problemen. Dit gedrag is pas recent ontstaan.

Daarnaast gebruikte ik hiervoor TrueNAS met vrijwel dezelfde Ubuntu-server, Docker-stack en SMB-configuratie. Toen heb ik dit probleem nooit gehad.

Mijn vraag

Heeft iemand dit eerder gezien?

Ik twijfel momenteel tussen:

• een Linux CIFS/kernel-probleem;
• een compatibiliteitsprobleem tussen Linux en de UNAS;
• een firmwareprobleem van de UNAS;
• of iets in de netwerkstack.

Alle ideeën of vergelijkbare ervaringen zijn welkom.

Alvast bedankt!

[GarBaGe]

Klinkt als wat subtiele mogelijke protocol gerelateerde zaken.
Op je Ubuntu server, welke mount opties gebruik je op dit moment voor je SMB?
En welke andere heb je al uitgeprobeerd?

Heb je ook nog logs aan de UNAS kant?

Wellicht is een andere optie om eventueel een ander protocol te kiezen, gezien je een Linux server gebruikt, zoals bijvoorbeeld NFS?

[the_killer_man]

GarBaGe schreef op donderdag 9 juli 2026 @ 14:20:
Klinkt als wat subtiele mogelijke protocol gerelateerde zaken.
Op je Ubuntu server, welke mount opties gebruik je op dit moment voor je SMB?
En welke andere heb je al uitgeprobeerd?

Heb je ook nog logs aan de UNAS kant?

Wellicht is een andere optie om eventueel een ander protocol te kiezen, gezien je een Linux server gebruikt, zoals bijvoorbeeld NFS?

ik mount hem via fstab

//10.0.20.20/Videos/ /NAS cifs username=username,password=password,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,iocharset=utf8,noserverino 0 0

[Kasper1985]

Wat is de netwerk omgeving?

Dat het bij alleen bij grote downloads gebeurt wijst wel op iets netwerk gerelateerd. Je kan eens proberen om lokaal te downloaden en dan sonarr een copy of move te laten doen naar de NAS.

En inderdaad NFS werkt veel stabieler op linux. Nergens voor nodig om SMB te gebruiken.

[FredvZ]

Je bent volgens een snelle Google actie niet enige met problemen met grote bestanden met cifs.
Ik zou ook eerst NFS proberen.

[c-nan]

Wat is de health van je disk(en)? reallocated/pending sectors?