Page 1 of 1

Datei-Manager entfernt Execute-Rechte (x-Bit) beim Speichern

Posted: Fri 17. Apr 2026, 16:46
by Muesli
Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
Ja (Fehler tritt nur bei Nutzung von Keyhelp auf)


Server-Betriebssystem + Version
Ubuntu 22.04 (64-bit)


Eingesetzte Server-Virtualisierung-Technologie
VMWare


KeyHelp-Version + Build-Nummer
26.0 (Build 3618)


Problembeschreibung / Fehlermeldungen
Wenn ich eine Datei im Datei-Manager bearbeite, die Execute-Rechte hat, sind die Execute-Rechte nach dem Speichern weg.


Erwartetes Ergebnis
vorher:

Code: Select all

root@keyhelp:/home/users/powerbi/files/copy_data_to_powerbi# ls -l run_all.sh
-rwxr-xr-x 1 powerbi powerbi 1512 Apr 16 10:38 run_all.sh
nachher:

Code: Select all

root@keyhelp:/home/users/powerbi/files/copy_data_to_powerbi# ls -l run_all.sh
-rwxr-xr-x 1 powerbi powerbi 1512 Apr 17 16:31 run_all.sh

Tatsächliches Ergebnis
vorher:

Code: Select all

root@keyhelp:/home/users/powerbi/files/copy_data_to_powerbi# ls -l run_all.sh
-rwxr-xr-x 1 powerbi powerbi 1512 Apr 16 10:38 run_all.sh
nachher:

Code: Select all

root@keyhelp:/home/users/powerbi/files/copy_data_to_powerbi# ls -l run_all.sh
-rw-r--r-- 1 powerbi powerbi 1512 Apr 17 16:31 run_all.sh
(-rw-r--r-- ist das Problem, weil x-Recht jetzt fehlt)


Schritte zur Reproduktion
* Man nehme eine Datei, die Execute Rechte hat (in meinem Beispiel: /home/users/powerbi/files/copy_data_to_powerbi/run_all.sh)
* Einloggen als Administrator
* Benutzerverwaltung
* Benutzername aus der Liste anklicken (man ist jetzt als Benutzer angemeldet)
* Datei-Manager aufrufen
* Haus anklicken für Hauptverzeichnis
* files anklicken, um files-Verzeichnis zu öffnen
* copy_data_to_powerbi anklicken, um das Script Verzeichnis zu öffnen
* run_all.sh anklicken, um das Startscript zu bearbeiten
* Etwas am Script ändern und Speichern drücken
* Jetzt sind die Execute-Rechte weg


Zusätzliche Informationen
Ich glaube, es ist erst seit dem Update auf Keyhelp 26.0 so. Ich bin aber nicht sicher.
Als Workaround starten wir das Script zukünftig über /bin/bash in der crontab. Aber komisch ist das Verhalten schon.


.