ich habe ein Zugriffsrechte Problem mit dem lokalen Syncstore.
Der Syncstore liegt auf einem iMac mit 10.6.8 in einer Ordnerfreigabe. Zugegriffen wird mit einem iMac 10.8 und einem MacBook Pro 10.8 auf den Syncstore.
Wenn ich darauf zugreifen möchte kommt obige Meldung. Gehe ich dann in die Einstellungen/Sync/ Speicherort bearbeiten und wähle dort den gleichen Sync Store aus, klappt es wieder von dem Rechner ohne Probleme.
Beende ich dann Devonthink Pro Office, syncronisiert er wie gewünscht wieder. Gehe ich danach an den anderen Mac, bekomme ich wieder das obige Problem. Dies lässt sich wieder beheben in dem ich den SyncStore wieder auswähle.
Schließe ich dann auch dem Mac, geht’s bei dem anderen auch wieder nicht und ich muss erst wieder den SyncStore neuauswählen.
Die Freigabe auf dem Syncstore steht jetzt auch schon auf “Everyone - Lesen/Schreiben” und wurde auf Unterordner übertragen.
Mit dem Finder klappt der Zugriff auch ohne Probleme und nachdem der SyncStore neu zugewiesen wird klappt es ja auch, ich gehe deshalb nicht von Zugriffsproblemen im Netzwerk aus.
Habt ihr dafür eine Lösung ? oder Ideen ? oder bekannter Bug an dem gearbeitet wird ?
Ich konnte leider trotz Suche keine Lösung finden.
Das ist meines Wissens bisher der erste Bericht in dieser Art. Wird denn auf allen Rechnern derselbe Benutzeraccount bzw. mit denselben Rechten verwendet? Sind denn eventuell in der Konsole (s. Programme > Dienstprogramme > Konsole.app > Alle Meldungen) irgendwelche Meldungen während der Synchronisierung zu finden?
Auf allen Rechnern wird der gleiche Benutzer mit den gleichen Rechten benutzt.
Auch Lesen/Schreiben für Everyone ändert da nichts dran (inkl. Unterordner). In der Konsole taucht komischerweise nicht ein Eintrag auf, während dem Sync
Befindet sich der freigegebene Ordner auf einem separaten Volume? Dann wäre es evtl. einen Versuch wert, den Eigentümer zu ignorieren (s. Info-Fenster des Finders).
Ich bezog mich natürlich nur auf unser Forum & Ticket-System
Denn warum manche Anwender Probleme in einem anderen Forum posten, obwohl unser Forum ein deutschsprachiges Board bietet und auch noch leicht per Hilfe-Menü erreichbar ist, bleibt mir doch ein Rätsel.
Jedenfalls habe ich das Problem weitergeleitet, der zuständige Entwickler ist aber gerade im Urlaub.
Die wahrscheinlichste Ursache ist wohl, dass das Netzwerkvolume, d.h. der freigegebene Ordner, noch während der Synchronisierung ausgeworfen wurde. Dadurch schreibt eine noch aktive Synchronisation Dateien mitunter an den falschen Ort, beim nächsten mounten des Netzwerkvolumes ändert sich dessen Pfad und der Sync Store muss deswegen erneut in den Voreinstellungen ausgewählt werden.
Da nur zwei Rechner miteinander synchronisiert werden sollen, wäre aber vielleicht sowieso die effektivste Lösung, diese direkt miteinander zu synchronisieren.
Ich synchronisiere jetzt direkt, müssen zwar beide an sein aber das läuft problemlos.
Ausgeworfen wird das Volume nur wenn der Rechner ausgeschaltet wird, es wird dann aber bei der Anmeldung automatisch gemountet, hat also immer den gleichen Namen.
In der Konsole ist auch nichts zu finden das in der Zeit des Syncs das Volume ausgeworfen wird.
Also schon eine merkwürdige Sache.
Praktisch gewesen wäre eben der Sync auf dem Freigegeben Ordner des iMacs, der läuft hier auch als Mediaserver für Musik und Video und läuft eh 24/7
Ich habe diese Meldung ebenfalls ständig. Der Sync Store befindet sich auf einem NAS, Zugriff entweder direkt im Netzwerk oder per VPN. Möchte sich DT syncen, während das NAS nicht gemountet ist, kommt diese Meldung. soweit verständlich.
Wird das NAS unmounted, während DT synct (oder bricht die VPN-Verbindung weg, während er synct), so stürzt DT ab.
davon würde ich nicht ausgehen, denn auf den Stick zu schreiben, das hat zunächst Mal funktioniert.
Das spätere Aktualisieren des Sync-stores auf dem Stick - vom gleichen Rechner aus - gab die Fehlermeldung.
Sind denn andere Formatierungen einfacher zu händeln?
Ideal ist normalerweise HFS+ oder UFS, da diese Dateisysteme alle Mac-Eigenheiten unterstützen, aber bei der Synchronisierung sollte das eigentlich nicht nötig sein.
Falls es ein Problem mit den Zugriffsrechten sein sollte, müsste die Aktivierung der Option “Eigentümer auf diesem Volume ignorieren” (s. Finder) das Problem beseitigen.
Eine andere Möglichkeit ist, dass der Sync einmal ausgeführt wurde, während der USB-Stick gar nicht eingesteckt war. Anschließend ist der Pfad des Sync Stores verändert und das kann mitunter zu solchen Problemen. Das nächste Release wird dieses Problem korrigieren.
wir sind auch von dem Problem betroffen. Der Fehler hängt u.a. damit zusammen, dass DevonThink beim Zugriffsversuch auf einen SyncStore (bei uns auf einem Windows Share) einen leeren Ordner mit dem Namen des Shares unter /Volumes/ anlegt, wenn das Share nicht gemountet ist. Mac OS X legt dann beim späteren Mounten einen Alias an, unter dem DevonThink den SyncStore nicht erreicht.
[b]Habe vom Support folgende Antwort bekommen:
“Thanks for the report. This should be fixed in the next release.”[/b]
Wir haben uns ein kleines AppleScript geschrieben, das den etwaigen, leeren Ordner unter /Volumes/ löscht, bevor das Share gemountet wird. Damit läuft alles sauber.
Anbei noch mein Fehlerbericht an den Support:
DevonThink Pro Office 2.6.1
Mac OS X 10.8.4
Samba Share on Windows Server 2012 Data Center Edition
Steps to reproduce issue:
Don’t have DevonThink started
Say e.g. you have a smb share called “devonshare”.
mount the smb share
You should see the mounted “devonshare” under “/Volumes/”
Start DevonThink and create a new syncstore on the share “devonshare”
Sync your database to the syncstore
Now unmount the share “devonshare” (You should see that it disappeared from “/Volumes”
Now try to sync your database again to the syncstore (which is now unavailable because the share has been unmounted) and you will get an error
Under “/Volumes” you now see a folder called “devonshare” that has been created by DevonThink. (maybe you guys try to force a lock key or something else at that time and that created the folder)
Try to sync your database and you will still get the error
Re-Mount the “DevonShare” result in another entry under “/Volumes/” called “Devonshare-1”.
Now you are trapped and trying to sync your database will always give you the error
Conclusion:
Everyone that has a syncstore on a share runs into the described issue, if he has e.g. forgotten to mound the share where the syncstore is located and then tries to sync the database against the syncstore.
Our workaround at this time is:
Unmount the share. Delete every folder from /Volumes/ that is named like the share. Re-mount the share. Start DevonThink. Successfully sync to the syncstore.
Solution:
Before syncing to a syncstore on a smb share you must check if the share exists but while doing this you must ensure that no folder will be created under “/Volumes/” if the share is not mounted.
