Skip to main content
Vraag

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

  • July 9, 2026
  • 15 reacties
  • 23 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!

15 reacties

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.

 


Sanne van KPN
Moderator
Forum|alt.badge.img+20

Hi ​@Y.Peters en welkom bij de KPN Community! 

Ik ben hier zelf niet erg thuis in helaas. 🫠 Gelukkig heb je wel tips gekregen van rvk01. Is het daarmee gelukt om dit op te lossen? Of nauwkeuriger te achterhalen waar het hem in zit?
Ik ben benieuwd!


  • Auteur
  • Deelnemer
  • July 11, 2026

​@rvk01 ​@Sanne van KPN,

Helaas heeft dit het probleem niet opgelost


rvk01
Slimmerik
  • July 11, 2026

Helaas heeft dit het probleem niet opgelost

Wat heb je dan gedaan?? Ik vroeg:

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

Dat is niet zozeer iets om het probleem op te lossen maar meer om te kijken of er daar een probleem kan zitten.


  • Auteur
  • Deelnemer
  • July 11, 2026

​@rvk01, 

RAM usage is rond 1.5GB van de 8

op de UNAS en op ubuntu

Dit gecontroleerd via htop


rvk01
Slimmerik
  • July 11, 2026

Die 1,5GB is bij het probleem?

En zie je het geheugen voor smbd terugvallen na een tijdje op moment dat de share zich herstelt?

 


  • Auteur
  • Deelnemer
  • July 11, 2026

​@rvk01,

de 1.5GB is de baseline. Bij zware downloads loopt ram op on max 3Gb op de UNAS. op ubuntu is de 1.5GB tijdens zware downloads. Via nzbget. 


rvk01
Slimmerik
  • July 11, 2026

En nzbget stuurt zijn download naar de UNAS. Die kan het best zijn dat die met 3GB voor smbd volgelopen is (bug in implementatie samba).

Ik neem aan dat als je het lokaal op Ubuntu opslaat alles wel goed gaat?

 


  • Auteur
  • Deelnemer
  • July 11, 2026

​@rvk01, local downloading gaat goed, alleen via SMB gaat het niet goed. dit probleem is vanaf maandag zo. ik heb de UNAS pro sinds feb dit jaar. ben nu aan het testen als dit probleem er ook bij een andere NAS is.


rvk01
Slimmerik
  • July 11, 2026

Kun je ook eens kijken als je het bestand lokaal op Ubuntu download en daarna handmatig naar de UNAS kopieert of het probleem dan ook optreedt.

 


  • Auteur
  • Deelnemer
  • July 11, 2026

​@rvk01, dit heb ik ook al getest gaat dan goed


rvk01
Slimmerik
  • July 11, 2026

Waar staat je InterDir in NZBGet op (temp dir)? Verwijst die naar een lokale map of ook al direct naar de UNAS.

 


  • Auteur
  • Deelnemer
  • July 11, 2026

​@rvk01 InterDir verwijst naar mijn UNAS


rvk01
Slimmerik
  • July 11, 2026

​@rvk01 InterDir verwijst naar mijn UNAS

Beste is om dat naar lokaal te doen zodat NZBGet pas na het downloaden over het netwerk gaat kopiëren.

 

 


  • Auteur
  • Deelnemer
  • July 11, 2026

​@rvk01, ik dit op deze manier meerdere jaren via truenas ging dit altijd goed. naar UNAS tot maandag ging het goed, op mijn UNAS 2 gaat het tot nu ook goed. Denk dat dit daarom niet de oplossing is voor het probleem