File-Server Zugriff

[Gast test456]

Moin,

 

wir haben alte File-Server (2008R2/2012R2) durch einen 2019 ersetzt, Copy Jobs per robocopy. In unserer Umgebung gibt es MACs, das Apple mit SMB nicht immer klar kommt ist bekannt. Zudem sind die MACs schon einige Jahre alt, keine Updates mehr. Beste Vorraussetzungen für Support, das Projekt für neue MACs und Vereinheitlichung liegt durch Corona auf Eis. Berechtigt auf den File-Server und den entsprechenden Share ist eine Gruppe, sowohl NTFS als auch Freigabeberechtigungen sind auf Ändern eingestellt, Eigentümer ist die lokale Administratorengruppe.

User speichern ein PDF oder Excel und öffnen dieses und nehmen Änderungen am Dokument vor und wollen dieses unter dem gleichen Namen speichern. Für mich ein klarer Fall, Ändern wird durchgeführt. Auf dem MAC kommt der Fehler im Finder, Pendant zum Windows Explorer: Objekt kann nicht ersetzt werden, weil unsichtbar. Das ursprüngliche Dokument vor gemachter Änderung verschwindet, es wurde gelöscht. Das habe ich auf dem File-Server geprüft. Die Dateien enthalten auch keine . am Anfang, so dass macOS meinen könnte es wäre eine Systemdatei.

Unser Dienstleister hat über das Terminal bereits einen Befehl abgesetzt, sodass alle Dateien angezeigt werden und diesen neugestartet. Das brachte aber nichts. Ich habe mal nur um zu klären ob es ein Berechtigungsproblem ist, sowohl die NTFS als auch Freigabeberechtigungen für diese Gruppe auf Vollzugriff gestellt.

defaults write com.apple.finder AppleShowAllFiles -boolean true;killall Finder

 

[charmanta]

vor 2 Minuten schrieb Gast test456:

as Apple mit SMB nicht immer klar kommt ist bekannt

Andersrum, SMB unterstützt nicht alles was ein Mac kann

vor 3 Minuten schrieb Gast test456:

User speichern ein PDF oder Excel und öffnen dieses und nehmen Änderungen am Dokument vor und wollen dieses unter dem gleichen Namen speichern.

Adobe und M$ Produkte legen eine temporäre Datei auf dem Server an und ersetzen das Ziel dann, wenn die Temp-Datei komplett übertragen wurde. Nur harmonieren diese Temp-Namen nicht mit 0815-SMB Shares

vor 4 Minuten schrieb Gast test456:

Das brachte aber nichts

Korrekt. Vor allem ist der "defaults" Befehl einer auf dem Mac. Dein DL hat keine Ahnung von Mac Integration, sorry

Es klingt für mich nach einem Feintuning am SMB2 ...

Grundsätzlich werden die Macs an so einer Büchse aber immer kastriert laufen, da die nicht alles verarbeiten können was das Apple SMB so darstellen kann ....

[Gast test456]

Wie ich deinem Beitrag entnehme, liegt das Problem bei Microsoft. So weit ich denken kann gab es bei den File-Server Zugriffen seit jeher Probleme. Entweder sind angeblich Sitzungen offen, die am MAC längst nicht mehr geöffnet sind. Das zwei große Unternehmen wie Apple und Microsoft nicht in der Lage sind bzw. es wollen das Sie miteinander klar kommen ist schon bescheiden. 

Was verstehst du unter einem 0815 SMB, ist das eine Anpassung auf dem iMAC oder dem File-Server? Bisher konnte ich deinem Beitrag entnehmen: Apple ist besser und unser Dienstleister ist in der Pflicht

[tkreutz2]

Das Problem liegt an einer schlechten Umsetzung von SMB2 von Haus aus bei einigen Betriebssystemen. Daher gibt es ja eine Reihe von Third-Party-Produkten zu dem Thema. (Tools)

 

Bearbeitet 23. Juli 2020 von tkreutz2

[charmanta]

vor 13 Stunden schrieb Gast test456:

Was verstehst du unter einem 0815 SMB, ist das eine Anpassung auf dem iMAC oder dem File-Server?

ein nicht für diesen Zugriff konfiguriertes SMB macht da Stress ... SMB1 geht überhaupt nicht mehr vernünftig. Für eine echte volle Implementierung gibt es kommerzielle Lösungen (@tkreutz2 Du warst präziser und schneller ) wie zb Helios oder Xinet.

vor 14 Stunden schrieb Gast test456:

Bisher konnte ich deinem Beitrag entnehmen: Apple ist besser und unser Dienstleister ist in der Pflicht

Apple ist anders und ganz viele Win Supporter unterschätzen völlig die Besonderheiten des OS wie zb die vielen Unicode Darstellungen oder das Verhalten auf einem Server. "Das sind ja bloss PCs mit nem Apfel drauf" ist einfach Unsinn, schon immer gewesen Die Win Protokolle sind vergleichsweise einfach.

Ich meine zu erinnern, dass NFS stabiler ist als schlecht konfiguriertes SMB2 ...  Auf jeden Fall muss der Dienstleister ran, nicht Du als Win Admin 1st Lvl Das ist was für 3rd Lvl

[Gast test456]

Unser Dienstleister meldete zurück, ich sollte mal auf einem 2019er Server SMB1 aktivieren. Gesagt, getan da bin ich mal gespannt. SMB1 und SMB2 laufen jetzt parallel

Besonderheit in Zusammenspiel mit MAC-Clients ist, diese können Pfade länger als 255 erstellen, auch hatte ich schon File mit Tilde oder Trademark und das geht dann nur über Konsole \\?\ usw. zu löschen. Ich als lokaler Administrator kann die Dateien dann weder löschen noch Berechtigungen vergeben bzw. Eigentümerschaft übernehmen. Selbst nach nem Robocopy nach der 7, Pfadtiefe festgestellt das alles darunter die Vererbung nicht geschluckt hat. Stufe drüber alles ok. Benamung ist redundant aber was soll man dazu sagen. Aufräumen und Stuktur reinbringen ist beim Kunden keine Zeit und kein Geld für ne Fachkraft die das übernimmt.

 

 

 

 

[Thanks-and-Goodbye]

vor 3 Minuten schrieb Gast test456:

Unser Dienstleister meldete zurück, ich sollte mal auf einem 2019er Server SMB1 aktivieren.

Autsch. Mit SMB 1.0 holst du dir deutliche Sicherheitslücken auf den Server.

vor 4 Minuten schrieb Gast test456:

Besonderheit in Zusammenspiel mit MAC-Clients ist, diese können Pfade länger als 255 erstellen

Das schafft man auch mit Windows Maschinen... Frag meine Anwender, geht ganz einfach.

Tipp: Totalcommander, 64bit Version und dann langsam von oben nach unten die Pfadnamen wieder einkürzen bis man unter 255 Zeichen kommt.

[Gast test456]

Thema kann als Gelöst angesehen werden, das Aktivieren von SMBv1 auf dem File-Server konnte das Problem lösen.