Server-Laufwerke "verschwinden"

[zaphod_42]

Hallo zusammen,



ich habe folgendes Probelm (auf allen Mac´s):

- OS X 10.13.x
- Hardware bubnt gemischt
- Netzwerk: 1GBit wired

Wenn ich hier Netzwerklaufwerke per afp mounte verschwinden diese nach kurzer zeit der Nutzung. Mounte ich die selben Devices per smb, so geschieht das nicht. Dieser Effekt tritt eigentlich bei allen NAS Storages auf, die ich im Netz habe. Dieser Effekt tritt nicht auf Windows Plattformen auf und die NAS Server sind zu 100% verfügbar. Die Latenz & pink sind vollkommen ok.

Hat jemand eine Erklärung hierfür? Anscheinen bin ich zu doof den Grund zu finden.


Vielen Dank im Voraus, Tom

 

[Dx667]

Nachdem AFP sowieso deprecated ist würde ich mir darüber keine Gedanken machen. SMB nutzen und „gut“ ist es.

 

[trexx]

Stimme vollkommen zu. Hatte mit AFP auch nur Probleme und schwache Performance.

 

[Wuchtbrumme]

Stimme vollkommen zu. Hatte mit AFP auch nur Probleme und schwache Performance.

echt? Kann ich nicht bestätigen. Auch bei 10.13 quasi noch Zuverlässigkeit und nach nfs schnellstes Protokoll (nicht mehr konkret gebenchmarked). Die Kritikpunkte kenne ich einklich nur von smb. Allerdings gibt es ältere Softwares in NAS usw. die afp anbieten, aber nicht richtig arbeiten. Aber was Dateiaustausch unter macOS angeht, null problemo.

 

[zaphod_42]

Kurze Intervention: Danke für eure Antworten, aber es geht bei der der Frage nicht um "Für und Wider" AFP. Es geht darum, warum die Laufwerke nur unter diesem Protokoll "umounted" werden.

Habt Ihr da eine Idee?

Und nein, ich kann momentan nicht auf AFP verzichten.

 

[Dx667]

Weil es nicht mehr weiter entwickelt wird und sich niemand um eine vernünftige Kompatibilität kümmert.

 

[Wuchtbrumme]

was sind denn das für NAS? Wie stellst Du die Netzwerkverbindung her? Wie sind die Schlafeinstellungen des Mac, wann treten die Probleme auf?

 

[tjp]

Kurze Intervention: Danke für eure Antworten, aber es geht bei der der Frage nicht um "Für und Wider" AFP. Es geht darum, warum die Laufwerke nur unter diesem Protokoll "umounted" werden.

Das kann man ohne Fehlerlog auf dem NAS und Deinen Macs rein gar nichts dazu sagen. Also, nachschauen ob im System irgend etwas dazu geloggt wird. Dann die Fehlermeldung hier posten.

Nachtrag: AFP läuft aus. Es wird muss zwingend darüber nachgedacht werden das Protokoll entweder mit SMB oder NFS zu ersetzen.

 

[zaphod_42]

Hallali. Nun habe ich das Problem auch bei Massenkopieraktionen mit SMB als connect Protokoll. Keine Fehler im NAS log, OS x sagt mir nur lapidar, dass die Laufwerke nicht mehr verfügbar sind.

Ich kann das ganz aber nun ein weniog mehr eingrenzen. Reproduzierbar, wenn ich >1TB kopieren und/oder >100.000 Files. Das ist leider Tagesgeschäft.

 

[ottomane]

Beantworte doch mal die Fragen: #8

 

[zaphod_42]

Nun ja, das passiert bei JEDEM NAS (Buffalo, IBM usw.). Es passiert nicht im SleepMode, sondern bei der Übertragung großer Datenmengen (Sowohl Volumen als auch Dateizahl). Das mounten ist dabei unerheblich. Es passiert sowohl wenn ich es über Netzwerklaufwerke verbinden mache (smb;//......) als auch, was bei mir der normale Weg ist, per Script.

 

[ottomane]

Also hängt es nicht vom NAS ab und es tritt bei großen Datenmangen auf. Bliebe der Mac und das Netz.

Ich würde ausprobieren, über eine alternative Netzverbindung zu gehen. Andere Kabel, anderer Switch. Natürlich kein WLAN benutzen.

 

[zaphod_42]

Nein. Es ist definitiv der Mac. Der Fehler tritt ausschliesslich unter OS X auf, auf allen Mac´s reproduzierbar. Win10, Debian, RedHead vollkommen problemlos, auch im gleichen Netzsegment. Es ist definitiv ein OS X Problem und es tritt sowohl bei WLan als auch bei Fixed Wired connection auf. Ich hatte sogar die Latenzen im Netz gemessen um auszuschliessen, dass OS X hier ein Problem bekommt. Aber das ist alles mehr als sauber. Cisco GBit.

 

[Wuchtbrumme]

ist ja schön, dass Du schon alles weißt. Warum bist Du dann noch hier?
Das ist nahe an einem Trollposting: Trotz Nachfrage immer noch kein Log. Aber dafür

Ich hatte sogar die Latenzen im Netz gemessen um auszuschliessen, dass OS X hier ein Problem bekommt. Aber das ist alles mehr als sauber. Cisco GBit.

keine Ahnung, was das sein soll. Latenzen messen? Welche denn? Die Nanosekunden bei der Autonegotiation?

Wenn Du Hilfe willst, dann können wir uns auf den Mac konzentrieren, wenn Du den im Verdacht hast.

Aber bitte strukturiert und mit den nötigen Infos zu den Nachfragen (Logs, Schlafeinstellungen mittels pmset -g und pmset -g log), dazu der *genaue* Fehlerzeitpunkt. Hast Du Assertions gesetzt bzw. den Mac zwangsweise wachgehalten? Jetzt schon mal die Nachfrage: Ist alles bei Dir auf denselben Zeitserver eingestellt und die Geräte auch gesynct? Welche Protokolle/Protokollversionen verwenden die einzelnen NAS?

Ich habe vor nicht einmal drei Wochen mit 10.13.6 ungefähr 8TB kopiert (AFP); alles ohne Probleme.

 

[zaphod_42]

Nochmal: Es geht um alle Macs. Und es tritt ausschliesslich bei OS X bei dem Transfer von grossen Datenmengen auf. Assertions helfen hier auch nicht wirklich weiter, da diese nur im Debug Modus gesetzt sind und nicht bei einem Wirk-System. Wäre es nur ein Mac, so würde ich den einfach neu aufsetzen lassen und gut ist. Der Effekt tritt jedoch erst seit Sierra auf und fängt nun langsam an mich persönlich zu nerven. Bei meinen Entwicklern habe ich das immer ignoriert Schande über mein Haupt.

Und nur mal so: Mit lLatenzen kann das sehr wohl zu tun haben, wenn die Trigger für die validierung einer etablierten Netzwerkverbindung regelmässig in´s Nirvana laufen.

 

[thomas65s]

Nur bei dir spielen ALLE Macs verrückt, also muss es an macOS liegen.
Und jetzt nochmal wiederholen. Merkst du wie unlogisch das klingt?

 

[Wuchtbrumme]

Assertions helfen hier auch nicht wirklich weiter, da diese nur im Debug Modus gesetzt sind und nicht bei einem Wirk-System.

"Was?". pmset -g assertions. Das pmset-Log sollte die notwendigen Infos auch haben.

Und nur mal so: Mit lLatenzen kann das sehr wohl zu tun haben, wenn die Trigger für die validierung einer etablierten Netzwerkverbindung regelmässig in´s Nirvana laufen.

"Was?". Hunderte Millionen dämlicher User setzen die Technik in ihrem Heimnetzwerk ein. So dumm ist das nicht.

WO IST DAS LOG? Verflixt nicht noch eins.

 

[zaphod_42]

SO, habe habe den Grund und eine Lösung gefunden. Wechselt man beim Mounten auf CIFS als Protokoll, so ist das Problem behoben.

Die Ursache ist eine Fehlerhafte smb Implementierung, die sich seit Sierra 10.13 (High) durchzieht. Somit war mein Einschätzung richtig. Es ist ein Timeing Problem.

Ein allgemeines Statement von heise.de:

"
Während manche Aktionen wie das Anlegen eines Ordners sich normal ausführen lassen, treten die Abstürze bei bestimmten Tätigkeiten sofort auf, etwa beim Abspeichern eines Dokumentes oder dem Verschieben einer Datei aus einem Ordner auf eine höhere Ebene, wie auch Mac & i in einem kurzen Testlauf reproduzieren konnte. Die Aktion wurde zwar ausgeführt, zugleich stürzte aber der Finder ab und zwar unwiederbringlich – es half nur noch das Erzwingen eines Neustarts.

Dieses Absturzproblem scheint kein generelles High-Sierra-Problem zu sein, sondern erst spezifisch mit der Anfang Dezember veröffentlichten macOS-Version 10.13.2 aufzutreten, die sich hauptsächlich der Fehlerbehebung gewidmet hat. Entwickler berichten, dass der Bug auch in der derzeitigen Beta von macOS 10.13.3 den Finder noch zum Absturz bringt.
"

aus 2017.

Bei mir läuft es nun mit der Umstellung des Protokolls.

 

[zaphod_42]

Ich lasse gerade, zur Verifikation, zwei Jobs laufen:

a) 500.000 Files a 2MB
b) 100 Files a 80GB

Wenn das durchläuft, dann war es das. Dieser beiden Tests haben nie funktioniert.

 

[Wuchtbrumme]

das ist ja prima, aber das ist doch ein bekanntes Problem, das hier schon dutzendfach gepostet wurde.
Wenn Du nur ein Mal eine belastbare Information von Dir gegeben hättest hätte man darauf verweisen können.

Ich bin jetzt raus.