Hi, kann mir jemand sagen ob das Verhalten normal ist oder ob das an meinen seit mehreren Wochen ständigen Problemem mit SMB zusammenhängt?

Sorry, übersehen/vergessen.
OS 15 Public Beta 3 oder 2. was gerade aktuell ist. Problem bestand aber unter 14.X auch schon.

Warum installiert man in einem Netzwerk mit dem man stressfrei arbeiten möchte auf einer FRITZ!Box und auf den Macmini M2 Beta Software?
Genau darum frage ich schon im Vorfeld nach den Eckdaten zu Hard- und Software.
Bei BETA bin ich nun komplett raus, kann ich weder Nachstellen, noch kenne ich die aktuellen Changelogs.

Problem bestand ja schon bevor auf beiden Geräten die Beta lief. Hatte gehofft Beta würde es evtl. lösen. Tatsächlich war die Lösung jetzt ja der LAN-Port.

Hast du dies nun endgültig validiert mit dem Anschluß der Geräte direkt an die FRITZ!Box ohne jeglichen Switch?

Also das Problem trat wieder auf. Ich bin jetzt per WLAN mit der FB verbunden und von dort per Kabel direkt an der Synology und trotzdem beim Copy:



Eine kleine JPEG von 12 MB kann ich ohne Probleme hin und her kopieren und bewegen, läuft. Sobald ich eine größere Videodatei nehme von mehreren hundert MB.....kaputt. Immerhin hab es beim Plotter keine Paketverluste. Ich werde mal die Fritzbox wieder auf die letzte Stapel zurücksetzen und diese als Fehlerquelle auszuschließen.

Ich habe jetzt mal eine alte TimeCapsule aus dem Regal geholt und den Mini und die Diskstation nur damit verbunden. Fritz!Box und auch die sonstige Hausverkabelung sind damit raus.

Fehlerbild bleibt. Nur kleine Dateien von wenigen MB werden anstandslos übertragen.



Wenn das so weitergeht, Wechsel ich nach 15 Jahren wieder zurück zu Windows....weil...it just Works.

Kannst Du einen Screenshot von Systemeinstellungen/Netzwerk machen und mitteilen, was in den Details bei DNS eingetragen ist? Die zwei Zitate habe ich rausgepickt, weil es für die erste Beobachtung noch keine Erklärung gibt und es auffällt, dass es funktioniert, wenn eine andere Netzwerkverbindung ins Spiel kommt.
Ansonsten habe ich hier etwas den Überblick verloren, was alles geprüft wurde.

Also auch unter Windows kommt es bei Transfers zu einelnen Paketverlusten in Richtung FritzBox, aber die Transfers laufen trotzdem durch, es gibt keine Abbrüche und auch die SMB-Laufwerke bleiben erhalten.

„Moin“ in die Runde…
Möchte hier einmal eine andere Fehlermöglichkeit ins Spiel bringen… da ich genau dieses Verhalten bei mir in der letzten Zeit ebenfalls feststellen konnte… Direkt über die GUI einer Syno (in Safari) Kopie perfekt - über Finder (SMB) wird scheinbar übertragen aber erst am Ende des Dateitransfers gab es die „Fehler 51 - Meldung“…
Es sah bei mir so aus, als ob es da ein Problem mit dem Dateisystem (Btfrs) der Syno gibt wenn via Finder (mit SMB-Protokoll) zur Syno kopiert wird. (Es gab nach meiner Erinnerung in diesem Zusammenhang einen Hinweis (im Protokoll der Syno) dass ich nicht die erforderlichen Zugriffsrechte hätte…)
Deshalb hab ich versucht die Rechte für das übergeordnete Verzeichnis auf der Syno neu seitens des Mac zu setzen (inkl. untergeordnete Verz.). Werden vielleicht die Dateiattribute bei/nach der Übertragung nicht korrekt übernommen oder verändert?
Vielleicht hilft diese(r) Hinweis/Ansatz/Überlegung weiter…
(Hier aktuelles MacOS-Sonoma und Syno akt. 7.x)

Ja, das Verhalten hatte ich auch schon. Aktuell beginnt der Transfer aber nicht einmal. Bevor es überhaupt losgeht kommt meistens schon der Fehler -51. Mal gibt es dann auch Paketverluste, mal nicht. Das Problem ist jedes mal etwas anders und nichts scheint länger als 2-6 Std zu helfen, dann gehts wieder von Vorne los...

@Tommy1980…

Ok, schau mal ins Protokoll der Syno welche Fehlermeldung da zum Kopierzeitpunkt erscheint…
LG Swimmi

Musste die SMB-Protokolle erstmal aktivieren. In den Synologyprotos war nichts spannendes zu sehen leider.

Ethernet ist alles auf Standard, da Das System ja nun frisch aufgesetzt wurde. Unter DNS sind 3 Einträge. Einmal die IPv4 Adresse der Fritz!Box und dann noch 2x IPv6 der Fritz!Box, einmal mit dem Präfix und einmal ohne.

Und ja, so langsam denke ich hierfür wäre ein Discordchat schon praktischer. =D
Vielen Dank aber an allen die Bock haben mir zu helfen und mir auch schon versucht haben hier zu helfen. Es ist echt komplex und ich befürchte dass ich hier vllt (warum auch immer auf einmal) vllt mehr als nur ein Problem habe und die Kombi das echt schwer macht grade.....

Lösche DNS-Einträge, die Du selbst eingetragen hast, die passenden Einträge kommen automatisch von der Fritzbox. Erwarten würde ich, dass dort 1x IPv4 und 1x IPv6 steht. Jedenfalls finde ich es seltsam, dass deine Diskstation unter wechselndem Namen auftraucht, das habe ich bei mir noch nicht gesehen und könnte durchaus ein Symptom von dem Hauptproblem sein.

Gibt leider keine Fehlermeldungen. Es kommt der Fehler -51 im Finder und im Log sieht man dann, wie er die Datei im Zielpfad löscht. Das wars.

Habe jetzt manuell nur die 192.168.0.1 der Fritz!Box eingetragen und auch noch IPv6 auf der DS deaktiviert (dachte das hätte ich schon gemacht). Sehe im Log wie jetzt statt IPv6 halt über IPv4 zugegriffen wird. Aber das Problem bleibt. SMB zu SMB ist kein cp oder mv möglich. Nur über den Umweg das File erst auf den Mini zu ziehen und dann wieder zurück an die DS. Das klappt problemlos.

Selbst die IP der Fritzbox müsste automatisch gefunden werden, ohne dass du das manuell einträgst. Ist bei dir die Fritzbox nicht 192.168.1.1?
Also für mich übersetzt heißt das Du kannst im Finder von einem Netzlaufwerk zum anderen direkt kopieren oder verschieben, aber zwischen Netzlaufwerk und Mac ist alles ok?

Zu 1: Ich habe immer schon 192.168.0.XXX. Einfach so drin bei mir. Sollte aber keine Probleme machen oder doch? Ja, die vergibt er auch automatisch, aber dann halt auch die beiden IPv6 und ich dachte die wollen wir grade nicht haben aktuell.

Zu 2: Finder SMB-Netzlaufwerk <> SMB-Netzlaufwerk Nope
Finder SMB-Netzlaufwerk <> MacMini - Läuft

ja, lass es mal so. Es driftet womöglich vom Problem ab, aber was sind das für zwei IPv6, die vom Router genannt werden? Sind das zwei Link-Local IPv6-Adressen (fe80:: ...)? Ich frag mich, warum das zwei Adressen sind, habe aber keine Idee.
Das wundert mich jetzt allerdings deutlich weniger, da Aktionen auf der Diskstation per Finder immer zäh sind. Das kann man besser direkt auf der DSM-Oberfläche machen.
Nur deswegen sollten die SMB-Laufwerksverbindungen oder Synology Drive nicht abbrechen.

Das ist alles wildes stochern im Nebel, so wird das nichts.
Wenn man Tests durchführt dann Schritt für Schritt und nicht wild gemixed mit mehreren Faktoren gleichzeitig.
Wenn der gleiche Fehler auch im WLAN auftritt, dann ist wohl Ethernet raus aus der Nummer.

Grundlegende Vorbereitung:
Alles auf Standard, nirgendwo irgendeine Beta am Start! Weder im Router, noch macOS!
Synology auf den aktuellsten Stand bringen, IPV6 abschalten. SMB Large MTU aus!
Prüfen das auf der Synology kein DHCP läuft!
Macmini mit M2 Chipset, wie wurde der neu aufgesetzt? Ein System mit M-Prozessor wird anders zurückgesetzt als ein System mit Intel-Chipset.
Macmini M2 neues Netzwerkprofil anlegen und dort IPV6 auf Link-Local umstellen.
Vor dem Hardware-Netzwerk-Umbau alle Geräte sauber herunterfahren.
Danach immer nur 1 Einstellung/Komponente ändern und erneut testen. Sobald etwas am Netzwerk verändert wird, alle Geräte neu starten!

Eingesetzte Kabel nicht aus der Krabbelkiste nehmen, nur neue Kabel zum Testen verwenden oder sofern möglich diese Kabel mit einem Netzwerktester prüfen.

Da es ja auch nun beim Windows PC Package Loss gibt, ist wohl hier generell im Netzwerk etwas n.i.O.
Sinvollerweise einen Zettel mit Testprotokoll anlegen und alle einzelnen Schritte aufschreiben, dann weißt du auch noch was wie getestet wurde.

Das deutet in den meisten Fällen darauf hin, dass ein Fehler in der Unicode-Normalisierung eines Dateinamens vorliegt. Kann es sein, dass unter den zu kopierenden Daten Namen enthalten sind, die Umlaute oder diakritische Zeichen ("Akzente") enthalten und diese Daten wurden ursprünglich vom Windows-Rechner angelegt?

Windows verwendet UTF8-Code mit Normalisierung C, macOS verwendet UTF8-Code mit Normalisierung D. Dateinamen mit der entgegengesetzten Normalisierung gelten für das jeweils andere Betriebssystem als ungültig und können grundsätzlich nicht kopiert werden. Das ist normal und muss so sein.

Zu den IP-Adressen: Alle Apple-Geräte verwenden seit vielen Jahren standardmäßig IPv6. Geräte sollten immer nur per Namen und niemals per Adresse angesprochen werden. Die lokalen Namen werden vom Router und/oder per Bonjour verwaltet.

Problem tritt auch bei Dateien auf mit Namen wie Test124.FUU.

Heisst wenn Apple jetzt im Standard IPv6 verwendet, dann IPv6 auf der Synology nicht ausschalten? Und woher kommt denn das hier? Warum wieder 2mal? Woher kommt dieses local? müsste es wenn dann nicht Fritz.box sein? So wird es von PingPlotter nämlich angezeigt wenn ich die IP anpinge kommt DiskStation.fritz.box.

Also die ungewöhnliche IP 192.168.0.1 für die Fritzbox oder "Diskstation.fritz.box" deutet doch darauf hin, dass deine Netzwerkeinstellungen speziell sind.

Wenn ich mal eine Lücke finde (sonst macht mich die Familie nen Kopf kürzer), werde ich die FB auf Werkeinstellungen zurücksetzen und außer meine Portfreigaben nichts weiter ab vom Standard konfigurieren.

Sorry, nur weil man ein anderes Netzwerk Segment als das Default von der FRITZ!Box nutzt, bedeutet das noch lange nicht das es speziell ist. Man nutzt ein Class C Netzwerk im privaten Bereich im Router, manchmal ist es auch durchaus sinnvoll den zu ändern, damit man weg vom Standard ist, damit es bei VPN Verbindungen keine Probleme gibt. Also bitte den TE nicht noch zusätzlich verwirren mit solchen Aussagen.
192.168.0.1 ist vollkommen o.k. Das würde im übrigen auch von alten FB genutzt, bevor AVM die default Adresse auf 192.168.178.1 gesetzt hat. Speedport Router nutzen z.B. 192.168.2.1 und das ist auch nicht verkehrt, liegt alles im Class C und somit absolut stressfrei, solange man den Router den Rest automatisch vergibt und nicht irgendwelche Routings umbiegt.
Bitte auch das Downgrade auf die Stable Release 7.57 machen. Die IP der FRITZ!Box darf gerne auf 192.168.0.1 bleiben, lass dich da nicht beirren!

Und das ist wie lange her? Stammen die Einstellungen noch von einer alten Fritzbox?
Mein Hinweis bezog sich darauf, dass die Netzwerkeinstellung nicht aktueller Standard der Fritzbox sind.
Gibt es hier VPN? Wäre ja auch interessant für die Problemlösung, zu wissen, wenn hier zwei Netze verbunden sind.

Interessat wäre, ob es auch zu Fehlermeldungen kommt, wenn du den Kopiervorgang mal per z.b. Cyberduck durchführst. Das kann auch SMB.

@Tommy1980
Bitte unbedingt auf die Stable Release der FB gehen, die Beta hat einiges an Problemen:

Also bitte alle Geräte auf Stable Release und erneut mit frischen Settings testen.

@SudoRinger
Das ist doch vollkommen unerheblich wie lange das her ist. Jeder Hersteller hat irgendwann schon mal die IP des eigenen Routers geändert, solange es im Class C ist, ist es total egal wenn es nicht kaputtkonfiguriert wurde. IP des Routers gesetzt, gespeichert, Neustart des Routers und aller Geräte im Netzwerk und gut ist es.
Die hier erläuterten Probleme haben absolut nichts mit einem gewählten Netzwerkbereich zu tun. Hier gibt es Package Loss, was nicht gut ist. Nicht jeder übernimmt den Standard des Herstellers, warum auch?

Kleiner Zwischenstand:
Ich habe gestern Abend noch den Netgear-Switch im Homeoffice durch eine alte Fritzbox 4040 ersetzt, die ich noch rumzuliegen hatte. Diese ist jetzt als AP (Mesh) und Switch im Office im Einsatz. Der Mini hängt wieder an seinem Port dran und seit nun fast 24 Std keine Paketverluste mehr im Plotter, kein komisches Verhalten der Synodrive aus dem Startpost. Keine sich trennenden SMB-Shares. Lediglich einige Dateien weigert er sich noch beharrlich von SMB zu SMB zu verschieben. Das allermeiste hat er jetzt jedoch anstandslos bewegt.

Anscheinend ist da doch etwas dran, dass die Fritzbox (zumindest in der Laborversion) nicht so gerne mit Fremdfabrikaten (hier switch) zusammenarbeiten möchte.

Bevor eine aktuelle Software-Version auf den Markt kommt, testen Technologie-Unternehmen eine BETA Software. Die Unternehmen versprechen sich davon noch umfangreicheres Feedback und Hinweise auf Bugs, die im internen Testing übersehen werden.

Darum sollten man nicht einfach in einem Netzwerk das stabil laufen soll einfach mal eine Beta installieren, nur weil man einen Fehler hat und vermutet das man ihn damit beheben kann. Das ist die absolut verkehrte Vorgehensweise. Beta Software testen man auf seinen Zweitgeräten die nicht im produktiven Umfeld genutzt werden, damit man sich nicht noch weitere Probleme dazuholt.
Beta Software ist für Entwickler gedacht, die ihre eigene Software schreiben oder Hardware entwickeln, damit sie sich frühzeitig mit den Neuerungen auseinandersetzen können.
Und zu deinem Problem FRITZ!Box und Switch hatte ich dir schon geschrieben das es mit verschiedenen FB Probleme mit den GigaBit Ports und Switchen gab, da waren einige Chargen laut Aussage von AVM defekt. Die wurden aber nicht getauscht, da das Problem nicht überall aufgetaucht ist.

Es wäre zum Abschluss noch interessant, ob die Fritzbox 4040 die gleichen Einstellungen wie das ersetzte Gerät hat oder anders konfiguriert ist.

Die 4040 übernimmt die Einstellungen von der 6690. Sie hat den Netgear Unmanaged Switch ersetzt. Da konnte man ja eh nicht konfigurieren. Seitdem keine Paketverluste mehr. 🤷‍♂️

Wow, eine Woche. Die Lösung hatte ich schon im zweiten Beitrag genannt.

Wie man eine Woche an SMB rumfummeln kann, wenn Pings ausbleiben und Dienste nicht funktionieren, die gar kein SMB nutzen ist mir ziemlich schleierhaft.

Aber naja, Hauptsache es funktioniert wieder.

P.S.: Falls Du mal mit dem Auto liegen bleibst, weil Du einen Platten hast, höre nicht auf Empfehlungen in Auto-Foren, die Wahl eines anderen Senders im Autoradio könnte das Problem lösen.

Hallo Hans, nun lassen Sie uns doch auch unseren Spaß.
Kabel hatte ich ja Anfangs alle schon getauscht, eine TimeCapsule genutzt, anderen Switch genutzt, dann neuen Switch (auch anderer Hersteller) gekauft. Erst die 6 Jahre alte und bereits vor 2 Jahren ausgemusterte Fritzbox 4040 löste das Problem. Das kann man ja nicht ahnen.

Denn möchte ich auf niemanden nehmen. Nur zu, wenn's Spaß macht.

Du hast tatsächlich vorgeschlagen den Switch zu tauschen. Es wurden Ersatz-Switch von Tommy1980 eingesetzt, was offenbar nicht half. Erst der Ersatz des Switch durch einen Router half das Problem zu lösen.

Auch wenn Du dir hier auf die Brust trommelst, war die (durchaus gute) Idee den Switch auszutauschen nicht die Lösung, die das Problem hier erklären könnte.
Ein Switch-Tausch erklärt die SMB-Verbindungsabbrüche, aber was hat der Switch mit doppelten Einträgen der Diskstation im Finder zu tun?

Ist das vllt einfach normal?
Pings sind alle OK und wenn ich an den Ordner was ändere, setzt Drive das auch sofort um und steht dann erstmal wieder auf "Aktuell" vorher auf Connecting....

Ist irgendwie unschön.

Also ich habe seit heute einen neuen Mac Mini M4. Keines der Geräte hier ist mehr auf irgenwelchen Betaversionen, alles Stable und es geht noch immer nicht....

Dabei hat es bis zur Eröffnung dieses Thread zu 99% reibungslos funktioniert....unter Windows eh die ganze Zeit. Was ist denn bloß mit MacOS los?

Und immer wieder sowas bei Transfers, die dann gar nicht erst starten....es ist ermüdend. Ich will doch nur Daten von A nach B bewegen, dass ist doch nicht zu viel verlangt oder doch?

Selbst wenn ich das File einfach an Ort und Stelle versuche zu kopieren. Ohne dass ich in einen anderen SMB-Share gehe klappt es nicht.....man!

Hast Du dich eigentlich an den Synology support gewandt? Mir konnten sie immer gut weiterhelfen.

Werde ich mal machen und berichten. Mich nervt dass mich das schon länger beschäftigt und stört als alle Windowsprobleme die ich jemals hatte....meh.

Such mal im Internet nach „M1 SMB Synology“ oder „macOS SMB numbers autosave error“ und ähnlich.

HAUFENWEISE Einträge bei Apple Community, Synology Forum und anderen.

Mit Intel-Mac alles fein. Seit M1 Prozessor trouble mit SMB. Je nach Fehlerbild-Suche finde man andere Beiträge.

Ich habe diese Probleme:
- iWork Programme melden Fehler beim Autosave und beim manuellen Speichern, dass sie die Datei anderweitig geändert habe (ich bin der einzige User an dieser Datei)

- DevonThink: Ich habe einen Job eingerichtet der neue PDF aus einem Scan-Verzeichnis (Synology) in die Inbox (Synology) kopiert und OCR drauf laufen lässt. Immer mal wieder Fehler, dass Berichtigungen fehlen würden. SEHR nervig

- kann soweit gehen, dass plötzlich die App hängt (beachball) bis nach minuten(!) eine Meldung kommt oder es einfach wieder geht.

Ich habe versucht an der Synology AFP abzustellen, nur SMB2 zuzulassen ohne Bonjour.
Ich dachte es hätte geholfen. Es fing aber wieder an.

Jetzt habe ich am mac eine nsmb.conf eingerichtet mit Parametern die ich in Foren fand. Das Problem beim speichern mit iWork Programmen (und auch mit Vorschau wenn ich ein Bild oder ein PDF auf dem Server bearbeite) sind noch da. Habe wenig Hoffnung, dass meine DevonThink Automation jetzt besser läuft. Muss ich beobachten.

Es ist zum heulen!

Manche schreiben, sie hätten an der Synology AFP aktiviert und dann verbindet sich der Mac via afp und alles sei gut … Ich hatte allerdings eben mit afp auch die o g Probleme - allerdings war ab der Synology ja auch smb aktivier (und ich kann es auch nicht abstellen weil andere Geräte dies nutzen. Der Scanner z. B.)

Kann das mit der Versionierung zusammenhängen? Pages speichert auch alte Bearbeitungsstände auf dem Mac, aber nicht auf dem NAS. Dazu kommt, dass der Mac die Datei bei der Bearbeitung geöffnet hält und immer sofort speichert. Bei einem NAS muss dafür eine Datei-Sperre aktiviert werden.
So genau kann ich den Unterschied nicht erklären, aber es wird deutlich, dass die lokale Speicherung auf dem Mac und auf dem NAS sich stark unterscheidet. Daher würde ich am Mac nie direkt auf dem NAS bearbeiten.
Warum kein Bonjour? Ich würde gründsätzlich SMB3 wählen (oder NFS) und kein AFP, was Apple schon vor 10 Jahren abgekündigt hat.

@ela
endlich ein Leidensgenosse hier. Haha =)
Ja, mit meinem Intelmac hatte ich solche Probleme nie, das kam erst mit den M-Chips. Aber das muss doch Apple mal hinbekommen. Kann doch nicht sein, dass sie es über Jahre nicht gefixt bekommen. Wie du ja schon sagtest sind wir ja auch nicht die einzigen mit dem Problem. Mh.

Ich kann mir vorstellen, dass das nicht jeder kennt. Wie im Bild dargestellt kann z.B. in Pages auf alte Versionen zurückgegriffen werden.

Ja natürlich können Apple Programme (und ein paar andere) Versionen verwalten und die Probleme (dieses eine genannte) könnte damit im Zusammenhang stehen.

Da tun sich Fragen auf:
- warum sagt die App beim schließen des Dokumentes, dass die Datei an einem Ort liegt in dem keine Versionen gespeichert werden können? Wenn die App das erkennt, warum sollte sie es dann vorher trotzdem versuchen?

- wenn die Ansage ist, dass Versionen nur lokal gespeichert werden (so war es damals ausschließlich; inzwischen geht glaube ich das iCloud Laufwerk auch. Was ja aber auch lokal gesichert ist …), warum sollte dies dann eine Ursache für ein Problem beim speichern sein?

- warum treten diese Probleme mit einem Intel Mac auf demselben Laufwerk nicht auf?

Nach allen was ich bisher dazu finden konnte (und ich suche in Summe sicher schon seit Wochen verteilt auf 1-2 Jahre seit ich den M1 habe) gehe ich davon aus, dass es schlicht ein Bug im macOS ist. Die SMB Implementierung für M Prozessoren hat irgendeine Macke - oder ist schlicht falsch konfiguriert)
Apple scheint so etwas aber nicht zu testen (die QM Abteilung hat ganz offensichtlich seit einiger Zeit ein Problem falls es sie noch gibt aber das geht hier am Thema vorbei)

Meine Hoffnung ist, dass es ein Problem der SMB Konfiguration ist und dass die per default beim Intel Mac anders ist (kann ja hart im Code stehen oder die Treiber haben irgend ein anderes IF oder was weiß ich) und dass man das mit der nsmb.conf nachstellen kann und irgendwer herausfindet wie …


Ja natürlich möchte man kein AFP mehr nutzen was seit Jahren abgekündigt ist. Stellt sich aber auch die Frage, warum macOS es noch immer per default nutzt wenn es verfügbar ist?!
An der Synology beides aktivieren und dann mal im Finder zum Server wechseln und eine Freigabe anklicken damit sie gemounted wird. Dann im Finder auf „Netzwer“ wechseln und mit cmd-Pfeil-rauf nach zur Übersicht gehen, die gemountete Freigabe auswählen und mit cmd+I Infos anschauen - AFP gemounted

Ich habe ja jetzt afp an der Synology deaktiviert damit der Mac zu smb gezwungen ist. Das klappt dann auch. Leider eben mit genannten Problemen.

Ein forcieren auf smb3 werde ich auch mal testen, bin aber nicht sicher, ob Scanner und Drucker(?) das können finde ich aber raus.

Ist aber schon sehr nervig. Weil eben NICHT „just works“ und null Probleme mit Intel Mac (außer dass der wegen anderer Dinge nervt - Lüfter, kaum Akku Laufzeit, langsam )

Ist zwar nicht besonders hilfreich, aber Apple hat noch nie offiziell irgendwo das Arbeiten auf Netzlaufwerken unterstützt oder besonders hervorgehoben. Die Programmierer gehen heutzutage davon aus, das man mit der lokalen schnellen SSD direkt auf dem System arbeitet, maximal mit einer extern angeschlossenen SSD.
Da sich diese Problematik mit Netzwerken AFP und SMB durch viele Generationen durchzieht, sieht man doch, das hier nicht wirklich großes Interesse daran besteht das hier wirklich nachgebessert wird.
Zur Info, das trifft nicht nur macOS, auch andere Betriebssysteme haben da ihre Probleme. Auch andere Hersteller bzw. Apps z.B. von Adobe machen immer wieder Probleme mit Netzlaufwerken.

Aber bleiben ja auch noch immer meine vielen SynoDrive-Meldungen. Das kann ja auch nicht Sinn der Sache sein, zumal das ja mal alles problemlos lief. Kann doch nicht sein, dass man jeden Tag 20-30 Connect und Disconnect Meldungen hat. Und das nur weil man von Intel auf AS gewechselt ist.

Nur weil es bei Dir seit Apple Silicon nicht funktioniert, heißt nicht, dass das die Ursache ist. Insbesondere wenn es bei anderen funktioniert. Ich gehe nach wie vor eher davon aus, dass etwas an der Konfiguration falsch ist, auch wenn das vehement bestritten wurde (Switch-Tausch ...).