Automatisch ein Webdav mounten via davfs2

Hallo liebe Community,

ich möchte eine Webdav- Ressource (Egroupware) immer nach dem booten automatisch gemounted haben.

Die Requirements sehe ich als erfüllt:

1. Der entsprechende User ist Mitglied in der Gruppe davfs2

2. Die Ressource ist korrekt in der /etc/fstab eingetragen

https://ich.de/egroupware/webdav.php /home/nuria/.egroupware davfs noauto,user 0 0

3. Das SUID- Bit füR die relevanten Befehle ist gesetzt

chmod u+s /usr/sbin/mount.davfs
chmod u+s /usr/sbin/umount.davfs

4. In der Secrets Datei des Users die Zugangsdaten

https://ich.de/egroupware/webdav.php/   "username@instance"       "youdonotknowthis"

5. Berechtigungen gesichert

chmod 700 ~/.davfs2/
chmod 600 ~/.davfs2/secrets

Damit müsste ja alles funktoionieren - tut es aber nur eingeschränkt:

A) Ein (ausführbares) Script, welches über die Systemsteuerung als Anmeldungsscript eingetragen ist, schafft den Mountvorgang nicht. Dieses Script erledigt neben dem Mounten noch zahlreiche andere Dinge recht erfolgreich. Der Snip hier:

[...]
mount /home/nuria/.egroupware
## der Mountbefehl ist der letzte Eintrag

B) Ein eigenes (ausführbares) Script, was es mittlerweile in mein K- Menü zum anclicken geschafft hat, mounted diese Ressource erfolgreich - die Codezeile ist aber die gleiche Das klappt aber auch nur dann, wenn ich das Script manuell starte - via Bash oder eben per Click im K-Menü

mount /home/nuria/.egroupware

C) Also dachte ich mir, ich starte dieses seperate Script aus Punkt B einfach über das bootscript aus Punkt A, welches ich daher wie folgt angepasst habe - geht natürlich auch nicht

## Mounte Egroupware
/home/nuria/bin/mountEGW.sh

D) In einem letzten Versuch habe ich dann das zusätzliche Script aus Punkt B als zusätzliches Anmeldescript eingetragen und den Mountvorgang aus dem anderen Script entfernt - natürlich führte das auch nicht Erfolg...

Ich verstehe dieses Verhalten nicht. Vielleicht sieht ja hier jemand das, was ich übersehe ?

Zitat von Sauerland

Netzwerkmanager?????

Kannst du mal ein Wait vor dem Befehl einfügen:

Code

sleep 30

Dann wird 30 Sekunden gewartet.

edit

falscher Befehl, muss sleep heißen.

Alles anzeigen

Nein, wicked. Das mit dem Sleep um Wartezeiten einzubauen, habe ich dennoch drinne - ganz am Anfang des Script - aber nur mit 10

Das mit dem noauto sollte aber nicht die Ursache sein - ein man fstab sagt ja dazu:

Zitat

      noauto

Nicht automatisch einhängen, wenn mount -a aufgerufen wird (z.B. beim Hochfahren)

In m einem Fall ist es ja letztendlich ein manueller Aufruf, der via Script ausgeführt wird. Das mache ich bewusst so, damit ich bei Netzwerk- oder Internetproblemen trotzdem problemlos booten kann (ohne zusätzliche Handgriffe)

Ich werde eine zusätzliche Sleeptime vor dem Mountbefehl einbauen - 20 Sekunden.

In Kombination mit dem Sleeper am Anfang des gleichen Scripts komme ich dann ja im Gesamtablauf auf (mindestens) 30 - sowie Sauerland empfohlen.

Dann mal gucken

Also die Erhöhung des Sleep- Wertes hat nichsts gebracht- würde aber aber meiner Meinung nach auch bei wicked kaum sinn machen.

In den Logs (messages) habe ich nichts passendes gefunden...

Es muss doch einen Unterschied zwischen geben, der das Fehlerbild verursacht. Aber soweit ich das sehe ist da eigentlich kein Unterschied, außer der Tatsache, daß das Script wo der Mount scheitert eben als Anmeldescript ausgeführt wird. Das erfolgreiche Script starte ich selbst.

Ich kann mir aber kaum vorstellen, daß es daran liegt. Weil einige andere Befehle, die ebenfalls im Anmeldescript sind problemlos funktionieren und ebenfalls die zugewiesenen Rechte meines Accounts benötigen - zB um in mein homedirectoiry schreiben zu können ....

Ich stelle mir die Frage ob das Problem an den Rechten liegt wegen dem

chmod 600 ~/.davfs2/secrets

Ein dir -all ergibt hier

insgesamt 8
drwx------ 1 nuria users   56 27. Dez 10:58 .
drwxr-xr-x 1 nuria users  768  1. Jan 14:12 ..
drwx------ 1 nuria users  532 27. Dez 10:59 cache
drwxr-xr-x 1 nuria users   14 27. Dez 09:58 certs
-rw-r--r-- 1 nuria users 2292 27. Dez 09:58 davfs2.conf
-rw------- 1 nuria users  335 27. Dez 10:51 secrets

An diesem System arbeite zwar nur ich, aber diese Datei mit unverschlüsseltem Password möchte ich trotzdem nicht freizügiger als nötig bereit stellen....

Hey, Danke Das Dokument lese ich mir später definitiv durch. Ich glaube daß hier durchaus die Ursache sein könnte.

Zu Deiner Frage: DIe liegen alle im bin Ordner ~/bin - das Bootscript, welches den Snip enthält, ist hier:

insgesamt 20
drwxr-xr-x 1 nuria users  100  1. Jan 14:09 .
drwxr-xr-x 1 nuria users   86  1. Jan 10:21 ..
-rwxr-xr-x 1 nuria users 3892  1. Jan 14:09 bootscript
drwxr-xr-x 1 nuria users  182 30. Dez 06:21 .git
drwxr-xr-x 1 nuria users  120 28. Dez 13:38 Library
-rw-r--r-- 1 nuria users 1099 28. Dez 14:42 LICENSE
-rw-r--r-- 1 nuria users  154 30. Dez 06:14 README.md
-rwxr-xr-x 1 nuria users 6510 28. Dez 14:26 SmartShutdown

Unter /home/nuria/.config/autostart/ die Datei, die die Systemsteuerung dazu angelegt hat:

[Desktop Entry]
Exec=/home/nuria/bin/Smart_Client/bootscript
Icon=dialog-scripts
Name=bootscript
Type=Application
X-KDE-AutostartScript=true

Ich hatte auf meinem ehemaligen System schon mal ähnlichen Ärger, der auch mit der Nutzung der Autostart Möglichkeit für dieses Szenario verbunden war. Wie ich das damals gelöst habe, hatte ich mir natürlich schlauerweise nicht notiert ...