Skip to main content
Vraag

Linux CIFS/SMB loopt vast bij langdurige schrijfacties naar UNAS Pro

  • July 9, 2026
  • 1 reactie
  • 7 keer bekeken

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:

 
//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:

 
D smb2_r /app/nzbget/nzbget

In dmesg zie ik onder andere:

 
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!

1 reactie

rvk01
Slimmerik
  • July 9, 2026

Een tijdje geleden had ik wel problemen om een bestand van 100+GB te kopiëren naar een Samba server (Linux Raspberry PI) en WD MyCloud NAS. Daar liep het geheugen onder mijn Windows copier vol. Een andere copier gebruiken (zoals Terracopy of Robocopy) haalde niets uit. Schijnbaar was dat toch iets in de samba implementatie op Windows want ik ben nu bezig een 130GB te kopiëren naar een QNAP NAS en dat loopt nu nog steeds goed (geheugen loopt niet op zoals een tijd geleden).

Ik zag daar echter wel hetzelfde dat dat geheugen zich na een tijdje weer hersteld.

Heb je gekeken hoeveel geheugen de samba implementatie op de Ububtu server en de Ubiquiti NAS in beslag neemt tijdens dat kopiëren.

Â