Das Problem ist wohl bekannt; eine Lösung habe ich nicht gefunden.

Wenn ich (MBP5,5, Sierra) mit Pages Dokumente von einem Yosemite-server (macmini late 2014, Zugang über afp://) bearbeiten möchte, kommt bisweilen die im Titel beschriebene Meldung. Für mich gibt es keinen offensichtlichen Grund, warum das passiert; somit halte ich das für einen bug. Der workaround (Apple-A und dann alles in ein Apple-N) ist extrem lästig und schafft auch kein Vertrauen
Kennt einer von Euch das Problem und/oder weiß Abhilfe?

Das ist aber kein Bug, das ist einfach der Stand der Technik von Apples Dateisystem und Time Machine:

Time Machine funktioniert nicht bei entfernt gemounteten Volumes (AFP oder Samba ist egal), und die Versionierung (das ist ja das „automatische Sichern“) arbeitet de facto eben über Time Machine.

Du kannst nur hoffen, dass sich das mit Apples neuem Dateisystem nächstes Jahr ändert (keine Ahnung, ob das so sein wird).
Den Workaround verstehe ich nicht. Die Meldung ist ja kein Fehler im eigentlichen Sinne; sie weist Dich nur darauf hin, dass Du von diesem Pages-Dokument eben keine Versionen haben wirst, auf die Du zurückfallen kannst. Am manuellen Sichern mit Command-S hindert Dich doch niemand?

Oder meinst Du, Du machst das, um manuell Versionen zu erzeugen? Falls ja, ja, dann ist das eben lästig. (Ein Duplikat erstellen mit Command-Shift-S ginge natürlich genauso.)

Doch, doch, das ist meines Erachtens buggy. Command-S ist dann nicht mehr möglich. Manchmal geht auch shift-command-S nicht mehr und dann kommt diese Command-A, Command-C, Command-N, Command-V-Geschichte.
Ich werde das gleich im Büro aber noch einmal verifizieren.

Kann man diese Versionierung denn irgendwo abschalten? Ich google das jetzt mal

Ooops! Dann ist das ein anderes Problem als ich dachte, dieses Phänomen kenne ich nicht.

Kannst Du in solch einem Moment das entfernte Volume denn im Finder noch erreichen?
Selbst dann, wenn Du ein lokales Volume zum Sichern auswählst?

So, gerade getestet. Ich öffne mit Pages 6.0.5 (4052) drei Dokumente vom yosemite-server, die ich gestern erstellt habe. Ich mache "Fenster/'Alle Fenster zusammenführen", weil ich das in den Tabs schöner finde. Dann ändere in jeder Datei einen Buchstaben und ändere ihn wieder zurück. Mit Apfel-Tab gehe ich zu einem anderen Programm. Just in dem Augenblick blitzt dort, "wo Pages sein Fenster hat", die besagte Meldung auf, die mich veranlasst, mittels Apfel-Tab zu Pages zurückzukehren. Tatsächlich, im Fenster oben rechts neben dem Dateinamen steht in blau: "Nicht gesichert".
Jetzt kommt's: Bei Apple-S kommt :"Das Dokument "lkasdflkasl.pages" konnte nicht gesichert werden." Der Server ist ganz normal erreichbar.
"Sicher unter..." auf den server funktioniert.
Bin da weiter am suchen, denn mit der "Sichern unter...-Datei" passiert das (Problem bislang) nicht.

Ist das denn konstitutiv für das Problem?

Beim Einkreisen von Problemen ist es ja immer sinnvoll, die einfachstmöglichen Schritte zu finden, die das Problem reproduzieren. Zusätzliche Schritte verwirren nur, weil man nicht weiß, ob sie zu dem Problem beitragen.
Hatte das Dokument denn ursprünglich diesen etwas seltsamen Namen (lkasdflkasl.pages)?

Jetzt habe ich die drei Dokumente auf meinen Rechner verschoben, dort mit Pages 6.0.5 geöffnet und sie durch "Sichern unter..." wieder auf den server zurückgeschrieben. Dann Pages geschlossen, vom Server abgemeldet und wieder angemeldet und mit Pages 6.0.5 die 3 Dokumente vom Server geöffnet und einen Buchstaben geändert. Problem taucht NICHT auf. Das könnte also ein work-around sein. Nur, was läuft da falsch?

"Konstitutiv" kenne ich nicht , ich halte es auch nicht für wichtig/relevant für das Problem.

Nein, den Namen hatte ich geändert, weil ich den eigentlichen Namen nicht veröffentlichen wollte.

...So jetzt gerade blitzt im Hintergrund doch wieder die Meldung von Pages auf. Also war das, was ich im posting von 10:42 beschrieb wohl doch kein work-arount. Meldung in Pages gibt es bei zwei von den drei geöffneten Dateien. Da wird die dritte vielleicht nicht lange auf sich warten lassen.
Diese Scheisse ist halt ein/der Grund, weshalb ich darüber nachdenke, auf Sierra-server zu wechseln; natürlich teste ich zunächst mit Klon, ob das update sauber klappt, der server läuft und ob das Problem weg ist.

Ja was jetzt? Wenn es nicht relevant ist, ist es auch nicht konstitutiv … das ist ja mehr oder weniger synonym.

Wie auch immer: Wenn das nicht relevant ist mit den 3 Tabs, dann lass die doch fort und schaue, ob das Problem auch mit einem einzigen Dokument auftritt oder mit 3 Dokumenten in getrennten Fenstern.

Ich meinte, dass ich die Bedeutung des Wortes "konstitutiv" nicht kenne

Ich habe aktuell 3 Dokumente in Tabs in Pages offen. 10:48 motzte Pages zwei davon an, das dritte immer noch nicht Ich werde diese jetzt schliessen und neu öffnen und in getrennten Fenstern halten. (Oder ich rufe Apple an, dass die das machen )

Einen Schritt weiter: 3 Dokumente in getrennten Fenster liessen 10 Minuten lang das Problem nicht auftauchen. Dann "Alle Fenster zusammenführen" und sofort meldet ein Dokument das Problem...
Ist jedoch (noch) nicht reproduzierbar, gerade noch einmal versucht und das Problem tritt jedenfalls nicht sofort auf.

Wozu gibt’s denn Lexikon in macOS?

Nachschlagen, was das heißt, geht weit schneller als zu bekunden, dass man es nicht weiß, und ist zudem weniger peinlich.

Ja, mein Verdacht wäre ja auch, dass es daran liegt, weil ich einerseits Dein Problem nicht kenne (obwohl ich auch Pages mit Dokumenten vom Server benutze) und andererseits aber auch nie diese Zusammenführ-Funktion verwende (weil ich Tabs nicht ausstehen kann).

Wenn es daran liegen sollte, wäre das natürlich klar ein Pages-Bug.

Welchen server und welchen client benutzt Du?

"Konstitutiv (lat. für „festsetzend, bestimmend“) ist ein Begriff aus der juristischen Fachsprache für Handlungen, durch die eine Rechtswirkung eintritt. Dabei kann es sich um rechtsbegründende, rechtsaufhebende oder rechtsgestaltende Wirkungen handeln."

Würde mich nicht wundern, wenn das ein Bug in Pages ist.

Hilft Dir jetzt vermutlich nicht: Bei gleichem Vorgehen mit einer älteren TimeCapsule habe ich dieses Problem nicht. (sehr wohl die Meldung, dass keine Versionen gespeichert werden - aber das ist ja normal, wenn auch blöd weil alles von Apple )

Evtl. glaubt Pages nur, dass es mit speziellen Dingen arbeiten könnte (Versionen oder was auch immer), dann klappt das aber nicht, weil der Server irgendetwas nicht versteht oder tut - Dann bleibt irgendein Zugriffs-Handle hängen und Pages hat sich selbst ausgesperrt.

Workaround könnte also sein: Datei lokal kopieren, dort bearbeiten und speichern, anschließend zurück auf den Server kopieren. (nein, das ist nicht schön, kaputte Dateien sind aber noch viel blöder )

So, unser server hat sich warm gelaufen Problem kann ich gerade nicht mehr reproduzieren/forcieren. Ich habe zwischendurch mal Pages mit shift gestartet. Hatte ich irgendwo gelesen. Passiert da was anderes, als wenn ich Pages ohne shift drücken starte?

Beides 10.11.
Das ist aber nicht aus Lexikon von macOS. Und es stimmt auch nicht; der Begriff wird nicht nur in der juristischen Fachsprache verwendet, sondern auch allgemeinsprachlich. Was ist das denn für eine seltsame Quelle?

Lexikon von macOS sagt (identisch mit Duden-Fremdwörterbuch und Duden-Deutsches Universalwörterbuch):
Rechtschreibduden:Ich habe den Begriff verwendet im Sinne von ausschlaggebend – eine Einstellung, ohne die das Problem nicht auftritt.

Die seltsame Quelle war irgendwas mit "edia" am Schluss

Aber kurz zurück: Mein Problem zeigt sich nicht mehr. Scheisse! Ich weiß nicht, woran es liegt. Habe ich vielleicht was repariert, dass ich Pages einmal mit "shift" gestartet habe?

Kein Problem mehr? So ein Mist!

Deswegen Mist, weil ich nicht weiß, warum es weg ist Natürlich in der Regel besser, als ein Problem zu haben.

Schon klar. Aber bis auf Weiteres würde ich an Deiner Stelle einfach hoffen, dass der Trick mit der Shift-Taste ggf. auch beim nächsten Mal hilft.

Nachtrag: Das Problem ist wieder aufgetaucht. Falls also jemand noch einen anderen Gedanken hat, immer her damit.

Ich habe seit Neuestem das gleiche Problem. Das ist richtig nervig.

@virk: Hast du mittlerweile das Problem lösen können?

Server 5.2 (Build 16S1195)
macOS 10.12.3 (Build 16D32)

@coldplayer: Nein, das Problem konnte ich noch nicht lösen. Es ist bei mir zur Zeit weniger aktuell, da ich kaum Pages-Dokumente zur Zeit bearbeite.

Wir haben das Problem auch - allerdings nicht nur bei Pages sondern auch bei Vorschau! (ebenfalls bei dem freien Editor Smultron) Speichert man eine Datei z. B. direkt durch hineinziehen einer Mailanlage in ein Finderfenster auf einem AFP Serverlaufwerk, kann man dieses z. B. PDF oder jpg nicht mehr in Vorschau bearbeiten. Vorschau meldet den Fehler "konnte nicht automatisch gesichert werden. " bzw. "konnte nicht gesichert werden. " und bietet ignorieren-abbrechen-duplizieren an... Das tritt nur bei bestimmten Vorgängen (wie dem heineinziehen aus einer Mail) auf. Eine PDF vom Desktop kann man auf ein Serverlaufwerk ziehen und auch mit Vorschau bearbeiten. Wenn eine Datei einmal diese "verbogenen Berechtigungen" hatte, kann man sie so oft duplizieren oder von Lokal zum Netz hin und her schieben, ohne dass sich daran etwas ändert.

Server Version 10.11.5, Client 10.12.3 (16D32) -

Bei Verbindung via SMB (testweise einmal aktivier) tritt der Fehler nicht auf. Allerdings ist SMB vor allem bei Spotlight und kopieren grösserer Datenmengen so untertäglich langsam...wie halt auch Windows so ist

Was hat Apple da wieder für einen Unsinn gebaut? Ich vermute, es kam mit dem letzten Update des Clienten auf 10.12.3 (16D32).

Nachtrag nach Serverupdate auf 10.11.6 (15G1217) ist der Fehler immer noch da.

Ich glaube nicht, dass es an der Server-Version von MacOS liegt. Ich habe das gleiche Problem mit einem fileserver von WD und einem Sierra-Client.

Ich gehe auch davon aus, dass es am Clienten liegt. Allerdings scheint es auch von der Serverversion abzuhängen. Wir haben parallel noch einen Server mit 10.6 laufen - da gibt es mit AFP keine Probleme!

Nachtrag - die Ursache liegt in den erweiterten Attributen von Apple. Eine PDF, direkt aus Apple Mail in ein Serverlaufwerk gezogen lässt sich in Vorschau nicht mehr ändern/sichern (gibt den o. g. Fehler) - nennen wie sie jetzt "a.pdf". Zieht man die Mail selbst zuerst auf den Desktop, öffnet diese Mail dann und zieht daraus ein PDF auf das Serverlaufwerk, ist ein Bearbeiten mit Vorschau möglich "b.pdf".

a.pdf wird auch nicht auf einer AFP Freigabe bearbeitbar, wenn man es über andere Laufwerke oder USB Sticks zieht, kann aber immer auf einem lokalen Laufwerk oder eine SMB Freigabe bearbeitet werden!?!...

Ich habe mir die erweiterten Attribute von Apple einmal angesehen:
Kais-iMac:Test $ ls -al@
total 1936
drwxr-xr-x 1 kai staff 264 13 Mär 11:41 .
drwx------ 1 kai staff 1112 13 Mär 11:41 ..
-rw-r--r--@ 1 kai staff 488954 13 Mär 10:00 a.pdf
com.apple.metadata:com_apple_mail_dateReceived 50
com.apple.metadata:com_apple_mail_dateSent 50
com.apple.metadata:com_apple_mail_isRemoteAttachment 42
com.apple.metadata:kMDItemWhereFroms 211
com.apple.metadata:kMDLabel_icw3m3piucq2idemrpo3pcaifu 1097
com.apple.quarantine 19
-rw-r--r--@ 1 kai staff 488954 13 Mär 11:41 b.pdf
com.apple.metadata:com_apple_mail_dateReceived 50
com.apple.metadata:com_apple_mail_dateSent 50
com.apple.metadata:com_apple_mail_isRemoteAttachment 42
com.apple.metadata:kMDItemWhereFroms 211
com.apple.metadata:kMDLabel_icw3m3piucq2idemrpo3pcaifu 329
com.apple.quarantine 19
_________________________
Der einzige unterschied ist die vorletzte Zeile "com.apple.metadata:kMDLabel..."

Durch Eingabe von:
Kais-iMac:Test kaiuwepatz$ xattr -c a.pdf

Habe ich alle erweiterten Attribute gelöscht und siehe da - Vorschau kann diese Dateien wieder bearbeiten...

Jetzt weiss ich mir zwar in Einzelfällen zu helfen und wenn Apple nicht bald mit einem Update um die Ecke kommt, lass ich diesen Befehl jede Nacht rekursiv über die Serverplatten rumpeln

AFP wird von Apple doch gar nicht mehr unterstützt, dachte ich?

Nachtrag zu vorherigem Thread:
- Der Fehler tritt erst bei Clienten mit Sierra und Server 5.2 auf (wie vermutet)
- Das verantwotliche Attribut heisst com.apple.metadata:kMDLabel_....ab hier steht immer je nach Client anderes... Wenn man das entfernt, lassen sich Dateien wieder bearbeiten.
Wenn man einen aktuellen Apple Server verwendet, hat man (noch) die Wahl und kann bei diesem SMB komplett deaktivieren - die Clients nehmen dann AFP.

Vorteile:

- Spotlight Suchen auf dem Server funktionieren wieder so, wie auf dem lokalen Laufwerk praktisch unverzögert beim Eintippen, mit SMB hat man 5 - 50 Sekunden Wartezeit, bis sich eine Suchliste aufbaut

- Kopieren von Dateien und Verzeichniszugriffe, vor allem via VPN in einem Bruchteil der Zeit

- Datendurchsatz bei grossen Dateien konstant > 110MByte/s, bei SMB nur gelegentlich mal knapp über 90MByte/s

- Einige Programme (dazu gehört paradoxerweise auch Microsofts Excel 2011) produzieren bei SMB nicht nachvollziehbare Abstürze bei Netzwerkdateizugriffen. Das Problem ist bei vielen Programmen bekannt, die Foren sind voll davon

Mit SMB hat es Apple geschafft, endlich genauso schlecht wie Windows zu werden! Datendurchsatz mies, Netzwerkumgebung genauso lahm und unzuverlässig wie man es seit Windows NT bereits kennt... Ist schon mal aufgefallen, dass Apple bei Timemaschine Backups intern immer noch das AFP Protokoll verwendet, auch wenn SMB zur Verfügung stünde?

"Konstitutiv oder nicht. Ist das nicht sch…egal?" Ich fand die Bemerkung ein bisschen moralistisch.
Aber nur weiter im Text.

Mit dem letzten Update auf 10.12.4 (16E195) auf Clientseite scheint der Fehler behoben... Oder gibt es noch vergleichbare Beobachtungen?