Autorun für ext. Datenträger

Jip-Hop

Benutzer
Mitglied seit
28. Feb 2021
Beiträge
5
Punkte für Reaktionen
3
Punkte
53
Ich hatte die gleichen Sorgen wie SyWalker in seinem Beitrag. Aus diesem Grund habe ich eine Methode implementiert, um zu überprüfen, ob das Skript nicht geändert wurde. Sie finden es auf GitHub.
 

Dragonia

Benutzer
Mitglied seit
19. Aug 2013
Beiträge
33
Punkte für Reaktionen
0
Punkte
6
Autorun scheint unter DSM 7 nicht mehr zu laufen
oder hat es wer zum laufen gebracht ?
 

framp

Benutzer
Mitglied seit
19. Feb 2016
Beiträge
800
Punkte für Reaktionen
30
Punkte
54
Eben bin ich auf dieses nette Tuelchen aufmerksam geworden und es klingt fuer mich sehr interessant. Ich habe mir jetzt mal die Implementierung von @Jip-Hop auf github angesehen und im Prinzip ist mir soweit klar was da ablaeuft (Per UDEV Regel ein Script aufrufen).

Mein Szenario ist dass ich zwei verschiedene USB Platten habe die ich wechselweise per USB anschliesse und fuer jede Platte jeweils einen Hyperbackup Job. An dieser Stelle im Code sieht man dass nach einem Script gesucht wird und wenn es existiert ausgefuehrt wird . Jetzt habe ich gesucht wie das Script heissen muss und bin auf diese Stelle gelangt und letztendlich definiert diese Stelle wie das Script heisst.

Jetzt frage ich mich wie und wo die Environmnentvariablen gesetzt werden. Vermutlich im UI. Dieses existiert aber nicht mehr im Fork von @Jip-Hop . Kann mir jemand sagen wo und wie sie gesetzt werden? Dann kann ich auf den jeweiligen Platten die jeweilige Hypebackup ID nehmen und den Backupjob beim Einstecken starten lassen.
 
  • Like
Reaktionen: Jip-Hop

SAMU

Benutzer
Mitglied seit
26. Sep 2018
Beiträge
252
Punkte für Reaktionen
9
Punkte
18
Autorun scheint unter DSM 7 nicht mehr zu laufen
oder hat es wer zum laufen gebracht ?

Das gleiche habe ich mir auch gerade überlegt (noch nutze ich DSM6) Weißt du da schon was neues?
 

Jip-Hop

Benutzer
Mitglied seit
28. Feb 2021
Beiträge
5
Punkte für Reaktionen
3
Punkte
53
Eben bin ich auf dieses nette Tuelchen aufmerksam geworden und es klingt fuer mich sehr interessant. Ich habe mir jetzt mal die Implementierung von @Jip-Hop auf github angesehen und im Prinzip ist mir soweit klar was da ablaeuft (Per UDEV Regel ein Script aufrufen).

Mein Szenario ist dass ich zwei verschiedene USB Platten habe die ich wechselweise per USB anschliesse und fuer jede Platte jeweils einen Hyperbackup Job. An dieser Stelle im Code sieht man dass nach einem Script gesucht wird und wenn es existiert ausgefuehrt wird . Jetzt habe ich gesucht wie das Script heissen muss und bin auf diese Stelle gelangt und letztendlich definiert diese Stelle wie das Script heisst.

Jetzt frage ich mich wie und wo die Environmnentvariablen gesetzt werden. Vermutlich im UI. Dieses existiert aber nicht mehr im Fork von @Jip-Hop . Kann mir jemand sagen wo und wie sie gesetzt werden? Dann kann ich auf den jeweiligen Platten die jeweilige Hypebackup ID nehmen und den Backupjob beim Einstecken starten lassen.

Google Übersetzer:

Ich wechsle auch zwei Festplatten für zwei separate Hyper Backup-Jobs.

Tolle Detektivarbeit, die den Code so durchliest :) Ich habe die UI in meiner Fork nicht entfernt, sie wurde bereits entfernt (nicht funktionsfähig), aber die Dateien waren immer noch da. Es besteht jedoch keine wirkliche Notwendigkeit für eine UI. Die gesamte Konfiguration wird während des Installationsassistenten festgelegt. Installieren Sie einfach Autorun und es wird nach dem Namen Ihres Skripts usw. gefragt. Wenn Sie diese Einstellungen ändern möchten, entfernen Sie das Autorun-Paket und installieren Sie es neu.

Ich weiß nicht ob es auf DSM 7 funktioniert, da ich es (noch) nicht benutze.

Original comment in English:

I'm also alternating two HDDs for two seperate Hyper Backup jobs.

Great detective work reading through the code like that :) I didn't remove the UI in my fork, it was already removed (non-functional) but the files were still there. However there's not really a need for a UI. All configuration is set during the install wizard. Just install Autorun and it will aks for the name of your script etc. If you want to change these settings, remove the autorun package and reinstall.

I don't know if it works on DSM 7 as I'm not (yet) using it.
 

Jip-Hop

Benutzer
Mitglied seit
28. Feb 2021
Beiträge
5
Punkte für Reaktionen
3
Punkte
53
Ich kann mein Skript auch empfehlen, um Hyper Backup + Integritätsprüfung + E-Mail-Benachrichtigungen auszuführen. Für mich ist Hyper Backup schnell abgeschlossen, aber die Integritätsprüfung kann ziemlich lange dauern. Ich empfehle daher, es über Nacht laufen zu lassen. Lesen Sie die Kommentare im Skript, um zu erfahren, wie Sie es konfigurieren.
 
  • Like
Reaktionen: Fusion

Christian72D

Benutzer
Mitglied seit
29. Apr 2010
Beiträge
702
Punkte für Reaktionen
11
Punkte
44
Ich habe gerade auf meiner 920+ (DSM 6.x) das Autorun über die Github Seite manuell installiert, meine autorun auf die Karte gepackt, aber die Synology blinkt oder piept nicht und führt auch nichts aus.
Wo genau kann ich schauen, ob das Programm arbeitet, das Script einen Fehler hat oder sonst was nicht passt.
 

JC-23

Benutzer
Mitglied seit
03. Aug 2021
Beiträge
1
Punkte für Reaktionen
3
Punkte
53
Autorun scheint unter DSM 7 nicht mehr zu laufen
oder hat es wer zum laufen gebracht ?
Da ich seit Sonntag DSM 7 am Laufen habe, habe ich Autorun dafür angepasst. Es basiert auf Jip-Hops Vorlage. Ihr könnt es auf meiner GitHub-Seite herunterladen. Beachtet, dass aufgrund von Berechtigungsänderungen in DSM 7 das Paket ohne manuellen Eingriff nicht lauffähig ist. Die Anweisungen dazu findet ihr in der README.
 

plang.pl

Benutzer
Sehr erfahren
Mitglied seit
28. Okt 2020
Beiträge
2.782
Punkte für Reaktionen
623
Punkte
154
Gestern hat reidemei sein autorun-Paket für DSM7 fit gemacht! Siehe github.
Nach der Installation ist ein SSH-Befehl als root auszuführen. Den sieht man während der Installation (zum kopieren) oder in der Readme.

Bei mir funktioniert es damit nun auch wieder!
 

Roger Wilco

Benutzer
Mitglied seit
19. Dez 2019
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Ich habe mit der Änderung auf DSM 7.0 auch autorun auf die Version 1.8 aktualisiert und anschließend den SSH-Befehl ausgeführt. Die USB-Platte wird erkannt und mein Backup Script beginnt zu arbeiten. Jedoch wird das Laufwerk mit "exit 100" nicht mehr ausgeworfen.

Auszug aus der log-Datei:
Code:
2021-08-24 11:21:41: device 'sdq1' - inserted, trying to find mount point
2021-08-24 11:21:49: device 'sdq1' - mount point '/volumeUSB1/usbshare' found
2021-08-24 11:21:54: device 'sdq1' - script '/volumeUSB1/usbshare/autorun' found, executing
2021-08-24 11:28:28: device 'sdq1' - script '/volumeUSB1/usbshare/autorun' finished (1.8T left on device), starting unmount
2021-08-24 11:28:34: <span style="color:red;">device 'sdq1' - error while unmounting '/volumeUSB1/usbshare', aborting

Hat jemand das gleiche Problem bzw. eine Lösung dazu? Ich wäre sehr dankbar!
 

plang.pl

Benutzer
Sehr erfahren
Mitglied seit
28. Okt 2020
Beiträge
2.782
Punkte für Reaktionen
623
Punkte
154
Jedoch wird das Laufwerk mit "exit 100" nicht mehr ausgeworfen.
Ich verwende die Option von HyperBackup zum automatischen Auswerfen. Habe es gerade mal testweise deaktiviert und auch bei mir wird mit "exit 100" die Platte nicht ausgeworfen. Unter DSM 6 ging das definitiv.
Habe dazu auf github gleich mal ein Issue aufgemacht
 

Tommes

Benutzer
Sehr erfahren
Mitglied seit
26. Okt 2009
Beiträge
8.429
Punkte für Reaktionen
406
Punkte
249
Hi!

Eine Frage zum Thema "auswerfen"!
Ich habe autorun in der Version 1.8 für DSM 7 grade mal installiert um mir das Problem mit dem "nicht auswerfen" näher anzuschauen. Jedoch muss ich feststellen, das bei mir das Auswerfen soweit funktioniert. Das einzige, was bei mir nicht funktioniert ist das abschließende löschen des eingehängten USB-Dateisystems volumeUSB1/usbshare. Dieses wird mir in der File Station auch weiterhin angezeigt. Für dieses Problem hätte ich auch eine Lösung anzubieten, jedoch wollte ich erst mal nachhören, wie das mit dem Auswerfen generell bei euch so ist.

Hier noch ein Auszug aus meinem Protokoll....
Code:
2022-01-29 16:45:13: device 'sdq1' - inserted, trying to find mount point<br/>
2022-01-29 16:45:17: device 'sdq1' - mount point '/volumeUSB1/usbshare' found<br/>
2022-01-29 16:45:22: device 'sdq1' - script '/volumeUSB1/usbshare/autorun' found, executing<br/>
2022-01-29 16:45:24: device 'sdq1' - script '/volumeUSB1/usbshare/autorun' finished (15G left on device), starting unmount<br/>
2022-01-29 16:45:30: device 'sdq1' - unmounted and ejected<br/>

Tommes
 

Roger Wilco

Benutzer
Mitglied seit
19. Dez 2019
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Hallo Tommes,

danke, dass du noch einmal auf das Problem mit dem Auswerfen zurückkommst. Ich glaube mittlerweile, dass irgendein Prozess (AV, Indizierung,...) meinen unmount verhindert hat. Nach einer Weile hat dann auch der umount Befehl per Hand im Terminal funktioniert, aber in der FileStation wurde der Datenträger immer noch angezeigt.

Da sich so lange keiner zu dem Problem gemeldet hat, dachte ich, dass ich einer der wenigen bin, der noch autorun in Verwendung hat. Zumindest einer der Wenigen, der Probleme damit hat. Schlussendlich habe ich deshalb schweren Herzens auf HyperBackup gewechselt, wo das automatische Auswerfen funktioniert. Ich bin aber schon gespannt, was aus Basic Backup noch wird.
 

Tommes

Benutzer
Sehr erfahren
Mitglied seit
26. Okt 2009
Beiträge
8.429
Punkte für Reaktionen
406
Punkte
249
Nach einer Weile hat dann auch der umount Befehl per Hand im Terminal funktioniert, aber in der FileStation wurde der Datenträger immer noch angezeigt.

Nachdem was ich so rausgefunden habe, fehlt autorun nur ein abschließender rmdir Befehl nach dem umount, damit der Mountpoint (z.B. /volumeUSB1/usbshare) aus der File Station verschwindet.

Wer das mal ausprobieren möchte, kann die Datei /var/packages/autorun/target/autorun editieren und die Zeilen 73 bis 76, also diese hier…

Bash:
# and eject the drive
EXTHD=`/bin/echo $1 | sed "s/[0-9]//"`
/bin/echo 1 > /sys/block/$EXTHD/device/delete
logInfo "device '$1' - unmounted and ejected"

… gegen diese hier austauschen…

Bash:
# and eject the drive
EXTHD=`/bin/echo $1 | sed "s/[0-9]//"`
/bin/echo 1 > /sys/block/$EXTHD/device/delete
if [ $? -eq 0 ]
then
    rmdir "$MOUNTPATH"
fi
logInfo "device '$1' - unmounted and ejected"

Wie gesagt. Bei mir funktioniert das so und rmdir löscht auch nur leere Verzeichnisse, weshalb bei dieser Aktion nichts passieren sollte. Da ich das für den Moment aber nicht ganz ausschließen kann, sollte man diesen Codeschnipsel vorerst nur zum Testen nutzen. Sollte das @Merthos (oder wer auch immer) aber für Zielführend erachten, wäre es vielleicht ganz nett, das ins SPK zu übernehmen.

Tommes
 
Zuletzt bearbeitet:

Tommes

Benutzer
Sehr erfahren
Mitglied seit
26. Okt 2009
Beiträge
8.429
Punkte für Reaktionen
406
Punkte
249
Ach so… ganz vergessen! Die oben genannten Änderungen beziehen sich auf die Version 1.8 für DSM7. Wie das bei den Forks in der Version 1.9 aussieht, hab ich mir nicht angeschaut.
 

mdawid

Benutzer
Mitglied seit
07. Jan 2014
Beiträge
61
Punkte für Reaktionen
2
Punkte
6
Hallo Zusammen,

ich habe vor kurzem auf meine DS216+ auf DSM 7.0 geupgraded und im gleichen Zuge auch das autorun Paket. Leider bekomme ich es im Moment noch nicht zum laufen, und ich komme nicht dahinter, wo das Problem sein könnte.
Ich habe wie in der Beschreibung gelesen, den "root Befehl" ausgeführt und die privileges.root an die richtige Stelle kopiert. Wenn ich nun, meine Backup-Festplatte auswerfe (via DSM) und das USB-Kabel abstecke und wieder einstöpsel, dann sehe ich diese Fehlermeldung im log:

Bash:
2022-05-17 20:46:58: device 'sdq1' - inserted, trying to find mount point<br/>
2022-05-17 20:46:58: device 'sdq1' - unable to find mount point, aborting<br/>

Ich hab schon in diesem Forum gesucht und wurde sogar hier fündig. Als Lösung war dort angegeben, dass das Encoding des autorun Skriptes falsch war und auf cp1252 gesetzt sein muss. Laut
Code:
file -bi autorun
ist das Skript wie folgt kodiert:
Code:
text/x-shellscript; charset=us-ascii
. Wenn ich aber die Datei in Notepadqq aufmache, dann soll die Datei in UTF-8 kodiert sein. Kann das sein? Ich habe schon versucht das Encoding zu ändern, aber das auch ohne Erfolg.

Wenn ich das Backup manuell über Hyperbackup starte, dann läuft es soweit ohne Probleme durch.

Meine autorun sieht wie folgt aus:

Code:
#!/bin/sh
/usr/syno/bin/synobackup --backup task_14 --type image
sleep 60
while [ "$(/bin/pidof img_backup)" ]
do
  sleep 60
done
exit 0

Meine synobackup.conf sieht wie folgt aus:

Code:
[task_14]
backup_apps=["AntiVirus","AudioStation","CloudSync","DNSServer","DownloadStation","FileStation">
backup_apps_config=null
backup_filter={"exclude_list":[],"whitelist":[]}
backup_folders=["...",>
backup_volumes=[]
create_time=1641157329
data_compress_type=1
enable_data_encrypt=true
enable_delete=true
enable_dest_auto_unmount=true
enable_notify=true
enable_version_file_log=false
enable_version_rotation=true
incheck_info="{\"data_enable\":true,\"date\":\"2022/1/9\",\"time_limit\":30}\n"
incheck_sched_id=21
linkkey="..."
name="Voyager"
repo_id=16
rotate_action="[[86400,3600,1],[2419200,86400,1],[0,604800,1]]"
rotate_condition="[1,16]"
rotate_customized_rules="[[86400,3600,1],[2419200,86400,1],[0,604800,1]]"
rotate_option="rotate_smart_recycle"
sched_id=20
support_cross_file_dedup=true
target_dir="ds-kepler.hbk"
unikey="..."

Versionen:
autorun: 1.8
DSM: DSM 7.0.1-42218 Update 3

Habt ihr eine Idee woran es liegen könnte?

Danke und Grüße
 

mdawid

Benutzer
Mitglied seit
07. Jan 2014
Beiträge
61
Punkte für Reaktionen
2
Punkte
6
Konnte mein Problem lösen, indem ich die anzahl der TRIES auf 60 gesetzt habe. Dadurch wartet das Skript ca 60s bis es loslegt. Die Konfig-Datei liegt hier /var/packages/autorun/target/config

Bash:
CRIPT=autorun
TRIES=60
WAIT=
BEEP=0
LED=0
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: plang.pl und Tommes

Horst22

Benutzer
Mitglied seit
07. Jun 2022
Beiträge
8
Punkte für Reaktionen
4
Punkte
53
Ich habe einen Fork von Autorun für DSM 7 als Version 1.10.0-0001 in Github veröffentlich: https://github.com/schmidhorst/synology-autorun. Viele Dinge habe ich etwas umgeschrieben. Die wesentlichen Änderungen:
  • Im Installations-Wizzard werden bei Re-Installation oder Upgrade die vorhanden Einstellungen als Vorgabe angezeigt. Re-Installation ist derzeit der einzige Weg, Einstellungen zu ändern, soweit man sie nicht per SSH /var/packages/autorun/var/config (neuer Pfad!) ändern möchte.
  • Derzeit ist der Installations-Wizzard in Deutsch und Englisch. Bisher noch keine weiteren Übersetzungen.
  • Die Desktop-Meldungen, die seit Synology's Umstellung von synodsmnotify auf i18n-Strings nicht mehr funktionierten, gehen jetzt wieder.
  • Der Laufwerks-Auswurf beim Rückgabecode 100 sollte wieder funktionieren.
  • Es kann nach dem Auswurf noch ein Skript (auf dem internen Speicher) ausgeführt werden. Z.B. um die Stromversorgung des externen Laufwerks über eine Smart-Steckdose abzuschalten.
  • Als Sicherheits-Feature kann die Skriptausführung auf zuvor registrierte SHA256-Fingerprints der Skripts beschränkt werden, ähnlich wie auch schon in anderen Forks.
  • Das auszuführenden Skript wird auf Fehler wie z.B. falscher Zeilenumbruch oder falsche Kodierung (nicht UTF-8) geprüft und geg. eine Fehlermeldung.
Rückmeldungen zu möglichen Fehlern und Optimierungen sind willkommen.

Geplante weitere Ergänzungen:
  • Exportmöglichkeit für Log-Dateien
  • Veröffentlichung via cphub.net
Offene Punkte:
  • In den cgi-Dateien zur Anzeige der aktuellen Einstellungen und der Log-Dateien ist es mir noch nicht gelungen, die Sprache des aktuellen User-Accounts zu ermitteln. Diese kann anders sein als $(/bin/get_key_value /etc/synoinfo.conf language), $(/bin/get_key_value /etc/synoinfo.conf maillang), $SYNOPKG_DSM_LANGUAGE und der Sprache im HTML-Header (z.B.
    "de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
    ").
  • Falls nach einem Fehler eine LED der Diskstation diesen anzeigt, ist es mir wegen der Permissions noch nicht gelungen, diese über eine der cgi-Dateien mittels "echo ... > /dev/ttyS1" zurückzusetzen.
PS: Im Mai 2022 habe ich mir mein erstes NAS, eine DS220+ zugelegt und mich mit hohem Zeitaufwand in die Tiefen der Paketentwicklung eingearbeitet. Autorun verwende ich für Backups mittels Duplicati (in Docker-Container).
 
  • Like
Reaktionen: geimist und Tommes
NAS-Central - Ihr Partner für NAS Lösungen
NAS-Central - The Home of NAS

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat 

Hosted by netcup