synOCR SynOCR - synOCR-Anwendungs-User in regulären Synology-User ändern

[Jerome]

Hallo zusammen,

da SynOCR Dateien als User "synOCR" in einem Ordner auf meinem NAS ablegt, welcher als Team-Ordner im Synology Drive angebunden ist,
tauchen neue Dateien weder in der Weboberfläche noch in der iOS-App unter "vor kurzem" auf.

Der Besitzer der Dateien ist also der User "synOCR".

Ist es möglich diesen, innerhalb von SynOCR, gegen einen regulären Synology-User zu tauschen oder
alternativ den Besitzer nach der Verarbeitung automatisch zu ändern?

Beste Grüße!

 

[plang.pl]

Du könntest ein Script im Aufgabenplaner anlegen (oder das synOCR Script bearbeiten), dass den Besitzer ändert (Stichwort "chown").

 

[geimist]

Zum Grundverständnis:
Die Ausgabedateien sind nicht die veränderten Eingabedateien, sondern (von OCRmyPDF) neu erstellte Dateien. Entsprechend müssen die Rechte neu gesetzt werden. Standardmäßig werden die Rechte der Quelldatei auf die Zieldatei übertragen (ob Linux Standardberechtigungen oder ACL). Wird synOCR nicht über den User root gestartet, gibt es Einschränkungen, was die Rechtevergabe betrifft. Dadurch wird dann in deinem Fall nur der Paketuser verwendet.

Workaround:
Abhilfe sollte es also schaffen, synOCR über den Aufgabenplaner mit dem User root zu starten. In den letzten Versionen habe ich eine Autostartroutine in das Startskript implementiert, sodass synOCR die Quellordner automatisch überwacht, sobald das Paket läuft und die inotify-tools installiert sind. Um in diesem Fall den ausführenden User zu ändern, muss das Paket zunächst gestoppt und anschließend als root neu gestartet werden.

Hier ein Beispiel, wie es im Aufgabenplaner aussehen könnte:

if [ $(ps aux | grep -v "grep" | grep -E "inotifywait.*--fromfile.*inotify.list" | awk -F' ' '{print $1}') != root ] && [ $(ps aux | grep -v "grep" | grep -E "inotifywait.*--fromfile.*inotify.list" | awk -F' ' '{print $2}') ]; then
    # stop / (re-)start monitoring:
    echo "läuft nicht unter root - starte neu ..."
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh stop
    wait
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh start
else
    # start monitoring:
    echo "starte neu ..."
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh start
fi

 

[Jerome]

Vielen Dank für den Tipp!

Ich habe es gerade über die Konsole ausprobiert:

sudo chown -R max volume1/Max/*

Funktioniert einwandfrei mit Passworteingabe.

Wenn ich diese Zeile in eine changeOwner.sh-Datei packe und via root oder max (Admin) als Task ausführe, ist das Ergebnis "unterbrochen (127)".
Auch das Entfernen von sudo führt zum selben Ergebnis.

Ich denke das ich hier noch was falsch mache.

Offensichtlich werden außerdem nachträgliche Besitzänderungen an Dateien, innerhalb von Drive, nicht berücksichtigt: Es gibt also keine "neuen" Dateien unter dem Reiter "Vor kurzem" (unter Home) in der Drive iOS-App.

Daher gehe ich davon aus, dass ich das Script innerhalb von synOCR ändern müsste.

Kennst du dich da zufällig aus?

Sprich:

- Welche Datei(en) ist/wären das?
- An wie vielen Stellen muss der User geändert werden?

Grüße

Edit: Der letzte Post von geimist und mein Post haben sich überschnitten ...

 

[Jerome]

Zum Grundverständnis:
Die Ausgabedateien sind nicht die veränderten Eingabedateien, sondern (von OCRmyPDF) neu erstellte Dateien. Entsprechend müssen die Rechte neu gesetzt werden. Standardmäßig werden die Rechte der Quelldatei auf die Zieldatei übertragen (ob Linux Standardberechtigungen oder ACL). Wird synOCR nicht über den User root gestartet, gibt es Einschränkungen, was die Rechtevergabe betrifft. Dadurch wird dann in deinem Fall nur der Paketuser verwendet.

Workaround:
Abhilfe sollte es also schaffen, synOCR über den Aufgabenplaner mit dem User root zu starten. In den letzten Versionen habe ich eine Autostartroutine in das Startskript implementiert, sodass synOCR die Quellordner automatisch überwacht, sobald das Paket läuft und die inotify-tools installiert sind. Um in diesem Fall den ausführenden User zu ändern, muss das Paket zunächst gestoppt und anschließend als root neu gestartet werden.

Hier ein Beispiel, wie es im Aufgabenplaner aussehen könnte:

if [ $(ps aux | grep -v "grep" | grep -E "inotifywait.*--fromfile.*inotify.list" | awk -F' ' '{print $1}') != root ] && [ $(ps aux | grep -v "grep" | grep -E "inotifywait.*--fromfile.*inotify.list" | awk -F' ' '{print $2}') ]; then
    # stop / (re-)start monitoring:
    echo "läuft nicht unter root - starte neu ..."
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh stop
    wait
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh start
else
    # start monitoring:
    echo "starte neu ..."
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh start
fi

Hi geimist,

vielen Dank für den Tipp und die ausführliche Erläuterung, das probiere ich aus!
Deine letzte Version (mit Ordnerüberwachung via inotify-tools) habe ich drauf.

Grüße

Jérôme

 

[geimist]

Wenn ich diese Zeile in eine changeOwner.sh-Datei packe und via root oder max (Admin) als Task ausführe, ist das Ergebnis "unterbrochen (127)".

Das Ergebnis kannst du dir ja ausgeben lassen, sofern im Aufgabenplaner ein Ordner für die Log-Files definiert wurde.
Nicht vergessen, deine changeOwner.sh auch ausführbar zu machen:
chmod +x changeOwner.sh
Deine Zeile kannst du aber viel einfacher direkt im Aufgabenplaner laufen lassen.

 

[Jerome]

Vielen Dank, sehr hilfreich!

Den Code direkt im Aufgabenplaner auszuführen, macht definitiv Sinn.
Mittels Log-File in einem definierten Speicherort konnte ich jetzt auch genau sehen, was nicht funktioniert hat:

Der Ordner wurde nicht gefunden, da ich noch ein "/" vor das volume1 packen musste.

Funktioniert!

Eine Datei ausführbar zu machen, behalte ich mal im Hinterkopf!

 

[Jerome]

Zum Grundverständnis:
Die Ausgabedateien sind nicht die veränderten Eingabedateien, sondern (von OCRmyPDF) neu erstellte Dateien. Entsprechend müssen die Rechte neu gesetzt werden. Standardmäßig werden die Rechte der Quelldatei auf die Zieldatei übertragen (ob Linux Standardberechtigungen oder ACL). Wird synOCR nicht über den User root gestartet, gibt es Einschränkungen, was die Rechtevergabe betrifft. Dadurch wird dann in deinem Fall nur der Paketuser verwendet.

Workaround:
Abhilfe sollte es also schaffen, synOCR über den Aufgabenplaner mit dem User root zu starten. In den letzten Versionen habe ich eine Autostartroutine in das Startskript implementiert, sodass synOCR die Quellordner automatisch überwacht, sobald das Paket läuft und die inotify-tools installiert sind. Um in diesem Fall den ausführenden User zu ändern, muss das Paket zunächst gestoppt und anschließend als root neu gestartet werden.

Hier ein Beispiel, wie es im Aufgabenplaner aussehen könnte:

if [ $(ps aux | grep -v "grep" | grep -E "inotifywait.*--fromfile.*inotify.list" | awk -F' ' '{print $1}') != root ] && [ $(ps aux | grep -v "grep" | grep -E "inotifywait.*--fromfile.*inotify.list" | awk -F' ' '{print $2}') ]; then
    # stop / (re-)start monitoring:
    echo "läuft nicht unter root - starte neu ..."
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh stop
    wait
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh start
else
    # start monitoring:
    echo "starte neu ..."
    /usr/syno/synoman/webman/3rdparty/synOCR/synOCR-start.sh start
fi

Diesen Code in eine Aufgabe zu packen und als root auszuführen hat funktioniert! Vielen Dank!
Wenn ich jetzt im, von synOCR, überwachten Ordner eine Datei ablege, ist der angemeldete Benutzer im Drive der Besitzer der abgelegten PDF-Datei.

Was mir noch aufgefallen ist: Mein NAS piept wieder, wenn die Datei verarbeitet ist, so wie ich es im synOCR eingestellt habe ...

Ich bin davon ausgegangen, dass das der unbekannte Besitzer "synOCR" der Grund für das nicht auftauchen der neuen Dateien unter "Vor kurzem" in der iOS-App und dem Drive-Frontend im Browser ist. Dem scheint aber nicht so zu sein.

Neue Dateien, tauchen nur dort auf, wenn sie via App oder im Drive Frontend direkt dort abgelegt werden, ohne den Umweg über synOCR zu gehen.
Die Änderung des Besitzers hat demnach, hinsichtlich dieser Thematik, nichts gebracht.
Was schön ist: Ich kann jetzt nach Besitzern in der Drive-App filtern.

Habt ihr evtl. eine Ahnung, woran das noch liegen könnte?

 

[geimist]

Piepen darf nur Herr root. Das kannst du in der GUI von synOCR einstellen (ganz unten).

Was den Verlauf betrifft: Es kann sein, dass hier Drive im eigenen Kosmos lebt und nicht von den Änderungen im Dateisystem gespeist wird. Darauf habe ich dann leider keinen Einfluss. Es kann auch sein, dass einfach nicht alle Shelloperationen gleichwertig getriggert werden. Es gibt ja nicht ohne Grund separate Log-Protokolle für SMB, FileStation, ect.

 

[Jerome]

Sieht so aus ... Das heißt dann vermutlich, dass nicht der Besitzer der Datei, sondern der "Dienst/Anwendungs-User" das Problem ist. In dem Fall root, der ja nicht Mitglied der Team-Ordners ist. Wenn ich meinem User root-Berechtigungen gebe und mich, als Mitglied des Team-Ordners, als Ausführer des SynOCR-Tasks auswähle ... Wäre das eine Option? Falls ja, wie gebe ich mir im Synology-Environment root-Berechtigungen?

Edit: Ich hab mal beim Support nachgefragt, wie die damit umgehen.

 

[Jerome]

Bisher noch keine Antwort, melde mich, aber wenn ich was höre.

Ich glaube, wenn synOCR in letzter Instanz das Konto des angemeldeten Benutzers verwenden würde, um die verarbeitete Datei in den Ziel-Ordner zu kopieren, würde Drive das checken und in "Vor kurzem" anzeigen. Ich allerdings weiß nicht ob das möglich ist oder ggf. zu einfach gedacht.

Grüße und schönen Feierabend!

Edit: Ach ne, Denkfehler. Da ist ja niemand angemeldet. Es müsste ein Team-Mitglied sein. Ich bin durch für heute ...

 

[geimist]

Ich wollte auch schon mal Tags so setzen, dass sie in Drive auch als solche erkannt / genutzt werden können. Aber die sind auch User bezogen und nicht an das Dokument gebunden. Es gibt also einige Abweichungen.

 

[Jerome]

Guten Morgen Stephan,

bisher habe ich noch keine Antwort vom Support bzgl. eines Triggers für neu abgelegte Dateien durch einen Anwendungsuser (in dem Fall synOCR).
Falls das nicht möglich ist, werde ich die Implementation einer entsprechenden Schnittstelle für User und Tags anfragen. Das macht definitiv Sinn, da man so nicht nur die Dateinamen anhand von spezifizierten Schlagwörtern benennen kann, die aus dem OCR-String ermittelt werden, sondern auch die Tagfunktionalität aus Drive nutzen könnte.

Hier hätte ich einen Featurerequest: Ich lese Dateien über ein MFP und via Quickscan (iOS) ein, handelt es sich um Dokumente von neuen Absendern, schaue ich mir dieses an, wähle einen eindeutigen Identifier als Tag, und pflege dieses in synOCR. Wenn das irgendwie komfortabler ginge … Beispielsweise über eine Textdatei, die man vom Handy aus bearbeiten und speichern kann.

Gibt es eine offizielle Stelle für Featurerequests oder machst du dir selbst deine Agenda?

Beste Grüße

Jérôme

 

[geimist]

Was ist ein Absender (wie definierst du ihn)? Meinst du die buchstäbliche Adresse im Dokument?

Gibt es eine offizielle Stelle für Featurerequests oder machst du dir selbst deine Agenda?

Es gibt zwar eine öffentliche Liste, aber die wird nicht wirklich gepflegt und ist ziemlich rudimentär.
Intern habe ich eine eigene Featureliste mit allen möglichen Notizen, ToDos und Notizen.

 

[Jerome]

Ne, viel einfacher gedacht. Ich meine, wenn ich Post vom MediaMarkt bekomme und vorher noch nie Post von denen bekommen habe. Dann logge ich mich auf meinem NAS ein, öffne SynOCR und ergänze die Liste der Tags um MediaMarkt (Hier meine ich den Absender MediaMarkt). Wenn das irgendwie einfach ginge, bzw. leichter zugänglich wäre.

 

[geimist]

Gehe ich da recht in der Annahme, dass du die Tag über die GUI setzt? Das könntest du über die YAML-Datei genauso umsetzen. Allerdings sind hier die Regeln etwas komplexer (und viel umfänglicher). Es handelt sich aber um eine Textdatei im YAML-Format.

Anstelle des Textfeldes kannst du aber auch den gleichen Inhalt in einer externen Textdatei (alles muss in einer Zeile stehen / keine Zeilenumbrüche) nutzen. Die Möglichkeiten beschränken sich in dem Fall dann auf die bekannten mit der GUI.

Egal, welche der beiden Varianten du nutzt: in das Feld der GUI gehört der absolute Pfad zur externen Datei. Für die erste Methode steht ein Konvertierbutton in der GUI zur Verfügung. Damit wird auch der Pfad in die GUI geschrieben.

Du kannst es ja testen, indem du dein aktuelles Profil duplizierst und deaktivierst. Anschließend kannst du mit deinem Duplikat herumexperimentieren.

 

[Jerome]

Genau. Danke, das teste ich mal.

 

[Jerome]

Guten Morgen Stephan,

Synology hat sich auf mein Ticket gemeldet, dieser Auszug könnte interessant sein:

Die Dateien müssen erst einmal bei Ihnen getriggert werden, z. B. die mtime verändert, damit diese als verändert erkannt werden. Danach landen diese dann in die Rubrik vor kurzem.

Weißt du, ob synOCR die Möglichkeit hat, die mtime einer bereits im Drive abgelegten Datei zu ändern?

Grüße

 

[geimist]

Das macht ja synOCR ja u.a. bereits dafür, dass das per OCR gefundene Datum als Dateidatum verwendet wird. Was anderes kann ich da auch nicht machen. Ich könnte mir aber vorstellen, dass es einen Unterschied macht, ob man per Shell das Datum einer Datei ändert, oder z.B. per FileStation (Stichwort: Zugriff).

Falls jemand anderes noch eine Idee hat, immer her damit.

 

[geimist]

Ich habe mal über die Konsole die Zugriffszeit und auch die Änderungszeit einer Datei geändert. In keinem Fall taucht sie in Drive unter "vor kurzem" auf.