Hallo zusammen,

ich habe die pacman.conf mit der pacman.conf.pacnew durchgearbeitet und die Optionen, die in meiner alten Konfiguration anders waren - sofern sinnvoll - übernommen. Viel war es nicht, aber Spielereien wie 'ILoveCandy' müssen einfach dabei sein 🙂 . Allerdings habe ich seinerzeit auch den Pacman-Cache auf ein anderes Verzeichnis verbogen und mich nun gewundert, dass ein Aufruf folgenden Effekt hat:

:: Pakete werden empfangen …
Fehler: Konnte Datei /home/xxxxxx/Daten/Pacman/Cache/pkg/download-yzSGC2/signal-desktop-7.26.0-1-x86_64.pkg.tar.zst.part nicht öffnen: Keine Berechtigung
Fehler: gescheiterte Einstellung der Downloadmenge für signal-desktop-7.26.0-1-x86_64.pkg.tar.zst
Warnung: Konnte einige Dateien nicht übertragen
Fehler: Der Vorgang konnte nicht durchgeführt werden (Konnte manche Dateien nicht übertragen)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Es muss mit dem Download User alpm zu tun haben, denn wenn ich diese Zeile mit # maskiere, geht die Aktualisierung durch, auch bei Nutzung 'meines' Cache Verzeichnisses.
Stelle ich bei aktiviertem alpm-Nutzer die pacman.conf so ein, dass das Defaultverzeichnis für den Cache genutzt wird ist alles ok. Im Prinzip scheint die Meldung klar zu sein - Berechtigung fehlt, um ein Unterverzeichnis anzulegen. Allerdings habe ich die Rechte an den genannten Verzeichnissen schon nachgesehen, scheint mir aber alles im Prinzip 'offenherzig' genug zu sein. Und selbst wenn ich die Berechtigungen testweise so setze, dass jeder User ändern darf, bleibt der o.g. Fehler.
Jetzt frage ich mich, wo ich gerade auf dem Schlauch stehe und was ich Offensichtliches gerade nicht sehe. Vielleicht kann mir da jemand einen Tipp geben?

LG
Stephan

  • GerBra hat auf diesen Beitrag geantwortet.

    Ja, das ist mir bekannt. Ich habe diese Befehle auch auf mein Cache Verzeichnis angewendet, jedoch blieb das Verhalten wie beschrieben. Vielleicht habe ich irgendeinen dummen Fehler gemacht, manchmal ist "Schussel" mein zweiter Vorname. 😉
    Ich gehe nachher alles nochmal durch....

    waldbaer59 Stelle ich bei aktiviertem alpm-Nutzer die pacman.conf so ein, dass das Defaultverzeichnis für den Cache genutzt wird ist alles ok. Im Prinzip scheint die Meldung klar zu sein - Berechtigung fehlt, um ein Unterverzeichnis anzulegen.

    Die Meldung besagt vornehmlich, daß nicht in das Verzeichniss (mit der Datei) zugegriffen werden kann mit dem alpm User.
    Es dürfte also am execute (x) Flag liegen. Damit eine Datei in einem Verzeichnis überhaupt gelesen oder geschrieben werden kann ist beim Verzeichnis das x-Flag nötig (du darfst "rein"(execute) und dann im Dir etwas machen).
    Das gilt für den gesamten Pfad (ab der Wurzel /) bis zum Ziel-Dir. Ich vermute, daß dein $HOME, also /home/xxxxxx den Zugriff (x) nur für den User (+rw) und ggf. für die Gruppe erlaubt. Das ist auch sehr sinnvoll und richtig. Der alpm User dürfte also unter "other" fallen und kommt dort gar nicht rein (kein execute), somit auch nicht "tiefer".

    Den pacman Cache in ein $HOME zu legen ist IMHO sowieso suboptimal.

    Zwei Möglichkeiten, ohne dein $HOME "aufmachen" zu müssen:
    a) den Cache nochmal zu verlagern, auf jedenfall außerhalb der Home-Verzeichnisse (oder ein eigenes Home für den User alpm und den Cache da rein).

    b) Auf dieses neue Feature verzichten. Ich habe sowohl die Option DownloadUser als auch DisableSandbox nicht aktiv und nutze meinen per NFS-Freigabe verfügbaren pacman-Cache wie gewohnt.

    Ich verstehe den Sinn dieses Feature auch nicht wirklich, warum soll mein Normaluser die Möglichkeit haben Pakete in den Cache downloaden zu können? Entweder arbeiten ich als root (-Syu) oder per sudo (-Syu), beides braucht keine extra Berechtigungen/User für die Cache-Dateien. Ich sehe auch keinen Hinweis in der manpage was für den PreDownload jetzt anders sein soll als es -Syw nicht auch schon vorher konnte. Oder der PreDownload per checkupdates (wenn man es nutzt. //Edit: Ich tue es, wenn ich PreDownloaden will, v.a. da es mir meine Haupt-Sync-Datenbanken nicht verändert).

    //Edit2:
    Ich glaube, jetzt habe auch ich es kapiert ;-) Es geht nicht um PreDownloaden, sondern den Download-Vorgang während des Update-Prozesses nicht mit root-Rechten machen zu müssen. Einen Sicherheitsgewinn (oder Risiko) sehe ich darin trotzdem nicht wirklich...
    Bei meinem NFS-Share für den Paketcache könnte ich mir dadurch einen Export mit der no_root_squash Option ersparen. Trotzdem ändere ich nichts...