[Eisfair] [E64] exim: "systemd: Failed to resolve symlink /usr/local/share/systemd/user, ignoring: Permission denied"

[Rolf Bensch]

Hallo Marcus,

Am 05.11.24 um 08:27 schrieb Marcus Röckrath:
> Hallo Rolf,
> 
> Marcus Röckrath wrote:
> 
>>> Ich habe hier eine Situation erstellen können, die genau deine
>>> Fehlermeldung provoziert:
>>>
>>> Nov  4 21:42:58 eis systemd[7036]: Failed to resolve symlink
>>> /usr/local/share/systemd/user, ignoring: Permission denied
>>> Nov  4 21:42:58 eis systemd[7036]: Failed to open
>>> "/usr/local/share/systemd/user", ignoring: Permission denied
>>>
>>> Was habe ich getan?
>>>
>>> Das Verzeichnis /tmp/x angelegt.
>>>
>>> /usr/local/share/systemd/user als Symlink auf /tmp/x angelegt:
>>>
>>> ln -s /tmp/x /usr/local/share/systemd/user
>>>
>>> /usr/local/share/systemd/user ist nicht das Ziel des Symlinks sondern es
>>> der Symlink, der in meinem Beispiel auf das Verzeichnis /tmp/x zeigt.
>>>
>>> Dann habe ich /tmp/x entfernt, so dass nun der Symlink ins Leere zeigt.
>>>
>>> Nun kommt, wenn der User exim aktiv wird, weil fetchmail pollt die obige
>>> Fehlermeldung.
> 
> Und sie passt auch zum Wortlaut der Fehlermeldung:
> 
> Die Auflösung des Symlinks /usr/local/share/systemd/user ist fehlgeschlagen
> - ignoriere (das Ziel).
> 
> Irritierend ist das "Erlaubnis verweigert", da das Ziel des Links garnicht
> existiert aber nicht die falschen Rechte hat.
> 
> Gibt es das Ziel des Links ist aber für den "User" verboten, erscheint die
> gleiche Fehlermeldung.
> 
> Der Fehler muss bei dir irgendwie auch in dieser Richtung vorliegen.

Hmm. Unabhängig davon ob das Ziel des Symlink existiert oder nicht, stellt sich doch vordergründig die Frage, weshalb systemd diesen Symlink sucht.

Hier ist bereits /usr/local/share/systemd nicht existent - in Deinem Test wäre das /tmp.

Grüße

Rolf