Word Dokumente können von mehreren Benutzerz geöffnet werden (AFP, OS X, Office 2011)

[ssta]

Moin,
ich stehe hier vor einem Problem...
Ein Beispiel:
User A öffnet ein Word Dokument, dieses Dokument ist nun für User B gesperrt. soweit alles gut.
Wenn User A das Dokument (per "cmd" + "s" oder "Datei" - "Speichern" ) zwischenspeichert, es aber weiter geöffnet lässt um weitere Änderungen zu machen, ist der Schreibschutz weg.
Jetzt kann User B das selbe Dokument öffnen.
Es Arbeiten nun also User A und User B im selben Dokument und machen Änderungen.
Der User, der das Dokument nun zuletzt speichert überschreibt dann das Dokument final und natürlich auch die Änderungen des anderen Users.


Bei AFP Shares von Mac Servern haben wir das Problem nicht.

Das Problem existiert auch bei PowerPoint Dokumenten, diese lassen sich direkt von mehrere Benutzern öffnen



Zu unserer Hard- und Software:
2x RS815RP+ im Synology High Availability. (DSM 6.0.1-7393 Update 1)
Freigaben über AFP
Clients 10.7 - 10.11 (Das Problem tritt bei allen auf)
Office Mac 2011 ( v 14.6.6)
Jeder Rechner verbindet sich natürlich mit einem eigenen Benutzer mit der Synology

Ist das Problem bekannt ?
LG

 

[ssta]

Kleines Update:
Ich hatte längeren Kontakt mit dem Support von Synology.

"We reproduced the problem successfully and developers needs some time to identify the cause. I'll keep you posted if there is any news.
Should you need any further information, please do not hesitate to contact us.
Best regards"

 

[Windwalker]

Kleines Update:
Ich hatte längeren Kontakt mit dem Support von Synology.

"We reproduced the problem successfully and developers needs some time to identify the cause. I'll keep you posted if there is any news.
Should you need any further information, please do not hesitate to contact us.
Best regards"

Hallo,

selbes Problem hier mit DSM 6.0.2-8451 Update 1 und MS Office 2016 für Mac. Die sollen das Problem mal ganz schnell beheben, das sind ja wohl Basics eines File-Servers.

Viele Grüße

 

[ssta]

Moin Windwalker,
der Bug in AFP ist bei uns ein kleines Desaster.
Schreib doch bitte auch mal den Support an und lass dir ein Ticket erstellen.
Wenn sich mehrere User melden geht der fix vielleicht schneller.
LG

 

[goetz]

Hallo,
@Windwalker
bitte keine Vollzitate und erst recht nicht wenn Du direkt antwortest.
Danke.

Gruß Götz

 

[Splurzgalonk]

Ich stoss das mal wieder an, da auch mit der aktuellsten DSM-Version das Locking bei mir nicht zuverlässig funktioniert.

2* DS 1815+, btrfs, SHA-Cluster: momentan alle User per AFP. Vormals AFP und SMB auf dieselben Shares und das ging gewaltig in die Hose. Wir haben Mac clients von 10.6 bis 10.12 und nur SMB ist ein no go. Nur AFP bot die kleineren Probleme und vor allem besseren speed (bis DSM 6.0.1) - jetzt auf DSM 6.0.2-8451 Update 4, aber dennoch unter AFP.

Nicht immer, aber doch hin und wieder sind offene Files nicht gelockt. Kann sein, dass sich das Problem damit verschärft, dass per Mail gesharte Links auf Dokumente jeweils einen eigenen Mountpoint haben. Snapshots habe ich inzwischen mal abgeschaltet, aber im Nachhinein kann ich bei gesharten Foldern die "advanced data integrity protection" nicht ausschalten. Das will ich dann mal noch testen.

Gibt es jemanden, der unter AFP ein konstantes File-Locking für Macs erlebt?

 

[ssta]

Update:
Der Bug wurde auch nach über 6 Monaten mit DSM 6.1 nicht gefixt.
Ich habe heute bei Synology ein neues Ticket geöffnet da nach dieser Mail:
"We reproduced the problem successfully and developers needs some time to identify the cause. I'll keep you posted if there is any news.
Should you need any further information, please do not hesitate to contact us.
Best regards"
nichts mehr passiert ist.
Ich kann das ganze wirklich nicht nachvollziehen...
Dokumente die doppelt geöffnet und bearbeitet werden können, das ist so ein heftiges NoGo für ein Nas wieso wird das nicht gefixt?
Wie soll man AFP so in einem Unternehmen einsetzten.

 

[Splurzgalonk]

In meinen Beobachtungen verschärft sich das Problem dann, wenn jemand links auf den Share per Mail an Kollegen verteilt. MacOS führt dann einen eigenen Mountpoint unter /volumes.
Wenn nun User 1 über den normal gemounteten Server geht und User 2 über den per Link gemounteten Folder, dann gibts schneller Probleme als wenn alle über den normalen gemounteten
Pfad gehen... Am hässlichsten ist es, wenn auf demselben Share per AFP und per SMB gearbeitet wird.

 

[ssta]

Wir Arbeiten (zum Glück, sonst wäre der Bug noch unerträglicher) nur per AFP auf verschiedenen Shares.
Allerdings arbeiten in Projektordnern gerne mal mehrere User an einem Dokument.
Das Problem ist, es wird nach dem "Zwischenspeichern" keine neue Temp-Datei erstellt und das Dokument nicht gelockt.
UserA öffnet ein Word-Datei und bearbeitet es, Temp wird erstellt und die Word-Datei ist für andere gelockt.
Wird dann über cmd+s zwischengespeichert, wird die Temp gelöscht, die Word-Datei aktualisiert allerdings keine neue Temp angelegt.
Ab dem Moment können 2 User im der selben Word-Datei arbeiten.
Wer dann als letzter speichert "gewinnt" der andere verliert alle vorgenommenen Änderungen.

Hast du eine Ticket über https://account.synology.com/support/support_form.php geöffnet ?
Du kannst dich gerne auf meine Tickets neu #1011924, alt #865270 berufen.

 

[Splurzgalonk]

Ok. Danke für die zusätzlichen Hints... ich habe mich auch bei Synology gemeldet. Hoffen wir, dass genügend Druck entsteht.

 

[ssta]

update:
Kernaussage vom Support:
"AFP wird von Apple selbst nicht mehr weiterentwickelt und ist auch bei uns nur noch zur Abwärtskompatibilität mit älteren OS X-Versionen vorhanden."
Großes Kino, nur bei Apple funktioniert AFP-Sharing wenigstens vernünftig.

 

[Splurzgalonk]

Der Upload-Speed von vielen kleinen Textdateien ist nach wie vor eine gnadenlose Trauershow.

Bei 500 Textfiles mit insgesamt 800kB erhalte ich knapp 20kb/sec. AFP ist immerhin Faktor 2 (!) schneller
als SMB. Und das ist bei diesen traurigen Speeds schon relevant.

Mit SFTP lade ich Dateien mit weit über 30MB/sec hoch.

 

[ssta]

Ich kann identische Geschwindigkeitsunterschiede feststellen.
Die Kommunikation mit Synology ist wirklich grauenhaft, ich könnte vor Wut platzen. Es wird auf kein Argument eingegangen und als Antwort kommt immer "nutzen Sie SMB".

 

[Splurzgalonk]

Nunja. Ich nehme mir immer wieder mal die Zeit, diese Problematiken (Speed issue bei kleinen Dateien und genereller Speed-Drop bei SMB für Mac) auf dem Feedback-Weg einzureichen. Hier die Faust im Sack zu ballen bringt nix. Darum los: feature requests schreiben, die deutschen Synology-Repräsentaten angehen... sonst geschieht hier nix.

Wir planen schon, alles auf SMB umzustellen, aber wenn ein langsames System dadurch um Faktor 2 langsamer wird, ist es schon ziemlich signifikant.

 

[till213]

* AFP ist in der Tat seitens Apple schon länger als "deprecated" eingestuft. "Offizielles" Netzwerkprotokoll unter macOS ist schon seit längerem SMB. AFP könnte schon mit dem nächsten macOS release komplett rausfallen. Die Tatsache, dass nun selbst die TimeMachine via SMB funktioniert, zeigt, dass Apple da jetzt Ernst macht (auch wenn Apple ironischerweise selbst keine Netzwerk-TimeMachines mehr herstellt). Aber ich wiederhole hier bloss, was im Forum eh schon jeder weiss Dass Synology daher nicht mehr gross Ressourcen in ihren serverseitigen AFP-stack steckt, ist aus wirtschaflichen Gründen daher nachvollziehbar.

* Hat sich mal wer überlegt, ob das Problem nicht client-seitig in AFP (also in macOS) stecken könnte?

* Tritt das Problem eigentlich auch mit "SMB only" Topologien auf? Einerseits sprach der OP von "Bei AFP Shares von Mac Servern haben wir das Problem nicht.", andererseits berichten andere, dass es gerade mit AFP nicht klappt (?) ("der Bug in AFP ist bei uns ein kleines Desaster.") - ja was denn nun?

* Hat das wer schon einmal mit Windows-Clients probiert, tritt dort daselbe Problem ebenfalls auf (mit SMB, versteht sich)?

* Und wenn ich sowas lese: "Das Problem ist, es wird nach dem "Zwischenspeichern" keine neue Temp-Datei erstellt und das Dokument nicht gelockt." - das wäre dann doch ein reines Applikationsproblem (Word), nicht? Es ist in der Tat so, dass eine Applikation explizit vom OS ein (exklusives) File Lock anfordern muss. Je nach Dateisystem wird das dann unterstützt oder eben nicht, und wenn dann noch Netzwerkprotokolle (SMB, APF) und verschiedene Dateisysteme auf beiden Enden sind (Ext4 vs Btrs vs HFS+ etc.), dann kann da so einiges schiefgehen. Viele Applikationen "behelfen" sich dann mit expliziten "Lock"-Dateien (z.B. .lock oder ähnlich) - was natürlich auch ein "hack" ist, da solche Dateien natürlich auf den diversen Clients "gecached" werden können, und es dann so ausschauen könnte, dass ein lock noch da ist, obwohl es bereits aufgehoben wurde (oder umgekehrt). Aber ich glaube ehrlich gesagt nicht, dass Office Word "tmp" Dateien für locking verwendet...

* Passiert dies auch mit anderen (abgesehen von Office) Applikationen, welche ein exklusives locking einsetzen?

 

[Splurzgalonk]

Dass Synology daher nicht mehr gross Ressourcen in ihren serverseitigen AFP-stack steckt, ist aus wirtschaflichen Gründen daher nachvollziehbar.

Mit dem kann ich leben, wenn sie dann aber endlich hinschauen und den Speed von SMB auf denselben Level wie das alte AFP heben. Der Speed ist für viele kleine Files sehr mager und AFP ist Faktor 2 schneller als SMB, auch mit deaktivierter Signierung clientseitig.

* Und wenn ich sowas lese: "Das Problem ist, es wird nach dem "Zwischenspeichern" keine neue Temp-Datei erstellt und das Dokument nicht gelockt." - das wäre dann doch ein reines Applikationsproblem (Word), nicht?

Die ganze Mickysoft und Adohweh-Suiten grenzen von Natur aus an Malware. Das stimmt. Nach wie vor schreiben die ja auch, dass ihre Applikationen NICHT direkt auf Netzwerkvolumes schreiben sollen. Damit ziehen sie sich aus der Verantwortung. Ich fürchte schon, dass die Applikationen mindestens einen signifikanten Anteil an der Problematik haben.

Nachdem es einen brutalen Speed-Drop gibt, wenn man bestimmte Dateitypen hochlädt (Txt, Word, JPG), scheint mir aber doch einiges ziemlich in den Schreibprozess zu fummeln. Da hat Synology einiges an Erklärung zu leisten. Lade ich nämlich die gleiche Menge (Anzahl, Bytes/file und Bytes total) Daten als nicht indizierbare binary chunks hoch, ist der Speed um mehr als Faktor 20 grösser. Also fummeln die schon irgendwie rein und auch wenn ich lange mit dem Support "diskutiert" habe, so gibt es kein Anzeichen davon, dass sie uns sagen können, was denn da genau so dazwischen funkt (und der Speed drop ist da, selbst wenn die CPU konstant unter 10% bleibt).

Mir scheint, da funkt irgend ein sehr langsamer Prozess dazwischen. Nicht die Indexierung, sondern mehr die Art, wie die einzelnen Prozesse die Daten weiter reichen. Inwiefern das einem Locking dazwischen funkt, kann ich nicht beurteilen, aber nachdenklich stimmt es mich schon.

 

[ssta]

zu "* AFP ist in der Tat…"
Apple kickt in Zukunft erstmal nur das AFP-Sharing und das auch nur unter APFS-Systemen.
Den Zugriff auf AFP Shares wird Apple noch lange unterstützen.

zu "Hat sich mal wer überlegt.."
Klar, trifft aber nicht zu. (dazu unten)

zu "Einerseits sprach der OP von…"
Da hast du etwas falsch verstanden. Ich versuch es mal etwas ergänzt.
"Bei AFP Shares von Mac Servern haben wir das Problem nicht." deswegen ist "der Bug im AFP(-Sharing von Synology-) bei uns ein kleines Desaster."

zu "Hat das wer schon einmal mit Windows-Clients probiert"
Natürlich ist da alles gut, ist dann aber auch ein anders OS und ein anderes Protokoll. ;-)

Das Problem existiert auch bei Powerpoint und excel, hier muss nichtmal zwischengespeichert werden.
Die Dokumente können direkt von mehreren Usern geöffnet werden (auch nur bei Synology AFP-Shares)

Es liegt definitiv an Synology bzw. der netatalk Konfig.

Bei uns lief auf dem OS X Server unter alles Programmen der Filelock wunderbar, der Fehler tauchte erst bei dem Umzug auf die Synologys auf.
An den Clients wurde nichts verändert.
Bei allen OS X Versionen (ich habe 10.7 bis 10.12 getestet) ist folgendes Bild identisch:
-Client greift per AFP auf Share von einem OS X 10.10.5 Server zu: File Lock funktioniert
-Client greift per AFP auf Share von einem OS X 10.12.4 Client zu: File Lock funktioniert
-Client greift per AFP auf Share von einem Ubuntu Server mit netatalk 3.1.10 zu: File Lock funktioniert
-Client greift per AFP auf Share von Synology zu: File Lock funktioniert nicht

Synology verwendet für AFP immer noch netatalk 3.1.8 und nicht das aktuelle 3.1.10, evtl liegt der Fehler dort.

Nachdem Ich dem Support von den vier Situationen oben Screencasts geschickt habe, kam jetzt folgende Antwort:

Die Entwickler haben es noch mal aufgenommen und überprüfen es, bisher ist die Ursache nicht bekannt, daher kann ich nicht sagen, wann es behoben ist.