Problem bei automatischen seahub start - vermutlich Berechtigungsproblem

Hallo zusammen, ich brauch mal eure Hilfe

aktuell kann ich meine seafile.sh und seahub.sh von Hand starten. Im Anschluss bin ich nach folgender Anleitung vorgegangen:

https://download.seafile.com/published/seafile-manual/deploy/start_seafile_at_system_bootup.md

Also User root konnte ich auch noch den Befehl systemctl enable seahub.service ausführen.

Wenn mit mit dem Befehl systemctl status seafile den Status ansehe, läuft der seafile server auch.

Beim Befehl systemctl status seahub bekomme ich jedoch folgende Ausgabe:

** seahub.service - seafile hub*

  • Loaded: error (Reason: Exec format error)*
  • Active: inactive (dead)*

Nov 20 12:14:47 seafile systemd[1]: /etc/systemd/system/seahub.service:3: Failed to add dependency on seafile.service, ig
Nov 20 12:14:47 seafile systemd[1]: /etc/systemd/system/seahub.service:11: Invalid user/group name or numeric ID: seafile

Beim Befehl systemctl start seahub bekomme ich folgende Ausgabe:

Failed to start seahub.service: Unit seahub.service is not loaded properly: Exec format error.
See system logs and ‘systemctl status seahub.service’ for details.

Ich vermute jetzt mal folgendes: Meine Daten liegen auf meiner QNAP NAS. Dieses Verzeichnis habe ich via NFS (Version 3) freigegeben.

Meine Virtualisierungssoftware Proxmox (also der Host) mounted diese Verzeichnis (in den Host).

Auf meinem LXC (Ubuntu 18.04) läuft mein Seafile Server. Dieser greift über bindmount (oder wie das heißt) auf den Mountpoint des Proxmox Hosts zu.

Hört sich etwas kompliziert an, geht ab. Ich kann sowohl auf der NAS Shell, als auch auf der Proxmox Shell oder auf der LXC Shell via touch eine Datei erstellen, sehe die in allen 3 Umgebungen und kann diese auch in allen 3 Umgebungen wieder löschen.

Jeder scheinen die Linux Berechtigung irgendwie unterschiedlich zu sein (da kenne ich mich leider nicht aus).

Unterhalb von seafiledaten sollen die eigentlichen Daten dann mal liegen.

Auf der QNAP NAS sieht das so aus:
drwx------ 6 101000 101000 4.0k Nov 18 19:53 seafiledaten/

Auf dem Proxmox so:
drwx------ 6 101000 101000 4096 Nov 18 19:53 seafiledaten

Auf dem LXC so:
drwx------ 6 seafile seafile 4096 Nov 18 18:53 seafiledaten/

Der darüberliegende Share Name sieht dann auf der QNAP NAS so aus:
lrwxrwxrwx 1 admin administ 16 Nov 20 05:51 SEAFILE -> HDA_DATA/SEAFILE/

Auf dem Proxmox so:
drwxrwxrwx 4 root root 4096 Nov 6 15:11 seafile

und auf dem LXC so:
drwxrwxrwx 4 nobody nogroup 4096 Nov 6 14:11 seafile/

Kann mir hier jemand behilflich sein, warum ich den seahub von Hand starten kann, aber über den Autostart nicht?

Vielen Dank

Gruß H-BLOGX

Ich würde erstmal prüfen, ob die systemd Unit für Seahub korrekt ist.

Das sieht für mich nach einem Fehler in der Syntax in der Unit aus. Gebe folgendes ein: systemctl edit --full seahub und vergleiche das mit hier: https://download.seafile.com/published/seafile-manual/deploy/start_seafile_at_system_bootup.md

Hallo rdb,

ich bekomme da als Ausgabe:

"/etc/systemd/system/seahub.service" already exists. Overwrite with "/etc/systemd/system/multi-user.target.wants/seahub.service"? [(y)es, (n)o]

Soll ich hier y oder n klicken?

Meine /etc/systemd/system/seahub.service sieht so aus:

[Unit]
Description=seafile hub
After=network.target seafile.service

[Service]
Type=forking
# change start to start-fastcgi if you want to run fastcgi
ExecStart=/home/seafile/seafile-server-latest/seahub.sh start
ExecStop=/home/seafile/seafile-server-latest/seahub.sh stop
User=seafile
Group=seafile

[Install]
WantedBy=multi-user.target

Die Unit sieht gut aus.

Führe im seafile-server-latest mal

./seahub.sh start-fastcgi

aus. Fastcgi wird zwar nicht mehr unterstützt, liefert aber mehr Debugging Infos als ./seahub.sh start

Einfach um ein paar Dinge vorher zu checken:

seahub.sh gehört seafile - oder seafile hat zumindest Ausführungsberechtigung? Soll heißen, ob der account seafile das shell script seahub.sh überhaupt ausführen “darf”

Du kannst mit sudo -u seafile -s dich als der Seafile User ausgeben und versuchen das zu tun, was du von deiner Unit erwartest. So lassen sich oft viele Probleme erkennen.

Dem entsprechend muss natürlich auch alles, was zum Prozess gehört, vom seafile Benutzer auch bearbeitet werden können - insbesondere der data Ordner.

Sicherlich nicht die Lösung - aber ein Ansatz um vielleicht eine zu finden. :slight_smile:

Guten Morgen rdb,

jetzt stehe ich etwas auf dem Schlauch. Das Starten von ./seafile.sh start und danach ./seahub.sh start geht ja. Ich habe ja das Problem nur bei systemctl start seahub

Guten Morgen IngwiePhoenix,

ich habe mich mal “ganz normal” auf der Shell als root eingeloggt und folgendes gemacht. Vielleicht kannst Du daraus ja schon ein paar Schlüsse bezüglich Berechtigungen ziehen:

root@seafile:~# sudo su seafile
seafile@seafile:/root$ cd ~
seafile@seafile:~$ ll
total 60
drwxr-xr-x 10 seafile seafile 4096 Nov 18 18:53 ./
drwxr-xr-x  3 root    root    4096 Nov  6 12:22 ../
-rw-------  1 seafile seafile 3400 Nov 20 15:46 .bash_history
-rw-r--r--  1 seafile seafile  220 Nov  6 12:22 .bash_logout
-rw-r--r--  1 seafile seafile 3771 Nov  6 12:22 .bashrc
drwxrwxr-x  3 seafile seafile 4096 Nov  6 14:47 .local/
-rw-------  1 seafile seafile   18 Nov  6 12:50 .mysql_history
-rw-r--r--  1 seafile seafile  807 Nov  6 12:22 .profile
drwx------  3 seafile seafile 4096 Nov 20 15:24 ccnet/
drwx------  3 seafile seafile 4096 Nov 20 15:11 conf/
drwxrwxr-x  2 seafile seafile 4096 Nov  6 13:44 installed/
drwxrwxr-x  2 seafile seafile 4096 Nov 20 14:36 logs/
drwxrwxr-x  2 seafile seafile 4096 Nov 20 15:24 pids/
lrwxrwxrwx  1 seafile seafile   25 Nov 18 18:29 seafile-data -> /mnt/seafile/seafiledaten/
drwxr-xr-x  7 seafile seafile 4096 Sep 19 02:54 seafile-server-7.1.5/
lrwxrwxrwx  1 seafile seafile   20 Nov  6 14:11 seafile-server-latest -> seafile-server-7.1.5/
drwxrwxr-x  4 seafile seafile 4096 Nov 18 19:34 seahub-data/
seafile@seafile:~$ cd seafile-server-latest
seafile@seafile:~/seafile-server-latest$ ll
total 156
drwxr-xr-x  7 seafile seafile  4096 Sep 19 02:54 ./
drwxr-xr-x 10 seafile seafile  4096 Nov 18 18:53 ../
-rw-r--r--  1 seafile seafile 11381 Sep 19 02:54 check_init_admin.py
-rwxr-xr-x  1 seafile seafile  1753 Sep 19 02:54 reset-admin.sh*
drwxr-xr-x  2 seafile seafile  4096 Nov 20 15:24 runtime/
-rwxr-xr-x  1 seafile seafile  1746 Sep 19 02:54 seaf-fsck.sh*
-rwxr-xr-x  1 seafile seafile  3134 Sep 19 02:54 seaf-fuse.sh*
-rwxr-xr-x  1 seafile seafile  2641 Sep 19 02:54 seaf-gc.sh*
drwxr-xr-x  7 seafile seafile  4096 Sep 19 02:55 seafile/
-rwxr-xr-x  1 seafile seafile  5000 Sep 19 02:54 seafile.sh*
drwxr-xr-x 15 seafile seafile  4096 Sep 19 02:53 seahub/
-rwxr-xr-x  1 seafile seafile  7906 Sep 19 02:54 seahub.sh*
-rw-r--r--  1 seafile seafile 57232 Sep 19 02:54 setup-seafile-mysql.py
-rwxr-xr-x  1 seafile seafile  1548 Sep 19 02:54 setup-seafile-mysql.sh*
-rwxr-xr-x  1 seafile seafile 22073 Sep 19 02:54 setup-seafile.sh*
drwxr-xr-x  4 seafile seafile  4096 May 11  2020 sql/
drwxr-xr-x  4 seafile seafile  4096 Nov  6 14:48 upgrade/
seafile@seafile:~/seafile-server-latest$

Ok, freut mich erstmal, dass Du jetzt ein funktionierendes Seafile hast.

Das nicht etwas mit Seafile kaputt war, sondern irgendwas mit der systemd Unit nicht stimmte, hatte ich ja vermutet. Evtl. sind irgendwo am Ende der Zeilen noch irgendwelche komischen Umbrüche, die durch das Copy-Pasting aus dem Seafile Manual entstanden sind.

Habe jetzt zur Vorsicht nochmals die /etc/systemd/system/seahub.service geleert und mit folgendem Inhalt gefüllt (vorher mal in notepad++ geposted und mir die nicht druckbaren Zeichen angeschaut. Es sind nur CRLF enthalten)

[Unit]

Description=Seafile hub

After=network.target seafile.service



[Service]

Type=forking

# change start to start-fastcgi if you want to run fastcgi

ExecStart=/home/seafile/seafile-server-latest/seahub.sh start

ExecStop=/home/seafile/seafile-server-latest/seahub.sh stop

User=seafile

Group=seafile



[Install]

WantedBy=multi-user.target

Ist denn eigentlich diese Berechtigung im obigen Verzeichnis ausreichend?
-rw-r–r-- 1 root root 386 Nov 19 15:23 seafile.service
-rw-r–r-- 1 root root 352 Nov 20 15:32 seahub.service

Wenn ich als User root den Befehl
systemctl enable seafile.service
absetze, bekomme ich keine Rückmeldung.

Wenn ich das gleiche mit dem Befehl
systemctl enable seahub.service
durchführe, bekomme ich folgende Fehlermeldung:

Failed to enable unit: File seahub.service: Invalid argument

Irgendwas scheint damit ja noch nicht zu stimmen …

Wirklich auskennen mit systemd tue ich mich nicht, aber im Forum gab es schonmal einen Thread:

Was ja irgendwie auch auf das hinweist, was du schon von Anfang an vermutet hast. Eine Idee, das wirklich zu bestätigen, wäre, den Link mal auf ein lokales Verzeichnis (das seafile:seafile gehört) zu setzen und zu schauen, ob das Seahub-Script dann geht. Dann wüsstest du ja sicher, dass es am Ordner liegt, wenn das die einzige Änderung ist.

Ich muss aber auch sagen, dass ich nicht genau verstehe, wie dein Setup aussieht. Was meinst du mit

Was ist/soll unter seafile/ sein? (Insbesondere, warum gehört es niemandem?)
Außerdem schreibst du, dass du per touch eine Datei erstellen kannst, die du in allen 3 Umgebungen siehst und auch löschen kannst. Nur, um das auch auszuschließen: (Auch) als user seafile?

Hallo squirrel, über den englischen Artikel bin ich auch schon gestolpert. Ich bin jetzt sicherlich in den Berechtigungsstrukturen von Linux noch nicht wirklich fit, aber wenn ich auf einem Linux System einen
chown seafile.seafile ****
Befehl ausführe, gehe ich mal davon aus, dass auf diesem System es ja einen Benutzer und eine Gruppe seafile geben muss, oder?

Auf meiner NAS (QNAP) gibt es keinen Benutzer / Gruppe seafile
Auf meinem Proxmox gibt es keinen Benutzer / Gruppe seafile
Auf meinem Seafile Server gibt es einen Benutzer / Gruppe seafile

Auf der NAS liegt der NFS Share. Der Proxmox holt sich diesen Share via /etc/fstab. Der Seafile holt sich wiederrum über Proxmox interne Sharemöglichkeiten diesen vom Proxmox.

Auf der NAS kann ich mit dem User “admin” im Shareverzeichnis schreiben - lesen - löschen

Auf dem Proxmox kann ich mit dem User “root” im Shareverzeichnis schreiben - lesen - löschen

Auf dem Seafile Server kann ich im seafile-data Verzeichnis NICHT als User root zugreifen, aber als User seafile kann ich dort schreiben - lesen - löschen

Hoffe das es jetzt deutlicher ist, falls nicht, bitte nochmals fragen.

Frage: Wenn ich mir jetzt ein temporäres lokaler Verzeichnis anlege und den SymLink umlege, muss ich dann die ganzen Verzeichnisse darunter gleich mitkopieren, oder kann man das zum Testen auch bleiben lassen?

Gute Frage :smiley: Ich glaube, das kannst du bleiben lassen.

Unter welchem Benutzer erstelle ich eigentlich diese beiden Dateien, bzw. unter welchem Benutzer werden diese “enabled”?

https://download.seafile.com/published/seafile-manual/deploy/start_seafile_at_system_bootup.md

Also root oder als seafile user?

Ich habe für mich eine Lösung gefunden, jedoch ob das bei anderen auch geht …

  1. Testweise habe ich ein lokales seafile-data Verzeichnis eingerichtet. Der automatische seahub service Start ging immer noch nicht.

  2. Ich habe als User root nochmals seahub.service und seafile.service disabled und zur Sicherheit die Dienste gestoppt.

  3. Dann die beiden Dateien nochmals gelöscht und systemctl daemon-reload ausgeführt.

  4. Jetzt bin ich nochmals genau nach https://download.seafile.com/published/seafile-manual/deploy/start_seafile_at_system_bootup.md vorgegangen. Auch die Verzeichnisse angepasst.

  5. Danach wieder ein systemctl daemon-reload durchgeführt.

  6. Nun ein sudo systemctl enable seafile.service und im Anschluss ein sudo systemctl enable seahub.service durchgeführt. Bei beiden kamen jetzt keine Fehlermeldungen mehr.

  7. Zur Sicherheit und aus Unwissenheit wieder ein systemctl daemon-reload durchgeführt.

  8. Jetzt ein systemctl start seafile (läuft … es wird spannend)

  9. Nun ein systemctl start seafile (läuft auch :crazy_face:)

  10. Virtuellen seafile Server einmal gebootet. Alles läuft.

  11. Beide Dienste gestoppt, seafile-data Verzeichnis wieder auf ursprüngliches Ziel umgeleitet und Server nochmals gebootet. Läuft!

Schön :slight_smile:

Um deine Frage vom vorigen Post zu beantworten: Als root, ausgeführt wird das Skript von root, aber im Skript steht ja, dass Seafile dann als Benutzer “seafile” ausgeführt werden soll.