207 lines
3.9 KiB
Markdown
207 lines
3.9 KiB
Markdown
# Music Sync Script (Unraid)
|
|
|
|
## Zweck
|
|
Synchronisiert neue Musikdateien aus `incoming` in zwei Zielordner.
|
|
Dateien werden nur verarbeitet, wenn sie vollständig geschrieben sind.
|
|
|
|
---
|
|
|
|
## Ablauf
|
|
incoming → ready → DEST1 + DEST2 → delete
|
|
|
|
---
|
|
|
|
## Warum incoming → ready?
|
|
|
|
Das Script verwendet zwei Verzeichnisse, um einen sauberen und sicheren Verarbeitungszustand zu gewährleisten.
|
|
|
|
### Problem ohne Trennung
|
|
|
|
Wenn direkt aus `incoming` synchronisiert wird:
|
|
|
|
- Dateien können noch geschrieben werden (z. B. durch Picard)
|
|
- `rsync` kopiert ggf. unvollständige Dateien
|
|
- bei mehreren Durchläufen entstehen Inkonsistenzen zwischen den Zielen
|
|
|
|
---
|
|
|
|
### Lösung: Staging mit `ready`
|
|
|
|
Der Ablauf ist bewusst zweistufig:
|
|
|
|
incoming (unsicher) → ready (stabil) → Sync
|
|
|
|
#### incoming
|
|
- hier schreibt Picard
|
|
- Dateien können noch im Zugriff sein
|
|
- kein Sync von hier
|
|
|
|
#### ready
|
|
- Dateien werden erst verschoben, wenn sie alt genug sind
|
|
- `mv` innerhalb desselben Filesystems ist atomar
|
|
- Datei ist danach garantiert vollständig
|
|
|
|
👉 Ergebnis:
|
|
Das Script arbeitet nur mit fertigen, stabilen Dateien.
|
|
|
|
---
|
|
|
|
## Wichtiger Hinweis zu "atomar"
|
|
|
|
Ein `mv` ist nur dann atomar, wenn sich Quelle und Ziel im selben Filesystem befinden.
|
|
|
|
In diesem Setup:
|
|
|
|
```
|
|
INCOMING="/mnt/user/Cache/Picard/incoming"
|
|
READY="/mnt/user/Cache/Picard/ready"
|
|
```
|
|
|
|
liegen beide Pfade im selben Share → gleicher Storage → atomarer Move.
|
|
|
|
Wichtig:
|
|
- Es ist egal, wo Picard läuft (Docker, anderer Host, etc.)
|
|
- Entscheidend ist nur, wohin geschrieben wird
|
|
|
|
Nicht atomar wäre z. B.:
|
|
|
|
```
|
|
/mnt/user/... → /mnt/diskX/...
|
|
```
|
|
|
|
Dann würde `mv` intern kopieren + löschen.
|
|
|
|
---
|
|
|
|
## Lockfile
|
|
|
|
```
|
|
/mnt/user/Cache/Picard/sync.lock
|
|
```
|
|
|
|
### Zweck
|
|
- verhindert parallele Ausführung
|
|
- schützt vor doppelten Operationen
|
|
|
|
### Problemfall
|
|
Wenn das Script abbricht, bleibt das Lockfile bestehen und blockiert weitere Runs.
|
|
|
|
### Lösung
|
|
|
|
```
|
|
rm /mnt/user/Cache/Picard/sync.lock
|
|
```
|
|
|
|
Nur ausführen, wenn sicher kein Script mehr läuft.
|
|
|
|
---
|
|
|
|
## CHOWN (Dateirechte / CIFS Problem)
|
|
|
|
Nach dem Kopieren werden Dateien und Ordner explizit gesetzt auf:
|
|
|
|
```
|
|
CHOWN_USER="thorsten"
|
|
CHOWN_GROUP="users"
|
|
```
|
|
|
|
### Warum ist das nötig?
|
|
|
|
Unraid + CIFS/Samba verhält sich so:
|
|
|
|
- Dateien werden oft als `root` oder `nobody` angelegt
|
|
- Netzwerkzugriff über CIFS hat dann **keine Löschrechte**
|
|
- selbst wenn Lesen funktioniert
|
|
|
|
👉 Typisches Symptom:
|
|
Datei kann geöffnet, aber nicht gelöscht werden
|
|
|
|
---
|
|
|
|
### Lösung im Script
|
|
|
|
Nach erfolgreichem Sync:
|
|
|
|
- wird jede Datei gechowned
|
|
- zugehörige Ordner werden ebenfalls angepasst
|
|
- Ordner aber nur **einmal pro Lauf** (Performance)
|
|
|
|
👉 Ergebnis:
|
|
- Dateien gehören deinem User
|
|
- CIFS Zugriff funktioniert korrekt
|
|
- kein manuelles `chown -R` mehr nötig
|
|
|
|
---
|
|
|
|
## Eigenschaften
|
|
|
|
- verarbeitet nur Dateien älter als 1 Minute
|
|
- atomarer Move (incoming → ready)
|
|
- Sync zu zwei Zielen per rsync
|
|
- Löschen nur bei Erfolg beider Syncs
|
|
- fehlgeschlagene Dateien bleiben erhalten
|
|
- Lockfile verhindert parallele Ausführung
|
|
- Dry-Run Modus vorhanden
|
|
- Logging + Konsolenausgabe
|
|
- Pfade tolerant gegenüber trailing `/`
|
|
- Zielpfade müssen existieren (sonst Abbruch)
|
|
- Ownership wird gesetzt (`chown`)
|
|
- Ordner werden nur einmal pro Lauf angepasst
|
|
|
|
---
|
|
|
|
## Konfiguration
|
|
|
|
```
|
|
INCOMING="/mnt/user/Cache/Picard/incoming"
|
|
READY="/mnt/user/Cache/Picard/ready"
|
|
|
|
DEST1="/mnt/user/Cache/Syncthing/..."
|
|
DEST2="/mnt/user/Media/Musik/..."
|
|
|
|
LOG="/mnt/user/Cache/Picard/sync.log"
|
|
LOCKFILE="/mnt/user/Cache/Picard/sync.lock"
|
|
|
|
DRY_RUN=false
|
|
|
|
CHOWN_USER="thorsten"
|
|
CHOWN_GROUP="users"
|
|
```
|
|
|
|
---
|
|
|
|
## Dry Run
|
|
|
|
```
|
|
DRY_RUN=true
|
|
```
|
|
|
|
- keine Änderungen am Dateisystem
|
|
- rsync läuft mit --dry-run
|
|
- Aktionen werden geloggt
|
|
|
|
---
|
|
|
|
## Cron Beispiel
|
|
|
|
```
|
|
0 */6 * * *
|
|
```
|
|
|
|
---
|
|
|
|
## Hinweise
|
|
|
|
- Script beendet sich sofort, wenn keine Dateien vorhanden sind
|
|
- `ready/` wird nur bei Bedarf erstellt und kann wieder verschwinden
|
|
- Rechteproblem bei CIFS wird durch chown gelöst
|
|
|
|
---
|
|
|
|
## Debug
|
|
|
|
```
|
|
cat /mnt/user/Cache/Picard/sync.log
|
|
ls /mnt/user/Cache/Picard
|
|
```
|