Proxmox verliert Verbindung zu SMB-Share auf Unraid

[urs]

Hallo zusammen,

Wie der Titel schon sagt verlieren 2 Proxmox VE-Maschinen immer wieder die Verbindung zu einem Unraid-Server. Es wurden 2 SMB-Shares darauf angelegt und unter Proxmox eingebunden was grundsätzlich gut funktioniert. Das bis die Verbindung zum Unraid-Server mal abbricht, z.B. wenn dieser mal neu gestartet werden muss. Danach bleiben bei beiden Proxmox-Maschinen die beiden Verbindungen auf "status unknown", haben ein Fragezeichen und beim Versuch darauf zuzugreifen kommt folgende Meldung: .

Natürlich werden auch keine Backups gemacht (was am störendsten ist) oder LXCs welche Daten darauf haben werden nicht gestartet, laufen nicht oder nicht richtig usw.Meldung beim Backup:

Das so lange bis ich den ganzen proxmox-node neu starte, dann ist wieder alles gut bis zum nächsten Verbindungsunterbruch zum Unraid. Reproduzierbar unter Proxmox VE V9.2.11, 9.2.10 und weiter zurück...wie weit zurück weiss ich nicht mehr.

Ist das ein bekanntes Problem? Wie kann ich es lösen?

Hab vorerst eine Gotify-Meldung eingerichtet welche aktiv wird wenn ein Backup fehler meldet und starte dann den Node neu, ist aber irgendwie nur eine Krücke, keine richtige Lösung...

Vielen Dank und Gruss

 

[Bu66as]

Hallo @urs, das ist kein PVE-Bug sondern der klassische hängende CIFS-Mount: wenn der Server unter einem hart gemounteten Share wegbricht, blockiert der Kernel jeden Zugriff auf /mnt/pve/UN_26_Prox endlos. pvestatd rennt genau da rein, deshalb das Fragezeichen, und der Mount kommt von allein nicht zurück, auch wenn Unraid längst wieder online ist. Deshalb hilft nur der Reboot.

Statt Node-Neustart reicht normalerweise das:

systemctl stop pvestatd
umount -f -l /mnt/pve/UN_26_Prox
umount -f -l /mnt/pve/UN_27_ProxJamna
systemctl start pvestatd

Danach mounted PVE die Shares von selbst wieder ein. Kannst du dir auch als kleines Skript an deine Gotify-Meldung hängen, ist immer noch Krücke, aber ohne Downtime der Gäste.

Dauerhaft würd ich in der /etc/pve/storage.cfg beim CIFS-Storage mal options soft probieren, dann geben Zugriffe einen Fehler statt zu hängen. Beim Backup-Ziel heisst das halt abgebrochenes Backup statt toter Node, aber das ist mir lieber. Welche SMB-Version fährst du denn und mountest du per DNS-Namen oder IP? Falls Unraid bei dir NFS anbietet, erholt sich das nach so nem Abriss deutlich zuverlässiger als CIFS. Hab ich bei genau dem Szenario schon öfter gesehen.

 

[urs]

Vielen Dank für deine Antwort.

Dauerhaft würd ich in der /etc/pve/storage.cfg beim CIFS-Storage mal options soft probieren, dann geben Zugriffe einen Fehler statt zu hängen.

einfach options soft unten an jedem der beiden shares anhängen? Und dann sollte der share wieder da sein wenn verfügbar ohne unmounten oder den node neu starten zu müssen?

Gemountet wird per IP, mit DNS tu ich mich schwer...
SMB vermutlich V2, hab ich nichts explizit ausgewählt, weder auf Proxmox noch auf Unraid (bin mir aber grad nicht mehr sicher ob ich V1 auf Unraid mal für etwas aktivieren musste.) In der storage.cfg steht nichts drin also V2? Oder wo finde ich welche version grad benutzt wird?

NFS wollte ich mir eigentlich nicht antun...wenn es aber den Share nach Verbindungsunterbrüchen ohne zu hängen wieder einbindet kann ich es mal in einer ruhigen Minute einrichten und probieren...

Vielen Dank und Gruss

 

[ThoSo]

Wenn beim smb Mount keine Version angegeben wird, wird das ausgehandelt.
SMB V3 wäre sinnvoll, da auch schneller als v2. Dazu aber mal beim NAS prüfen was hier für SMB als min und max angegeben ist, sofern das überhaupt angezeigt wird.

 

[jim_os]

Moin

Oder wo finde ich welche version grad benutzt wird?

In der Shell:

mount | grep cifs

eingeben. Ergebnis (hier zwei SMB-Mounts):



Du solltest klären warum bei Unraid die SMB-Verbindung abbricht, denn das dürfte vermutlich halt nicht an PVE liegen. Zumindest habe und hatte ich damit hier mit ganz unterschiedlichen SMB-Mounts (Synolgy NAS, OMV, Asus Router, Fritzbox) noch nie ein Problem. Wobei sich das "nie" auf die letzten rund 5 Jahre mit PVE bezieht.

Edit: Auch wenn ich Unraid nicht nutze, aber auch bei Unraid kann (oder konnte) man die genutzte SMB-Version auswählen. Was notwendig war falls man ggf. noch alte Geräte einsetzt die nur SMB1 können.

VG Jim

 

[urs]

Dazu aber mal beim NAS prüfen was hier für SMB als min und max angegeben ist, sofern das überhaupt angezeigt wird.

Danke. Muss ich mal schauen...im Normalfall aktiviere ich alles ab V2.

aber auch bei Unraid kann (oder konnte) man die genutzte SMB-Version auswählen. Was notwendig war falls man ggf. noch alte Geräte einsetzt die nur SMB1 können.

Genau. Bis zu einer gewissen Version konnte es V1 out of the Box, irgendwann wurde das standardmässig deaktiviert und man konnte es irgendwie aktivieren.Wie geschrieben, ich hatte ein Gerät das nur V1 konnte und wollte und dafür musste ich V1 explizit aktivieren, ist aber inzwischen ausgemustert. Kann aber sein dass V1 trotzdem auf Unraid noch aktiviert ist. Muss ich mal schauen... Aber das sollte doch auf mein Problem keinen Einfluss haben, oder doch?

In der Shell: mount | grep cifs

Danke. Demnach läuft es auf 3.1.1. sehe aber immer noch nicht was das mit meinem eigentlichen Problem zu tun haben könnte. Kann mich jemand aufklären?

Du solltest klären warum bei Unraid die SMB-Verbindung abbricht, denn das dürfte vermutlich halt nicht an PVE liegen.

Natürlich liegt das nicht an PVE. Ein Grund warum die Verbindung abbricht habe ich ja bereits genannt:

wenn dieser mal neu gestartet werden muss.

Gemeint ist der Unraid-Server z.B nach einem Update oder bei Problemen...Weitere Gründe für Verbindungsunterbrüche sind: Ein Proxmox ist über Wireguard am Hausnetz und somit am Unraid angeschlossen. Wenn jetzt im Hausnetz am Router ein Update stattfindet oder am WG-LXC oder das WG-LXC aus irgend einem Grund gestoppt und wieder gestartet wird, oder am entfernten Standort am WG oder Router ein Update gemacht wird oder sonst was am WG oder Router ist oder ein Stromausfall an einem der beiden Orte stattfindet oder oder oder...dann sind alle Geräte erstmal unhappy, erholen sich aber wieder alle ohne weitere Eingriffe meinerseits. Alle sind sobald die Verbindung wieder steht happy und senden/holen fröhlich Daten zum/vom Unraid. Nicht so PVE, das stellt einfach den dienst ein und macht gar nichts mehr bis jemand (ich) ihm wieder sage, hey, deine shares sind längst wieder online.
Das Erste mal wurden nach einem solchen Unterbrch 2 Wochen lang keine Backups gemacht bis ich zufällig da rein geschaut habe...schwein gehabt das in der Zeit nichts passiert ist. Das Szenario hab ich inzwische auch mit besagter Gotify-Meldung abgefangen, aber es ist trotzdem extremst mühsam solchen Geschichten dann nachlaufen zu müssen...solche Sachen sollte das System gefälligst selber wieder auf die Reihe kriegen...ist zumindest meine Erwartungshaltung . Erwarte ich zu viel?

Nur zum klar stellen: Ich kann gut damit leben wen mal ein Backup nicht gemacht wird weil gerade da die Verbindung weg war. So redundant dass das nicht passieren kann, kann und will ich das System gar nicht auslegen. Aber wenn die Verbindung wieder steht würde ich schon erwarten dass PVE im idealfall dort weiter macht wo es gescheitert ist oder aber zumindest beim nächsten cron job wieder normal seine Aufgaben erlediget...was leider nicht der Fall war...vielleicht ändert das mit options soft oder allenfalls NFS, hatte noch keine Zeit es einzurichten und zu testen...

Danke allen und schönen Sonntag

 

[jim_os]

Nicht so PVE, das stellt einfach den dienst ein und macht gar nichts mehr bis jemand (ich) ihm wieder sage, hey, deine shares sind längst wieder online.
....
solche Sachen sollte das System gefälligst selber wieder auf die Reihe kriegen...ist zumindest meine Erwartungshaltung

Tut es auch. Wie bereits geschrieben dürfte das vermutlich an Unraid liegen und ich vermute mal das man dazu in irgendeinem Unraid Forum auch Infos finden sollte. Wie ebenfalls bereits geschrieben habe oder hatte ich hier keine Probleme damit wenn ein per SMB Mount als Storage unter PVE mal nicht da ist, weil es - wie in Deinen Beispielen genannt - z.B. nach einem Update mal neu gebootet und gestartet wird. Aktuell läuft hier PVE 9.2.10. Ich habe das eben extra noch einmal für Dich mit einem Synology NAS durchgetestet.

Also bei dem NAS einen Neustart gemacht. Bis das Synology NAS dann neu gebootet hat und wieder da ist, dauert es bei einem Synology NAS bekanntlich mehrere Minuten. Während der Zeit meldet PVE das das Storage nicht verfügbar ist.




Da das NAS auch noch gleichzeitig ein NUT Server ist kommt eben auch noch zusätzlich die Meldung das UPS keine Verbindung zu dem NUT Server - das NAS - herstellen kann. Nach in dem Fall ca. 4 Minuten wurde das NAS neu gebootet und gestartet und es kommt die Meldung das der NUT Server auf dem NAS wieder erreichbar ist.



Gleichzeitig und automatisch ist das NAS auch wieder per SMB Mount als Storage unter PVE vorhanden.



Auch mit dem "NAS" meiner Fritzbox, das ebenfalls per SMB bei Proxmox als Storage eingebunden ist, gibt es da keinerlei Probleme wenn die FB mal neu gebootet wird. PVE stellt die SMB-Verbindung dazu dann auch wieder automatisch her.

Da ich aber - wie auch schon geschrieben - Unraid nicht nutze weiß ich halt nicht wo da das Problem mit/bei Unraid liegt. Vielleicht kennt sich hier ein anderer User ja mit Unraid aus und - sofern noch nicht gemacht - würde ich danach mal in irgendeinem Unraid Forum suchen und ggf. fragen.

VG Jim

 

[Bu66as]

Der Unterschied liegt wahrscheinlich beim Weg: bei @urs hängt einer der Nodes über WireGuard am Unraid. Ein NAS im selben LAN das rebootet ist für den CIFS-Client was ganz anderes als ein Tunnel der einfach still verschwindet. Im LAN kommt sauber RST bzw. gar keine Route mehr, die Session wird abgeräumt und neu aufgebaut. Fällt der Tunnel weg, bleibt die TCP-Verbindung halb offen und der Kernel dreht Endlos-Retries auf einer Session die serverseitig längst tot ist. Deswegen kriegt @jim_os das mit seiner Syno auch nicht reproduziert.

Schau beim nächsten Abriss mal in dmesg -T | grep -i cifs rein. Wenn da nur Server ... has not responded in 120 seconds. Reconnecting... im Loop steht und nie ein passendes "has reconnected" kommt, hängts genau da. Zweiter Punkt, der bei dir wahrscheinlich der eigentliche Grund ist warum nur ein Reboot hilft: du hast LXCs die Daten von dem Share nutzen. Wenn die per Bind-Mount auf /mnt/pve/... zeigen, sitzen deren Prozesse im D-State auf dem toten Mount fest und lassen ihn nicht mehr los. Prüf das mal mit fuser -vm /mnt/pve/UN_26_Prox wenn es wieder klemmt.

Zu deiner Frage von eben: ja, einfach als eigene Zeile in den jeweiligen Storage-Block, gleich eingerückt wie die anderen Optionen:

cifs: UN_26_Prox
        server 192.168.x.x
        share ...
        content backup
        options soft

Greift aber erst wenn der Mount neu aufgebaut wird, also Storage einmal disable/enable oder umount. Und ganz ehrlich, deine Erwartung ist berechtigt, aber CIFS über eine Leitung die reproduzierbar wegbricht ist halt fragil. Wenn du eh am Umbauen bist: für die Backups über den WG-Link wär ein PBS deutlich robuster als ein CIFS-Ziel, der macht bei Abbruch einfach einen Fehler und beim nächsten Lauf weiter, statt dir den Node lahmzulegen.

 

[urs]

@jim_os & @Bu66as : Danke euch 2 für die Hilfe und die Tests. Problem ist noch nicht gelöst, ihr habt mich aber sehr wahrscheinlich auf dem richtigen Weg gebracht...hab nur grad wenig Zeit, daher dauert das ganze etwas.

Wie bereits geschrieben dürfte das vermutlich an Unraid liegen und ich vermute mal das man dazu in irgendeinem Unraid Forum auch Infos finden sollte.

In Unraid Foren hab ich nichts wirklich sinnvolles dazu gefunden (geht es nur mir so oder wird die Google-Suche wirklich immer unbrauchbarer?) aber ich komme auf den Punkt nochmal zurück...

Der Unterschied liegt wahrscheinlich beim Weg: bei @urs hängt einer der Nodes über WireGuard am Unraid. Ein NAS im selben LAN das rebootet ist für den CIFS-Client was ganz anderes als ein Tunnel der einfach still verschwindet.

Ich denke das dürfte in dem Fall nicht das Problem sein. Die WG-Verbindung läuft zwar über LTE und ist nicht so wirklich schnell, aber darüber funken seit mehr als einem Jahr diverse Systeme (KNX, MQTT, Kleiner Offsite-Backup-Server usw) Daten zu mir nach Hause und zurück ohne merkliche Probleme oder Verbindungsabbrüche. Kommt dazu dass ein PVE bei mir Lokal im gleichen LAN wie der Unraid hängt, keine VLANs oder sonstiges dazwischen und dieser verliert die Verbindung genau gleich wie der PVE hinter dem WG-Tunnel.
Was ich inzwischen gemacht habe: options soft und von SMB auf NFS umgestellt. Ergebnis: Bei Neustart von Unraid bleiben die Verbindungen in PVE zu den Shares in Unraid wie gehabt auf "Status Unknown" und sind damit faktisch tot.
Das Umstellen auf NFS mittels "hilfe" von einer KI gemacht. Da hagelte es Fehlermeldungen dass der eine PVE di Verbindung getrennt hat der andere sie aufgebaut und dann umgekehrt. Anscheinend ein Problem dass die ID gleich sind. Und laut KI angeblich die einzige Möglichkeit das zu beheben indem ich die beiden PVE-Node Namen welche beide Proxmox heissen auf unterschiedliche Namen setze...tja, die liebe KI hat mich dann das System erstmal an die Wand fahren lassen weil eine nachträgliche Node-Namensänderung wohl so nicht vorgesehen ist bzw. so trivial ist. Wie auch immer, sie hat mich dann -entgegen erster Behauptung- dann noch eine weitere Lösung vorgeschlagen. Irgend was mit Unique-ID hat sie mich basteln lassen was offenbar soweit funktioniert dass die Fehlermeldungen nicht mehr da sind, aber am ursprünglichem Problem hat das leider auch nichts geändert. Unraid down heisst Shares in beide PVE un- und wieder mounten damit sie wieder da sind.

Also weiter suchen:

Schau beim nächsten Abriss mal in dmesg -T | grep -i cifs rein.

Danke für den Tip...hab anstatt cifs nun natürlich nfs genommen, aber das brachte schon mal einige neue Erkenntnisse. Für Interessierte hier mal das Log vor, während und nachdem der Unraid-Server ein paar Minuten down war:

[Wed Sep  9 00:29:16 2026]
[Wed Sep  9 00:29:51 2026] nfs: server 10.10.10.248 OK
[Wed Sep  9 00:29:52 2026] nfs: server 10.10.10.248 OK
[Wed Sep  9 00:29:52 2026] nfs: server 10.10.10.248 OK
[Wed Sep  9 00:29:53 2026] nfs: server 10.10.10.248 OK
[Wed Sep  9 00:29:53 2026] nfs: server 10.10.10.248 OK
[Wed Sep  9 00:29:53 2026] nfs: server 10.10.10.248 OK
[Wed Sep  9 00:29:54 2026] nfs: server 10.10.10.248 OK
[Wed Sep  9 20:13:21 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:16:21 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:16:26 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:19:21 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:19:32 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:22:21 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:22:26 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:22:37 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:25:21 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:25:32 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:25:43 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:28:21 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:28:27 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:28:40 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:28:48 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:31:22 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:31:26 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:31:34 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:31:45 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:31:54 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:34:22 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:34:32 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:34:39 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:34:52 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:34:59 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:37:22 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:37:27 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:37:37 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:37:44 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:37:58 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:38:04 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:40:24 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:40:27 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:40:34 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:40:43 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:40:50 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:41:03 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:41:11 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:43:24 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:43:33 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:43:40 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:43:49 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:43:55 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:44:08 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:44:17 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:46:25 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:46:30 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:46:38 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:46:46 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:46:54 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:47:01 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:47:14 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:47:22 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:49:25 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:49:35 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:49:43 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:49:51 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:49:59 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:50:06 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:50:19 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:50:30 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 20:52:04 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:05 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:06 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:07 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:08 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:09 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:10 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:11 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:13 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:14 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:15 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:16 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:17 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:18 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:19 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:20 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:21 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:22 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:23 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:25 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:26 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:27 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:28 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:29 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:30 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:31 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:32 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:33 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:34 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:35 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:37 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 20:52:44 2026] NFS: server 10.10.10.248 error: fileid changed
[Wed Sep  9 20:52:44 2026] NFS: server 10.10.10.248 error: fileid changed
[Wed Sep  9 20:52:44 2026] NFS: server 10.10.10.248 error: fileid changed
[Wed Sep  9 21:00:46 2026] nfs: server 10.10.10.248 not responding, timed out
[Wed Sep  9 21:01:30 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:31 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:33 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:34 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:35 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:36 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:37 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:38 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:39 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:40 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:41 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:42 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:43 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:45 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:46 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:47 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:48 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:49 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:50 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13
[Wed Sep  9 21:01:51 2026] NFS: state manager: check lease failed on NFSv4 server 10.10.10.248 with error 13

Das mal durch die KI gejagt und die rät mir zu folgendem: "Wenn du auf feste, physische Mountpoints (z.B. /mnt/cache/sharename statt /mnt/user/sharename) für deine Exports/Freigaben umstellst, sollte sich das Problem bei beiden Protokollen gleichermaßen deutlich verbessern."

Und die lange Version warum das so sein soll:

Sowohl NFS als auch CIFS haben theoretisch Mechanismen, um einen Server-Neustart zu erkennen (bei NFS die Grace Period, bei SMB einen geänderten "Server GUID" oder eine neue Boot-Zeit im Negotiate-Response). In der Praxis überwacht Proxmox's cifs.ko-Client aber genau wie der NFS-Client die Verbindung nicht aktiv genug, um das automatisch zu erkennen – der Mountpoint bleibt im "toten" Zustand hängen (bei CIFS äußert sich das oft als "Host is down" oder "Permission denied", bei dir wahrscheinlich vergleichbar zu den NFS-Meldungen).

4. Deshalb hilft auch hier nur Unmount/Mount

Nur ein sauberer Neuaufbau (neue TCP-Verbindung, neue SMB-Session, neuer Tree-Connect) räumt den alten, ungültigen Zustand komplett weg – identisch zur NFS-Situation.

Kurz gesagt: Das Protokoll (NFS vs. CIFS) ist fast egal – die Wurzel des Problems liegt eine Ebene tiefer, nämlich im Unraid-eigenen /mnt/user-FUSE-Layer, der bei jedem Neustart die darunterliegenden Datei-Identitäten verändert. Jedes Netzwerkprotokoll, das darauf aufsetzt, erbt dieses Problem.

Klingt erstmal halbwegs plausibel...ob das dann wirklich so ist werde ich die Tage sobald ich Zeit finde herausfinden.

Vielen dank nochmal und Gruss

PS: PBS hab ich mal angeschaut und installiert...scheint nichts was in einer viertelstunde eingerichtet ist. Mal schauen, wenn ich etwas mehr Zeit habe mich da ein wenig einzulesen vielleicht...

 

[GMBauer]

PS: PBS hab ich mal angeschaut und installiert...scheint nichts was in einer viertelstunde eingerichtet ist.

Wenn man es ein, zweimal gemacht hat, dann schon.