Neue Phänomene – MacOS Sonoma, InDesign CC, QuTS hero

Zitat von derkolarsky

ich weiß, dass Adobe offiziell nicht zur Rechenschaft gezogen werden kann, wenn man wider Ansage von denen auf einem Netzwerklaufwerk arbeitet

Das hattest du vorher nicht erwähnt. Das ändert die Lage.

Die Netzwerkdateisysteme bieten nicht die volle Funktionalität des lokalen Dateisystems. Es kann vorkommen, dass deswegen mal etwas nicht funktioniert. Ich habe hier den Fall, dass das Subversion-Plugin für Eclipse nicht funktioniert, wenn der Workspace auf einer SMB- oder AFP-Freigabe liegt. Mit einer NFS-Freigabe geht es hingegen. NFS ist in der Konzeption und den Möglichkeiten näher an einem lokalen Dateisystem als SMB und AFP es sind.

Von daher wäre die Einbindung der Netzlaufwerke per NFS einen Versuch wert. NFS hat aber aber auch Nachteile. Zum einen müssen User-IDs (oder ab NFS 4.0 Usernamen) über das ganze Netzwerk abgeglichen sein. Zum anderen erfolgt der Zugriffsschutz über das lokale Login an Rechner, d. h. wenn der Admin nicht alle Rechner im Netzwerk unter seiner Kontrolle hat, gibt es keinen Zugriffsschutz (über Kerberos soll es doch gehen, habe ich aber nie probiert). Den wechselnden Zugriff mit NFS und SMB/AFP auf dieselbe Freigabe kann ich nicht empfehlen.

Es ist aber auch denkbar, dass sich die Adobe-Software verschluckt, wenn zwei Benutzer auf dieselbe Datei im Netzwerk schreibend zugreifen (auch wenn der Zugriff nicht gleichzeitig stattfindet). In dem Falle wird eine Umstellung auf NFS das Problem nicht lösen.

Frage:

Treten die seltsamen Phänomene auch dann auf, wenn nur ein einziger Benutzer arbeitet? (Es geht um die Abklärung, ob der gleichzeitige Zugriff verschiedener Benutzer Ursache des Problems ist.)

Hallo zusammen und vielen Dank für die vielen Kommentare und euren Input, das „nicht zu helfen“ mal ausgeklammert, denn sowas kann man – wenn man denn will – auch eleganter ausdrücken…

Also ich versuche mal alles in eine Antwort zu packen:

> Thema Software (Mac/QNAP) (von Austro-Diesel )

aus meiner Sicht ist hier beim Mac nichts Auffälliges (aktuelle Programme der Creative Cloud, Microsoft Office, Indizierung wohl die interne vom Mac). Der QNAP hat nur HBS3, die myQNAP-Apps, Qboost und den Security Counselor).

> Dateirechte ( von Austro-Diesel )

alle User (meistens sogar nur einer aktiv, weil kleines Büro) haben für die jeweiligen Freigabeordner volle Rechte. Primär sind die Zugriffsrechte über Gruppen gelöst, sekundär noch mal gezielte Sonderfreigaben einzelner User. Habe ich bei einem anderen Team ebenfalls so gelöst und läuft prima.

> Temporäre Dateien (von NaStrada )

die temporären Dateien im Finder sind mir durchaus bewusst und kenne ich auch zuhauf – sowohl lokal, als auch auf Server-Seite.

> Indizierung und Protokolle ( von Mavalok2 )

bewusst bin ich aufm QNAP noch nicht aufs Thema Indizierung gestoßen oder aber es ist quasi „automatisch“ bei meinem Aufsetzen mitgelaufen. Wo finde ich die Settings, wenn, im QNAP? Zugriffsprotokolle habe ich mir (bisher jedenfalls) noch nicht angeschaut, ist aber auf meiner Liste. Danke Mavalok2 für den Hinweis.

> NFS ( von Mavalok2 und Anthracite )

hier hab ich mich ehrlicherweise noch nicht rangetraut, da ich mit NFS einfach gar keine große Erfahrung habe und bevor ich da irgendwas abschieße…

> Ganze Ordner umbenennen ( von Austro-Diesel )

Richtig. Ich kenne da auch nix. Das ist gruselig/erschreckend/fatal, wenn die Ordner plötzlich anders heißen.

> Anzahl User ( von Anthracite )

Wie oben geschrieben, großteils nur ein User und auch nur ein Rechner (Mac Studio M1) aktiv.

Ich hoffe, ich hab keine Anmerkung/keinen Kommentar unbeantwortet gelassen. Ich schick das Thema jetzt auch zusätzlich noch an den QNAP-Support. Stoße hier aktuell ein wenig an meine Grenzen…

Ich halte euch auf dem Laufenden

Cheers

Ralf

Zitat von derkolarsky

Der QNAP hat nur HBS3, die myQNAP-Apps, Qboost und den Security Counselor).

Also Standard Apps und Dienste. Kann mir eigentlich nicht vorstellen, dass die es sind. Die werkeln so ziemlich auf jedem NAS. Das wäre dann wohl vermehrt aufgetreten.

Zitat von derkolarsky

bewusst bin ich aufm QNAP noch nicht aufs Thema Indizierung gestoßen oder aber es ist quasi „automatisch“ bei meinem Aufsetzen mitgelaufen.

Die Multimedia Indizierung läuft meines Wissens automatisch mit. Aber auch die läuft vermutlich bei sehr vielen NAS. Aber wenn nicht benötigt, kann man die ja auch mal deaktivieren / deinstallieren. Wobei, wird die beim aktuellen QTS überhaupt noch mit installiert? Ist ja inzwischen eine eigene App im App Store. Das Multimedia-Dings ist bei meinen NAS von jeher immer deaktiviert oder wenn möglich deinstalliert.

Multimedia Console | QTS 5.0.x

>> Edit <<

Sorry, altes Handbuch, aktuelles hier:

Multimedia Console | QTS 5.1.x

Könnte ggf. ein anderer Netzwerk-Bestandteil (z. B. ein Netzwerk-Switch) Grund für solche Problematiken sein?

Ich hab es wenigstens soweit reduziert, dass alle Netzwerkgeräte über den gleichen Switch laufen statt teilweise direkt an der Fritzbox und teilweise am Switch. Bisher allerdings noch keine Chance gehabt, einen anderen Switch zu testen.

Kann ich mir irgendwie nicht so richtig vorstellen. Ein defekter Switch, bei dem die Netzwerkverbindung beim Speichern unterbrechen würde, würde wohl eher beschädigte Dateien produzieren und keinen Ordner umbenennen. Ich denke, das ist schon ein Programme / Dienst oder der gleichen dahinter. Ich denke, dass es auch irgendwie mit MacOS zu tun haben muss, denn ansonsten wäre das Problem sehr wahrscheinlich schon öfter aufgetreten. Hier im Forum sind doch die meisten mit Windows unterwegs.

Welche Firmware genau ist auf dem NAS installiert? Vielleicht könnte hier ein Update oder ein Downgrade gegeben Falls noch eine Option sein.

Welche Version von Sonoma ist genau im Einsatz? Habe gerade gelesen, dass MacOS 14.4 wohl noch Probleme hat. Zwar betrifft dies wohl Java, aber wer weiß. Auch MS Office soll aktuelle unter MacOS Problem machen. Was hier los ist, kann ich allerdings nicht sagen.

Ein defekter Switch ist nicht komplett auszuschließen, aber unwahrscheinlich.

Gibt es außer den umbenannten Verzeichnissen denn noch weitere Fehler, z. B. manchmal fehlerhaft übertragene Dateien?

Zitat von derkolarsky

Wie oben geschrieben, großteils nur ein User und auch nur ein Rechner (Mac Studio M1) aktiv.

Alle anderen Macs sind ausgeschaltet oder zumindest die Adobe-SW läuft dort gerade nicht? Und auch dann tritt der Fehler auf? Das spricht gegen Probleme durch konkurrierende Zugriffe und erhöht die statistische Wahrscheinlichkeit, dass der Versuch mit nfs erfolgreich wird.

Um den Versuch mit nfs mit minimalem Aufwand durchzuführen:

- nfs auf QNAP aktivieren

- neue Freigabe erstellen (darf in einem bestehenden Volume sein)

- diese Freigabe mit nfs auf nur einem Gerät mounten (z. B. über "Mit server verbinden" oder mount im Terminal). An allen anderen Netzwerkfreigaben änderst du nichts, also wie bisher mit smb.

- Dann arbeitet der eine Mac testweise mit den Adobe-Produkten auf dieser Freigabe.

(Wenn nur ein Benutzer testweise auf der Freigabe arbeitet, kannst du den Punkt mit dem Abgleich der User-IDs ignorieren, und der Zugriffsschutz spielt vermutlich auch keine Rolle.)

=> Tritt der Fehler dann auch auf, d. h. gibt es auch auf der nfs-Freigabe seltsame Verzeichnis-Umbenennungen?

Zitat von Mavalok2

Welche Firmware genau ist auf dem NAS installiert? Welche Version von Sonoma ist genau im Einsatz?

NAS hat die aktuellste QTS (nicht QT Hero oder wie das heißt) und Sonoma ist auch aktuell, also 14.4. Das Problem ist aber auch vorherigen Versionen von macOS aufgetreten…

Zitat von Anthracite

Alle anderen Macs sind ausgeschaltet oder zumindest die Adobe-SW läuft dort gerade nicht?

Andere Macs sind mal an, mal aus und Adobe läuft mal und mal nicht – ändert nix an der Situation.

Und NFS teste ich mal. Vielen Dank für die Infos dazu.

Zitat von Austro-Diesel

Sind alle Computer unter verschiedenen Usernamen mit dem QNAP verbunden?

Welche Betriebssysteme und -versionen werden genutzt? Alles homogen oder wild gemischt?

Unterschiedliche Usernamen: ja. Aber auch das war teilweise früher mal anders.

Betriebssysteme jeweils die aktuellsten auf QNAP und den Macs (1x Mac Studio M1 mit Sonoma, 1x Intel-iMac mit Sonoma und 1x älterer Intel-iMac mit Catalina)

Zitat von Anthracite

Gibt es außer den umbenannten Verzeichnissen denn noch weitere Fehler, z. B. manchmal fehlerhaft übertragene Dateien?

Kopieren, Speichern, bzw. Speichern unter muckt massiv rum bei AFP. Unter SMB wohl nicht, aber da beginnt dann eben die Namens-Schnitzeljagd…

Es könnte vielleicht einen Zusammenhang mit den Veto Files die in der SMB.conf/Qnap SMB Einstellungen standardmäßig drin sind geben. Dieses Einstellungen verhindern z.B. dass man ein Verzeichnis von einem synology NAS auf ein Qnap kopieren kann, welches erzeugt wurde indem ein user unter Windows Bilder von einem Iphone auf ein (altes) Synology NAS kopiert hat.

Das MacOSX legt auf SMB Volumes alles mögliche abartige an - das früher auf AFP Volumes oder auch auf NTFS volumes in einer extra Fork (AFP) oder einem alternativen Data-Steam (NTFS) drin war.

Zitat von Austro-Diesel

Sind diese Ordner mit den abenteuerlichen Namen immer kürzlich angelegte Verzeichnisse oder sind es auch ältere die schon einige Zeit bestehen?

Langsam bin ich mir nimmer ganz sicher mit meiner Aussage, dass einfache Netzwerkprobleme nicht (Mit-)Ursache sind … und DHCP funktioniert sauber?

Leider auch hier die unklare Aussage: mal neu, mal älter. Das ist echt unfassbar wahllos.

Und ja, DHCP funktioniert im Netzwerk. Die QNAPs haben aber alle feste IPs außerhalb der DHCP-Range.

Zitat von nobody411

Es könnte vielleicht einen Zusammenhang mit den Veto Files die in der SMB.conf/Qnap SMB Einstellungen standardmäßig drin sind geben.

Oh! Das klingt interessant. Hab das mit den Veto-Files gesehen, klang für mich aber eigentlich recht logisch. Und Windows bzw. Synology kommen aber in der gesamten Kette nicht vor. Jedenfalls nicht, dass ich da irgendwas mitbekommen hätte.

Ich dachte zuerst, die "VETO" dateien, die sind einfach unsichtbar. Aber dann konnte ich mit robocopy unter Windows einige Ordner nicht kopieren, Das waren Ordner die hiessen sowas wie ".@__thumb" und enhielten wohl die Vorschau der Bilder des darüberliegenden Ordners - und die waren auf einem alten Synology NAS.

Wie die Ordner dothingekommen sind, das weiss ich nicht, denn der User benutzte Windows. Hat aber ein iphone.

Im übrigen gibts auch bei Synology VETO dateien, Aber ich habe nicht geprüft ob die identisch mit den QNAP Veto-Dateien ist.

Jedenfalls ich habe dann getestet ob man einen Ordner mit dem namen ".@__thumb" anlegen kann auf einem Qnap NAS via SMB verbunden. Und siehe da, es wird verweigert. Natürlich kann man den in der shell anlegen. dann ist er da.

Meine Fantasie: Mit MacOSX und AFP sind solche Namen erlaubt (wogegen übrigens mit AFP manche andren Namen verboten sind. Kopiert man nun einen Ordner von einem Windows SMB Share auf einen per AFP geshareten Ordner, da kann man die auf das Ziel kopieren. Aber dann kann der order auf dem SMB volume ja vielleicht Ordner/dateien enthalten die eigentlich VETO dateien sind.

Verwendet man dann wiederum SMB um auf die gleichen Dateien zuzugreifen, dann könnte es Probleme geben, kann ich mir zumindest vorstellen.

Hast Du denn das näher erforscht?

Aber dann müssten die Ordner mit den "komischen" Namen doch zusätzliche Ordner sein und nicht umbenannte Ordner mit den eigentlichen Dateien. Diese "VETO" Dateien - hießen die früher nicht mal Fork oder so? - enthalten aber nur zusätzliche Informationen und nicht die eigentlichen Daten, oder? Kopiert man unter MacOS Dateien z.B. auf eine USB-Stick der mit FAT32 formatiert ist, dann werden diese auch nicht mit kopiert. Die Daten bleiben aber trotzdem erhalten. Zumindest war dies früher mal so. (Habe leider noch kein Sonoma im Einsatz)

Was eine resourcefork enhält, das bestimmt das Programm dass die erzeugt. Im falle einer Word datei oder eines jpeg Bildes nichts wichtiges, nur ein icon oder einen preview und meta-information. Aber das kann auch anders sein.

kopierst Du unter MacOSX dateien die eine Resourcefork haben, auf einen USB stick mit FAT32 legt MacOSX dateien an wie ._filename.xyz für jede datei die eine Resourcefork hat. Daher bleiben die Daten der Resourcefork erhalten. Das gleiche gilt auch wenn man von einem HFS+ volume eine Datei mit einer resourcefork oder metainformation auf ein SMB volume kopiert.

Wenn aber jemand (unter windows) z.B. die Datei x.ext löscht, und diese eine zweite Fork hat, nennen wir die mal x.ext/rsrc, oder jemand benennt die um. Und es ist auf einem Dateisystem wie SMB das keine forks kennt, dann bleibt die x.ext/rsrc als Leiche übrig. Nun erstellt jemand anderer aber eine neue x.ext. Plötzlich bekommt die für einen Mac eine zusätzliche resourcefork die gar nicht dazugehört.

Oder aber ein Mac schreibt eine neuedatei x.ext mit einer resource fork dann gibts aber die schon, und das gibt wahrscheinlich eine Fehlermeldung.

mit AFP auf NTFS oder AFP auf HFS da würde das nicht geschehen, denn das weiss dass die resourcefork dazugehört.

Eigentlich hat aber Apple schon lange nichts mehr mit resource-forks. Die sind 2005 ausgestorben.

Die andere Option ist, dass Programme die derkolarsky verwendet zufälligerweise Dateien oder Ordner produzieren wollen die per Veto gesperrt sind.

Ich weiss es nicht genau. Es ist nur eine Vermutung.

etwas OT dazu:

Ich trauere den Services für Macintosh nicht sehr hinterher, Dier Performance war im Vergleich zu dem Apple eigenen Server damals nicht befriedigend. Es gab noch third party produkte, nur die wollten in erster Linie reich werden hatte ich den Eindruck, Als dann Apple seinen eigenen Server mit TCP/IP unterstützung hatte statt AppleTalk, da endete das dann bald weil Apple die Lust am eigenen Produkt verlor. Somit haben alle anderen auch aufgegeben.

Hallo zusammen,

also ich habe inzwischen nochmal ein wenig getestet und auch parallel die Infos an den QNAP-Support gespielt. Der Support ist noch im Auswerten von Log-Dateien und da passiert vermutlich vor Mitte kommender Woche nix.

Nachdem ich die Veto-Funktionalität abgeschaltet hatte, schien es auf einmal alles zu laufen – warum auch immer… AFP hatte ja merkwürdige Abstürze und laut Log-Datei gab es da wohl sowas wie einen Abbruch/ein Timeout. Näheres werde ich noch berichten, wenn sich der Support wieder gemeldet hat.

Wünsche euch noch ein paar entspannte Tage

//R

.AppleDouble
.AppleDesktop
.DS_Store
Network Trash Folder
Temporary Items
TheVolumeSettingsFolder

z.B.:

.DS_Store - Wikipedia

Aber das sind doch gerade die typischen Dinge die MacOSX erzeugen würde wenn man per SMB auf einen Server zugreift (und wenn ein Programm oder das MacOSX die notwendigkeit sieht diese anzulegen).

Verbietest Du das, und versucht das MacOSX diese dennoch anzulegen, dann gibts vielleicht ein Problem.