Beiträge von DarkTrinity

Zitat von Sauerland

Poste mal die entsprechende desktop-Datei aus ~/.config/autostart

Also die von dem als Anmeldescript eingepflegtes Script hier (funktioniert nichts, nix in den Logs gefunden):

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

So... Anders versucht jetzt:

Nun habe ich testweise ein seperates Script, nur mit Mountbefehl zusätzlich bei Autostart reingemacht, allerdings nicht als Anmeldescript sondern als Anwendung:

Code:

#!/bin/bash
mount /home/nuria/.egroupware

Desktop Datei:

[Desktop Entry]
Comment=
Exec=/home/nuria/bin/mountEGW.sh
Icon=kaccounts-owncloud
Name=Mounte Egroupware
NoDisplay=false
Path=
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=

Das funktioniert zwar auch nicht, liefert aber im merhin schonmal Anhaltspunkte in den Logs - ein cat /var/log/messages | grep EGW ergab:

Zitat

2024-01-01T13:00:06.366945+01:00 DeskBox systemsettings[5676]: kf.kio.core: Url QUrl("file:///home/nuria/.config/autostart/mountEGW.sh.desktop") already represents a local file, cancelling job.

Zitat von Sauerland

In welchem Ordner ist das Script gespeichert?

Lesenswert:

https://docs.kde.org/stable5/e…l/autostart/autostart.pdf

Ok- da finde iCh jetzt nichts wirklich neues... Aber ich könnte versuchen das alles als Programm einzubauen (und nicht als Anmeldescript). Da es ja eine ausführbare SH- Fileist mit zugewiesenem Shebang sollte das ja gehen...

Vielleicht hatte ich das letztens sogar genau so gemacht ...

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 ...

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....

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

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)

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

Hi,

Ich persönlich würde die Config files prüfen, sowie sie in den DOCs von MariaDB angegeben sind (verwendetes OS berücksichtigen )

MariaDB Docs

Dann würde ich, zB via PHPMyAdmin prüfen, ob der verwendete USer entsprechend Zugriff hat. Als root würde da übrigens keine Remote Anmeldung zulassen. Die Anmeldung in PMA selbst sollte natürlich entsprechende Zugriffsrechte bieten, damit Du auch "alles siehst":

^PMA Docs

Visual Studio Code ist meiner Meinung nach ein tolles Tool, ich kann mir kaum vorstellen daß es daran liegt... Ein mehr oder weniger aktuelles PlugIn (6/23), was Dir vielleicht helfen könnte, findest Du hier:

Studio Code Market Place

PS:

Ein direkter RemoteAccess auf den Datenbankdienst würde ich aber, wenn überhaupt, nur LAN intern zulassen und entsprechend absichern. Sollte der Remote über das Web gehen, wäre eine API sicher die bessere Lösung.

Viel Erfolg

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 ?

Hat sich erledigt, mich mal ein wenig belesen und halte die Verschlüsselung der Festplatte über das BIOS (PW HDD) eigentlich für ausreichend.