Probleme beim Daten kopieren MacStudio (M1) in Windows Server-Umgebung

[implied]

Hallo Ihr,

so, bin jetzt wieder als Angestellter unterwegs...
Nun arbeite ich mit MacStudio (M1) in einer Netzwerkumgebung (öffentlicher Dienst) und habe da immer wieder das Problem mit ganz banalen Finder-Kopien von Dateien von Mac auf den Windows-Server. Die Ansage der IT ist, dass ich auf dem Server arbeiten "muss/soll". Das ist auch der Grund, warum mir bisher von der IT keine lokale TimeMachine HD genehmigt wird .

Ich weiß nun leider nicht, was Ihr genau für eine (fachkräftige bzw. weiterführende) Analyse an dezidierten Infos braucht, und da ich erst neu im Job bin habe ich noch nicht genug Erfahrung mit der Infrastruktur.
Aber vielleicht kommen wir ja gemeinsam auf die richtigen Fragen, die ich im Falle der IT stellen kann.
Die IT selber sagt nämlich, es läge am Mac, denn mit den Windows-Rechnern läuft ja alles - und sie kennen sich mit Mac dann leider doch nicht soooo sehr gut aus

Meine Problemstellung als ein Beispiel:
Ich habe einen vorhanden Ordner der 2 Vorgänger-Damen in meinem Job auf die interne Festplatte kopiert, um den irrsinnigen Datenwust zu sortieren, (mehrfach) redundante Dateien zu löschen. Nach der (wohlgemerkt 3 Stunden dauernden Sortieraktion) wollte ich dann den neuen Ordner mit einem neuen Namen (etwa 3,2GB) auf den Server kopieren.
Nach kurzer Zeit brach die Serververbindung ab (Meldung, ignorieren oder trennen machte soweit keinen Unterschied). Der Finder meldete dann, die Datei "LN 5535 1.JPG" könnte nicht kopiert werden, da der Dateiname zu lang wäre bzw. Zeichen enthält, die der Server nicht unterstützt. Das ist jedoch aus 2 Gründen wohl Humbug, denn zum einen stammt die Datei ja ursprünglich von dem Server, zum anderen war das ja ein kurzer Name.
Der Server/das Netzwerklaufwerk bleibt dann immer für mehrere Minuten für den Mac nicht erreichbar, aber auch ohne Neustart funktioniert es dann wieder

Das passiert leider immer wieder, eine Struktur ließ sich bisher für mich nicht erkennen, warum er abbricht.
Ich habe dann versucht, einzelne Ordner zu kopieren, teilweise habe ich probiert Ordner auf dem Server anzulegen und Dateien ohne weitere Ordner-Unterstruktur zu kopieren.... Mal geht es, mal geht es nicht.

Was kann ich prüfen, kann ich irgendwo in Protokollen oder ähnlichem nachschauen, "was" dann passiert im Hintergrund, wenn der Fehler auftritt?
Was habt Ihr denn da für Ideen, woran es liegen könnte?

Vielen Dank schon mal, lieben Gruß

PS:




Als kleine Nebeninfo:
Der IT Admin meckert hier (natürlich) über Apple, aber leider technisch insgesamt dann doch zu hoch für mich, um das wirklich zu verstehen.

Er meint in etwa: Windows könnte, aber "Apple" will nicht. Es würde nur SMB 1.0 unterstützt, dabei wäre 2.0 längst Standard, Verwendung unterschiedlicher Zeichensätze, Problem mit Kopie auf lokale Platte (da MacOS die Zugriffsrechte umschreiben würde und damit die Kopie zurück unter andere Maßgabe stattfindet....etc.etc.

Vielleicht hilft Euch das weiter?

 

[Marcel Bresink]

Er meint in etwa: Windows könnte, aber "Apple" will nicht. Es würde nur SMB 1.0 unterstützt, dabei wäre 2.0 längst Standard,

Das ist alles Unsinn. Apple unterstützt SMB 3, zwischen zwei Macs kommt zurzeit standardmäßig SMB 3.0.2 zum Einsatz.

Was die beiden Computer zur Kommunikation gerade ausgehandelt haben, kannst Du auf dem Mac mit dem Befehl

smbutil statshares -a

anzeigen.

Verwendung unterschiedlicher Zeichensätze

Auch das ist sehr zweifelhaft. Fast alle Betriebssysteme verwenden etwa seit dem Jahr 2000 für Dateinamen Unicode in UTF8-Darstellung. Es gibt höchstens Unterschiede in der Normalisierungsform für mehrfach codierte Zeichen.

Problem mit Kopie auf lokale Platte

Das wäre theoretisch denkbar, aber man könnte den Mac zu einem Active Directory Client machen, so dass er die gleiche Benutzerdatenbank verwendet, wie die Windows-Rechner.

Wahrscheinlich sind aber eher Kompatibilitätsprobleme beim Datei-Locking die Ursache. Es wäre hilfreich, die Kopie über das Terminal statt über den Finder zu machen, da bekommt man korrekte Fehlermeldungen.

 

[implied]

SMB 3.0.2 habe ich mittlerweile selbst herausgefunden, per Terminal - dann hab ich einen screenshot davon an die IT gesendet.
Bin leider erst Montag wieder drin….. Bin mal auf die Reaktion gespannt.

Ok, Terminal kann ich leider nur mit expliziter Anweisung (Zeichenketten) bedienen, kenne mich mit den Befehlen nicht aus - die IT auch nicht.
Kopie des betreffenden (abbrechenden) Ordners per Terminal probiere ich gerne, hast Du da die Befehle für mich, da wäre ich wirklich dankbar

Gut, schon irgendwie Schade, dass ich als Mitarbeiter hier Recherche der IT übernehmen muss, aber so scheint es nun mal. Ich muss sozusagen wohl der IT nachweisen, dass der Fehler bei Windows liegt

Gibt wohl noch andere, laut anderen Mitarbeitern seit Jahren bestehende Probleme, dass manche Arbeitsplätze nicht „richtig“ arbeiten bzw. im Vergleich manche viel zu langsam im Zugriff sind. IT sagt, ist alles Gigabit, Anschlusswerte in der Norm…“das kann gar nicht sein“.

Habe da nämlich zusätzlich noch das Problem, dass ich eine Applikation an einem TV in einem vorgelagerten Pavillion betreiben soll. Im Haus funktioniert es, im Pavillion jedoch nicht (Netzwerkkabel alles in der Norm, können wir nichts machen).
Vielleicht hängt das Problem an meinem Mac Studio ja irgendwie auch damit zusammen (time out Fehler oder irgend so was)?

Sorry, ich weiß leider zu wenig über Netzwerke, vom hausinternen mal ganz abgesehen, um da treffsichere Vermutungen anstellen zu können, deshalb suche ich ja hier Hilfe, Ihr seid so dermaßen fit

Wahrscheinlich sind aber eher Kompatibilitätsprobleme beim Datei-Locking die Ursache. Es wäre hilfreich, die Kopie über das Terminal statt über den Finder zu machen, da bekommt man korrekte Fehlermeldungen.

Datei-locking konnte ich nichts erhellendes finden. Tipps dazu?

Und wie bereits gesagt, eine Anleitung dazu wäre ganz toll

 

[Scotch]

schon irgendwie Schade, dass ich als Mitarbeiter hier Recherche der IT übernehmen muss

Was ist denn eigentlich der Hintergrund, dass du als Angestellter im (ausgerechnet) öffentlichen Dienst in einer anscheinend homogenen Windows-Umgebung als (anscheinend) Einziger einen Mac benutzen musst?

 

[Wuchtbrumme]

Der Finder meldete dann, die Datei "LN 5535 1.JPG" könnte nicht kopiert werden, da der Dateiname zu lang wäre bzw. Zeichen enthält, die der Server nicht unterstützt. Das ist jedoch aus 2 Gründen wohl Humbug, denn zum einen stammt die Datei ja ursprünglich von dem Server, zum anderen war das ja ein kurzer Name.

Wie Marcel schon gesagt hat, die Fehlermeldungen über den Finder sind ... Fehlermeldungen und sagen nichts besonderes aus, außer dass es nicht geklappt hat.

Ich wollte an der Stelle nur noch anmerken, dass Deine Hypothese, es sei Humbug, da ja der Name kurz ist, etwas zu vorschnell ist. Gemeint ist der gesamte Pfad auf dem Server und auch der Netzwerkpfad darf bestimmte Längen nicht überschreiten, weil er ja auch dort gespeichert werden muss. Auf NTFS-Festplatten (die der Fileserver der IT vielleicht benutzt) sollte das nicht mehr als 260 Zeichen umfassen.

Aber wie gesagt, der Finder hat keine gescheite Fehlermeldung für Fehler in Netzwerkaktionen.

 

[implied]

Ja, die (für mich sichtbaren) Namen von Ordnerstruktur und Dateinamen hatten weniger als 256 Zeichen. Hypothese „Humbug“ stammt ja daraus, dass ich das bereits abzählte - allerdings muss ich dann mal nachfragen, ob ich ggf. nur untergeordnete Ordner sehe und es darüber noch weitere gibt, so dass es mit 256 Zeichen dann am Ende doch eng wird. Dennoch konnte ich Dateien mit längeren Dateinamen ja auch kopieren, so dass ich das eigentlich ausschließe.

Es stellt sich nicht die Frage, warum ich Mac nutze oder nicht. Die Abteilung nutzte ja auch schon vorher Mac.Ich weiß aus anderen Infrastrukturen, dass es grundsätzlich geht. Den Fehler zu finden ist angesagt und nicht, den Arbeitsplatz umzubauen. Am Ende wird es nur eine kleine richtige/falsche Einstellung im Netzwerk sein, firewall-Einstellungen, Berechtigungen, Datei-Locking, was auch immer…
Ja, es ist nicht meine „Aufgabe“, aber nachdem was ich mitbekam ist das ein wenig Kampf gegen Windmühlen, wenn in der IT gegen Apple gewettert wird und für alles verantwortlich gemacht wird

 

[Scotch]

aber nachdem was ich mitbekam ist das ein wenig Kampf gegen Windmühlen, wenn in der IT gegen Apple gewettert wird und für alles verantwortlich gemacht wird

Das ist meiner Erfahrung nach auch fast immer richtig. Ich kenne solche Probleme, wie die deinen, auch noch aus meinem privaten LAN und die traten immer nur bei sehr großen (paar 100GB aufwärts) oder sehr vielen Dateien (große Verzeichnisbäume) auf. Und auch ausschliesslich bei meinen Macs, nie bei Windows oder Linux Kisten/VMs. Meine Workarounds waren entweder in "Häppchen" zu kopieren oder eine VM mit Windows oder Linux unter macOS zu starten und von da aus zu kopieren (ja, echt!).

Mein Fazit: Samba ist unter macOS Schrott. Schon immer so gewesen und es bessert sich auch nicht. Apples Lösung ist "Cloud", alles andere kann man unter macOS (im Vergleich zu Windows und Linux) vergessen. Selbst wenn es funktioniert ist die Performance unterirdisch. Selbst ihr "hochgelobtes" AFP (NetBIOS ist doof, SMB ist doof) war so "toll", das sie es sang- und klanglos irgendwann beerdigt haben. AppleTalk anyone?

 

[Wuchtbrumme]

Hallo @implied , hast Du die Verbindung zum Server statt mit smb:// schon einmal mit cifs:// herzustellen versucht?

 

[Scotch]

CIFS oder SMB hat nur in v1 einen Unterschied gemacht (und auch da nur selten). Seit v2 spielt das keine Rolle mehr.

 

[implied]

Hmmmm.

Das ist meiner Erfahrung nach auch fast immer richtig. Ich kenne solche Probleme, wie die deinen, auch noch aus meinem privaten LAN und die traten immer nur bei sehr großen (paar 100GB aufwärts) oder sehr vielen Dateien (große Verzeichnisbäume) auf. Und auch ausschliesslich bei meinen Macs, nie bei Windows oder Linux Kisten/VMs. Meine Workarounds waren entweder in "Häppchen" zu kopieren oder eine VM mit Windows oder Linux unter macOS zu starten und von da aus zu kopieren (ja, echt!).

Wenn es denn wenigstens in „Häppchen“ zuverlässig funktionieren würde. Aber selbst Ordner mit nur wenig Dateien, die zudem nicht mal sehr groß sind, führen zum Fehler - manchmal kopiert er Ordner trotz vieler Dateien und Unterordner sowie größeren Datenmengen einwandfrei.

Ach ja, was mir aufgefallen ist, ist vielleicht noch hilfreich:
Wenn es zu einem Fehler kommt, wurden bisher ausschließlich entweder 0kb oder 6,4MB kopiert
...update.Heute hat er einen Ordner fast fertig kopiert, ist bei 69,3 von 83MB ausgestiegen...

 

[implied]

Ich konnte es mittlerweile etwas reduzieren:
Der Fall tritt wohl nur auf, wenn ich nicht nur einen Ordner mit Dateien schicke, sondern wenn in dem zu kopierenden Ordner ein oder mehr Unterordner drin sind. OK, könnte man sich am Ende auch dran gewöhnen, ist aber eben etwas hinderlich.

Meine unbedarften Ideen:

Ist da eventuell das Problem in der Umsetzung afps zu ntfs zu suchen?
Gibt der Mac da ggf. in dem Versuch es umzusetzen irgendwelche „temporären Namen“ oder irgendwas an, was dann zu dem Fehler führen könnte? Interessant ist, dass in so einem Fall der Mac wohl in sehr hoher Frequenz Anforderungen an den Server versucht, um es zu übergeben, der sagt aber nach wohl ein paar hundert Anfragen „was soll denn das werden?“ und der sagt mir dann „Ällabätsch“ und schließt meinen Benutzer für die nächsten 5 min. aus dem System aus.

Ich hab ja auch ein Terminal drauf, da kann ich in einer Windows Umgebung (VM?) arbeiten, aber: Gehe ich dort in den Explorer kann ich zwar Dateien/Ordner mit drag&drop auf meinen Mac ziehen, anders herum geht es jedoch nicht. Da war meine Hoffnung, dass das Terminal als „Schnittstelle“ für Datenkopien gehen könnte.

 

[Marcel Bresink]

Ist da eventuell das Problem in der Umsetzung afps zu ntfs zu suchen?

Nein, die gemeinsame Sprache zwischen beiden Computern ist SMB, d.h. es läuft Folgendes ab:
1. Der Mac setzt APFS nach SMB um.
2. Der Windows-Server setzt SMB nach NTFS um.

Ohne eine saubere Diagnose kann man nichts sagen. Du kannst einen Kopierversuch ohne Finder wie folgt versuchen:

1. Starte das Programm "Terminal" aus dem Ordner "Dienstprogramme".
2. Tippe im Terminal-Fenster den folgenden Befehl, gefolgt von einem Leerzeichen ein:

cp -R

3. Ziehe aus dem Finder den zu kopierenden Mac-Ordner auf das Terminal. Der entsprechene Dateiname wird in korrekter Schreibweise eingefügt.
4. Tippe nochmal ein Leerzeichen dahinter.
5. Ziehe aus dem Finder den Ziel-Ordner auf das Terminal. Auch hier wird der Dateiname eingefügt.
6. Drücke die Eingabetaste.

Es kann sein, dass macOS um die Erlaubnis bittet, dass das Programm "Terminal" auf das Netzwerk zugreifen darf. Das muss bestätigt werden.

Der Kopiervorgang läuft jetzt. Wenn ein Fehler auftritt, wird nach dem jeweiligen Dateinamen eine korrektere Fehlermeldung (in kurzem Englisch) geliefert. Falls hier alles fehlerfrei läuft, ist der Finder die Ursache.

 

[implied]

@Marcel Bresink Superklasse. Vielen Dank, ich hoffe, ich kann es morgen abchecken

 

[implied]

Der Kopiervorgang läuft jetzt. Wenn ein Fehler auftritt, wird nach dem jeweiligen Dateinamen eine korrektere Fehlermeldung (in kurzem Englisch) geliefert. Falls hier alles fehlerfrei läuft, ist der Finder die Ursache.

Danke nochmals, habe es mal so gemacht. aber es folgt der "Absturz" wie immer, sprich "Serververbindung unterbrochen".

2 Meldungen sehe ich hauptsächlich. Der zu kopierende Ordner ist "KV-Schraenke", die erste Fehlermeldung bezieht sich gleich auf einen Unterordner im Unterordner

cp: /Users/implied/Desktop/Archiv - bereits auf Marketing kopiert/KV-Schraenke/2022/Bilder fertige KV-Schraenke/Thumbs.db: could not copy extended attributes to /Volumes/ordnerstruktur/abteilungen/Marketing/Kopie-Test/KV-Schraenke/2022/Bilder fertige KV-Schraenke/Thumbs.db: Input/output error
cp: /Volumes/ordnerstruktur/abteilungen/Marketing/Kopie-Test/KV-Schraenke/2022/Bilder fertige KV-Schraenke/LN 21099 2.JPG: No such file or directory

Danach folgen einige "no such file or directory", die sich auf den Ordner beziehen, der wohl nicht angelegt werden kann.
Bei einem anderen Unterordner folgt dann folgendes und natürlich weiteres:

cp: /Users/implied/Desktop/Archiv - bereits auf Marketing kopiert/KV-Schraenke/2023: unable to copy extended attributes to /Volumes/ordnerstruktur/abteilungen/Marketing/Kopie-Test/KV-Schraenke/2023: No such file or directory
cp: /Volumes/ordnerstruktur/abteilungen/Marketing/Kopie-Test/KV-Schraenke/2023/Wiesenstraße.docx: No such file or directory

Vielleicht sagt Dir / Euch das mehr? Ich interpretiere hier mal, dass Unterordner nicht angelegt werden können und die Kopie lediglich deshalb schief geht. Was meint Ihr?

Vielen Dank

 

[Wuchtbrumme]

Hallo, könntest Du mal ein

ls -la '/Users/implied/Desktop/Archiv\ -\ bereits\ auf\ Marketing\ kopiert/KV-Schraenke/2023'

machen und die Ausgabe posten?

Hatte es nicht auch noch Ordner, die besonders geschützt sind? Der Dateiname ist so richtig (also alles Spaces?)?

 

[implied]

Mac-Studio-von-implied:~ implied$ ls -la /Users/implied/Desktop/Archiv\ -\ bereits\ auf\ Marketing\ kopiert/KV-Schraenke/2023
total 5080
drwxr-xr-x  12 implied  STWZ\Domänen-Benutzer     384 27 Jun 12:54 .
drwxr-xr-x@  9 implied  STWZ\Domänen-Benutzer     288 27 Jun 12:44 ..
-rw-r--r--@  1 implied  STWZ\Domänen-Benutzer    8196  3 Jul 08:46 .DS_Store
-rwx------@  1 implied  STWZ\Domänen-Benutzer  719172 27 Jun 12:53 2023-Liste KV-Schränke.numbers
-rw-r--r--@  1 implied  STWZ\Domänen-Benutzer    6701 27 Jun 12:54 2023-Liste KV-Schränke.xlsx
drwx------  11 implied  STWZ\Domänen-Benutzer     352 27 Jun 12:11 An der Weinleithe 1,7,13
drwxr-xr-x@ 10 implied  STWZ\Domänen-Benutzer     320 20 Jun 15:44 Ansbacher Straße Ecke Rankenstraße
-rwx------   1 implied  STWZ\Domänen-Benutzer  726988 27 Jun 12:40 Mühlstraße.docx
-rwx------   1 implied  STWZ\Domänen-Benutzer  359516 27 Jun 12:41 Ölstraße.docx
-rwx------   1 implied  STWZ\Domänen-Benutzer  439534 27 Jun 12:46 Paul-Metz-Straße.docx
-rwx------   1 implied  STWZ\Domänen-Benutzer  325621 27 Jun 12:38 Wiesenstraße.docx
drwxr-xr-x@ 15 implied  STWZ\Domänen-Benutzer     480 27 Jun 12:50 fertig
Mac-Studio-von-implied:~ implied$

 

[Marcel Bresink]

In den beschriebenen Fällen gibt es Probleme mit dem Kopieren von Erweiterten Attributen. Diese werden von SMB und NTFS prinzipiell unterstützt, aber es gibt Unterschiede im Detail. Es kann zum Beispiel sein, dass ein Attribut verwendet wird, das der Windows-Server als "verboten" ablehnt, es könnte sein, dass macOS ein Attribut per SMB falsch umsetzt, oder es könnte sein, dass der Windows-Server zu alt ist.

Für mich wäre interessant, die Ausgabe von

xattr -l -x "/Users/implied/Desktop/Archiv - bereits auf Marketing kopiert/KV-Schraenke/2022/Bilder fertige KV-Schraenke/Thumbs.db"

zu sehen. Wenn man als Kopierbefehl

cp -R -X

verwendet, werden die Erweiterten Attribute nicht mitkopiert.

 

[implied]

Öööööh, ok? Das ist interessant, denn die "Thumbs.db" sehe ich über den Finder gar nicht....Check, die ist unsichtbar.
Interessant: fertige ich eine Finder-Kopie von dem Ordner an, werden die vormals unsichtbaren thumbs.db in dem Duplikat sichtbar, keine Ahnung , warum.

Das Terminal wirft aus:

encryptable:
00000000

Ach schau an, im screenshot sieht man, was er letzendlich kopiert hat an Daten. Es wurden also Unterordner angelegt, es wurden Daten vollständig in 2 der Unterordner kopiert, ausgestiegen ist er dann bei der "Thumbs.db", richtig? Die steht auch drin mit 0kb.



hier screenshot vom Ursprungsordner "KV-Schraenke"

 

[Marcel Bresink]

Ja, das ist ein altes Kompatibilitätsproblem zwischen Windows und anderen Betriebssystemen.

Der Windows Explorer legt Vorschau-Cache-Datenbanken für Ordner, die Bilder enthalten, in versteckten Dateien mit dem Namen "Thumbs.db" an. Dabei wird unter anderem ein Erweitertes Attribut mit dem Namen "encryptable" verwendet. In NTFS wird das in einem Alternate Data Stream unter dem Namen "Thumbs.db:encryptable:$DATA" gespeichert. So ein ADS ist in etwa das, was im klassischen Mac OS "Fork" genannt wurde.

Es kann sein, dass der Server ein Einschleusen "fremder" Thumbs.db-Kopien, bzw. deren ADS-Daten absichtlich verhindert, denn das gilt als Sicherheitsrisiko. Die Lösung wäre, diese Dateien vor dem Zurückkopieren zu entfernen. (Möglicherweise gibt es aber noch weitere Probleme.)

 

[implied]

Geilo....Alle im Ordner (also in dem Duplikat, was ich vorsichtshalber mal vorher anlegte) befindlichen "thumbs.db" rausgelöscht, und er kopiert einwandfrei (per Terminal als auch per Finder)
Chacka, Ihr seid Klasse