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

Marcus Röckrath marcus.roeckrath at gmx.de
Mo Nov 4 22:00:57 CET 2024


Hallo,

Marcus Röckrath wrote:

>> Dennoch habe ich ein "make DESTDIR=/tmp/cups install" ausgeführt und
>> finde jetzt in /tmp/cups die Unterverzeichnisse "etc" und "usr". Darüber
>> ein "grep -r /share/systemd" ausgeführt liefert kein Ergebnis.
>> 
>> Suchen wir hier an der richtigen Stelle? Selbst wenn diese misslungene
>> Installation Ursache für den Fehler ist - wie stehen die hier gewonnenen
>> Dateien im Zusammenhang mit einem User-Login? Müssten wir nicht
>> eigentlich im Bereich systemd irgendwie fündig werden?
> 
> 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 /root/tmp/x /usr/local/share/systemd/user

Typo:

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.
> 
> Ob das bei dir die Ursache ist, sagt das nicht, du hast ja auch schon
> gesagt, dass es /usr/local/share/systemd/user bei dir nicht gibt.
> 
-- 
Gruß Marcus
[eisfair-Team]



Mehr Informationen über die Mailingliste Eisfair