ubuntuusers.de

Hallo community,

Verzeichnis: /var/log/ ––→ "Keine Berechtigung" (irgentwelche Protokolle anzulegen)

Ein bash script ausführen schlägt fehl , als Beispiel:

#! /bin/bash
{
echo "*** $(date -R) ***"
for MP in / /home     # <-- Anpassen auf die eigenen Bedürfnisse
do   /sbin/fstrim -v "$MP" || echo Fehler beim trimmen von $MP
done
} | tee >>/var/log/batched_discard.log

nach änderung des log-verzeichnisses erhalte ich folgende Fehlermeldung:

rodrigo@xxxxxx:~$ bash /etc/cron.hourly/batched_discard.sh
fstrim: /: FITRIM ioctl fehlgeschlagen: Vorgang nicht zulässig
fstrim: /home: FITRIM ioctl fehlgeschlagen: Vorgang nicht zulässig

wo liegt das problem bitte?

Systemarbeiten wie TRIM muss der Systemverwalter root ausführen und die Hardware muss natürlich auch mitspielen.

hallo kBkB schrieb:

Systemarbeiten wie TRIM muss der Systemverwalter root ausführen und die Hardware muss natürlich auch mitspielen.

ja,das ist mir klar. die bash ist als "root" (besitzer+gruppe) + ausführbar gesetzt. TRIM:z.b. 1x wöchentlich geht gar nicht ,da reagiert mein Rechner nicht mehr. 2x täglich würde auch reichen , muss auch nicht stündlich sein. 3 SSD's vorhanden.

aber das ich nicht mal eine log im "/var/log/" verzeichnis anlegen darf , obwohl ich Administrator bin , ist mir neu.

meinertreu74 schrieb:

die bash ...

Warum macht man denn so etwas?

mario@mario-Vivobook ~ > systemctl status fstrim fstrim.timer
○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
     Active: inactive (dead)
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)

● fstrim.timer - Discard unused filesystem blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Sat 2025-10-04 21:36:49 CEST; 10min ago
    Trigger: Mon 2025-10-06 01:26:22 CEST; 1 day 3h left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Okt 04 21:36:49 mario-Vivobook systemd[1]: Started fstrim.timer - Discard unused filesystem blocks once a week.
mario@mario-Vivobook ~ > 

@mylin

Na weil er unbedingt die SSDs schrotten will. 🤣

meinertreu74 schrieb:

TRIM:z.b. 1x wöchentlich geht gar nicht ,da reagiert mein Rechner nicht mehr. 2x täglich würde auch reichen , muss auch nicht stündlich sein.

aber das ich nicht mal eine log im "/var/log/" verzeichnis anlegen darf , obwohl ich Administrator bin , ist mir neu.

Gebe mal in einem CodeBlock die folgenden Befehl mit Ausgabe wieder:

$ touch /var/log/batched_discard.log
$ ls -l /var/log/batched_discard.log

Was du bei deinem Script eingestellt hast ist mir unklar. Offenbar rufst du als unprivilegierter User "rodrigo" ein Script auf, das in das geschützte Verzeichnis "/var/log" ohne sudo schreiben soll. Eventuell willst aber auch das SUID Flag nutzen. Das geht aus deiner Beschreibung leider nicht hervor. Zeige mal die Berechtigung deines aufgerufenen Scriptes:

$ ls -l /etc/cron.hourly/batched_discard.sh

Selbst wenn du ein nicht zu empfehlendes

$ sudo chmod 7777 /etc/cron.hourly/batched_discard.sh
$ sudo chown root:root /etc/cron.hourly/batched_discard.sh

gemacht hast, wird dein Script als user "rodrigo" ausgeführt und hat kein Recht, in "/var/log" zu schreiben. Du kannst dann aber ein "sudo tee" machen, damit es klappt.

Da du leider sehr wenig Informationen gibst, bin ich hier nur am rätseln, was du wohl meinen könntest.

hallo und danke Mylin , schon den fstrim.service abgefragt , war noch nie aktiv bei mir.

hallo und danke schwarzheit ,

Na weil er unbedingt die SSDs schrotten will. 🤣

Diese Aussage ist absoluter Schwachsinn !! 🤣🤣 Anscheinend sind noch viele auf diesem Planeten über den TRIM-befehl falsch informiert. Fakt ist: samsung ssd 840 pro (gekauft aug 2013) ca. 16,5 TBW von 75 TBW geschrieben und samsung ssd 850 pro (gekauft dez. 2014) ca. 16,9 TBW von 150 TBW geschrieben und beide laufen immer noch problemlos. Also der TRIM-Befehl dient nur dazu damit der Speicherkontroller weiß welche speicher-bereiche frei zur löschung sind oder speicher-bereiche sich verändern. die eigentliche Arbeit macht nur der Speicherkontroller , nur er löscht und managt die ssd , d.h. das OS kann nicht direkt auf die Daten zugreifen , nur der Speicherkontroller.

hallo und danke shiro

touch /var/log/batched_discard.log
ls -l /var/log/batched_discard.log

die beiden Befehle sind nutzlos ,weil diese LOG nie angelegt wurde.

ls -l /etc/cron.hourly/batched_discard.sh

Ausgabe vom Befehl:

rodrigo@xxxxxx:~$ ls -l /etc/cron.hourly/batched_discard.sh
-rwxr-xr-x 1 root root 223 Okt  4 16:03 /etc/cron.hourly/batched_discard.sh

so große Fehler kann ich dabei nicht gemacht haben , wenn aber doch dann bitte melden.

Um nicht noch weiter eure Zeit zu vergeuden , überlege ich mir diese Bash überhaupt zu löschen. Manuell die ganze Sache durchzuführen , ist auch kein Beinbruch. Schließe diesen Beitrag hiermit.

-rwxr-xr-x 1 root root 223 Okt 4 16:03 /etc/cron.hourly/batched_discard.sh

Leider hast du meinen Post nicht vollständig gelesen oder verstanden. Die Protection des Scripts zeigt "-rwxr-xr-x" und nicht, wie es nach dem "chmod 7777" korrekterweise

-rwsrwsrwt

lauten müsste. Weiterhin hast du im Script wahrscheinlich die Zeichenkette "tee" nicht in "sudo tee" abgeändert.

meinertreu74 schrieb:

hallo und danke Mylin , schon den fstrim.service abgefragt , war noch nie aktiv bei mir.

Doch doch, schau mal in deinen syslogs nach. Schonmal eine längere Startzeit als gewöhnlich wahr genommen? Der fstrim.timer hat die Laufbedingung ConditionPathExists=!/etc/initrd-release. Die initrd-release ist ein Symlink auf os-release und existiert nur während der initrd-Phase man os-release. Der Trim wird also bei Fälligkeit während der Startphase ausgeführt.