Freut mich daß es jetzt funktioniert.
_Ardbeg_ Bleiben für mich zwei Fragen und ein ToDo:
Frage 1: Woher bezogst Du das Wissen zu den ähnlichen Fällen?
Frage 2: Warum hast Du ein solch profundes Wissen zu mount.cifs?
Ganz einfach: Ich bin eine "natürlicheDummheit-GPT" ;-)
Und ich kann Suchmaschinen bedienen. Und kann aufgrund doch einiger Grundlagen recht schnell "problemrelevantes" von irrelevant unterscheiden. Und ich habe oft Glück.
Mit Windows/Samba habe ich seit langen - zum Glück (sic!) - nichts mehr zu tun. Wie ich nun zu der "Lösung" kam?:
Die Meldungen im ersten Post bzgl. "less secure dialect" sind ja IMHO keine Fehlermeldungen, sondern Infos/Warnungen. Mich interessierte dann eher: Was ist der return code -5 ?
Und: kommt dieser Code wirklich von cifs.mount oder mount?
Also suche ich nach "cifs mount return codes". Nur um festzustellen das es so eine "Liste" scheinbar nicht gibt (wie bei vielen anderen Projekten leider auch, außer ggf. im Sourcecode).
Suche ich also weiter nach: cifs mount "failed w/return code = -5"
Viele Treffer, meistens im Bezug zu eben den Änderungen bzgl. der SMB-Versionsdialekte. Dann begrenze ich die Anzeige auf Treffer "im letzen Jahr".
Recht prominent (und aktuell) sticht dabei ein Thread im Fedora-Forum hervor:
https://discussion.fedoraproject.org/t/samba-broken/82614
Der ganze Thread paßt wunderbar zu deinem Problem, v.a. auch daß das Problem "kurzfristig", ohne Konfig-Änderungen o.ä. auftritt.
Der User h.janssen kommt dann Mitte des Threads erstmals mit der Bestätigung das "nodfs" funktioniert bei ihm, bei anderen dann auch.
So dachte ich mir dann: schlag das doch mal als Versuch hier vor. Und ich hatte (mal wieder <g>) Glück...
Also kein "profundes Wissen", aus der manpage-Beschreibung dazu hätte ich nie Infos darin direkt mit deinem Problem in Zusammenhang gebracht.
Ich habe dann später mal etwas zu nodfs recherchiert und bin mir ziemlich sicher (wie im Fedora-Thread schon angemerkt) daß das ein Bug im aktuellen cifs-Modul/part des Kernels ist, bei Fedora wohl ab 6.2.15.
Du weißt ja evtl. das Datum als dein Problem daß erste auftauchte (oder in den Logs suchen) und kannst ggf. nachvollziehen das du z.B. am Vortag ein Systemupdate inklusive eines neuen Kernels gemacht hast. Das dürfte dann die "Übeltäter-Version" sein.
Zu nodfs:
Diese Option weißt mount.cifs an keine Funktionalität des Servers bzgl."Distributed File Services" (DFS) zu verarbeiten. DFS bei Windows bzw. Samba bedeutet, daß eine Freigabe(das Dateisystem) problemlos auf einen anderen Server umziehen kann, durch Änderungen der Mapping-Tabellen ist das für den Client transparent und muß nicht angepaßt werden. Solche Szenarien findet man am ehesten in "großen Umgebungen" mit etlichen Windows/Samba-Servern, meist gekoppelt mit ActiveDirectory(AD) - aber nicht bei einem einzelnen, kleinen, "billigem" NAS...
Zwei Referenzen zu nodfs scheinen mir lesenswert:
https://www.anleitungen.rrze.fau.de/betriebssysteme/linux/druck-und-dateiserver/windows-shares-unter-linux-einbinden/
//Edit: Der Teil zu "Besonderheiten zu Windows Distributed File Services (DFS) und der FAUAD"
Im englischen Archlinux-Wiki:
Punkt 4.4 (Troubleshooting) in
https://wiki.archlinux.org/title/samba
Du könntest also nach weiteren Kernelupdates immer mal schauen, ob es ggf. auch wieder ohne den "nodfs" Parameter gehen würde.
//Edit: Du könntest auch nochmal ins (Samba?)Log deines NAS schauen ob dort bei den fehlerhaften Mountversuchen des Clients Meldungen bzgl. "Distributed File Services" (DFS) aufgetaucht sind. Oder andere Fehlermeldungen, die mit nodfs jetzt nicht mehr anfallen.