TrueNAS 25.04.2.4 Verschieben von Dateien keinerlei rw Berechtigungen

Uzer1510

Lt. Commander
Registriert
Feb. 2025
Beiträge
1.495
Hmm mir ist gerade aufgefallen wenn ich im TotalCommander nach Dateien suche in Verzeichnissen mir die als Liste anzeigen lasse und dann von einem Verzeichnis aus dem Server in anderes Verzeichnis auf dem TrueNAS Server move gehen alle Attribute verloren also ist kein rwx etc mehr vorhanden - gar keines.

Das muss ich dann als root fixen (user und gruppe stimmen aber mit apps:apps)

Kopiere ich die Datei aus dem Verzeichnis in ein anderes bleiben alle Rechte erhalten oder auch wnen ich von einem beliebigen anderen Verzeichnis dorthin move passt das auch mit den Rechten

Lediglich beim moven innerhalb des Serververzeichnisse geht das verloren.

Ist das nur bei mir so?

TrueNAS Scale 25.04.2.4, Samba, Win 11

Nichts für ungut snoogans aber jemand der in einem Technikforum wie Du NUR über seine Gefühle und Empfindungen redet als seien die was wichtiges und nichts inhaltlich beizutragen der kann nichts verlangen :D

Dass beim moven auf einem TrueNAS Server von share zu gleichem share per Samba Dateiattribute verlorengehen können ist sicher interessant - was Du über andere denkst interessiert niemanden am Ende vor allem keine TrueNAS Nutzer.

Denn das TrueNAS Verhalten führt dann nunmal zu dem Effekt bei mir dass man manuell eingreifen muss z.B. als root.

Da moven von anderen Quellen - auch von anderen Samba Quellen - funktioniert ohne dass alle Rechte verloren gehen denke ich ist das vielleicht auch keine Konfigurationssache - da ist dann moven natürlich technisch ein copy.

--------------------------------------------------

Ich habe das mal gerade wieder ausprobiert:

Moven OHNE die Ergebnisdateiliste funktioniert - nur aus der Ergebnisliste moven führt zum Verlust der Attribute. Auf meinem System lässt sich das problemlos wiederholen immer mit dem gleichen Ergebnis.

die amd* Datei gemoved per Samba vom Desktop-PC auf den Server (über TotalCommander Suche => Sucheregebnisliste)
die balena* Datei gemoved vom Server auf den gleichen Server Share (auch über TotalCommander auf dem Desktop-PC)

Die gemovete Datei selber ist immer in Ordnung - wenn man die rw(x) Rechte danach korrigiert auch wieder zugreifbar.

Da ich immer mal wieder die Suchergebnisliste von Totalcommander zum Aufräumen nutze werde ich wohl mal meine Dateiattribute jetzt nachschauen müssen denn merken tut man es ja erst beim Zugriff :D

-----

Ich hab mal nachgeschaut per
Code:
"find /mnt/tank -type f -perm 000"
und hatte 132 Dateien (tank ist mein sharename)

1760879015521.png


Da ich super viel mit TotalCommander arbeite und auch mit den "Suchergebnisfenstern" habe ich mein TrueNAS mal ergänzt und logge bei jedem reboot automatisch mit nach dem decrypten ob und wie viele Dateien davon bei mir betroffen sind - und natürlich um das auch immer zu fixen.

Code:
echo "=================================================" >> /root/fileattrchanged.txt && date >> /root/fileattrchanged.txt && find /mnt/tank/crypted -type f -perm 000 -print -exec sh -c 'echo "Angepasst: $1"; chmod 666 "$1"' _ {} \; >> /root/fileattrchanged.txt
 
Zuletzt bearbeitet:
Liegt m.E. an TC. Wenn ich verschiebe über den Windows-Explorer, bekomme ich eine Sicherheitswarnung der Interneteinstellungen. Drückt man dann auf ok, wird normal verschoben.
 
Ich finde das halt komisch dass das nur passiert wenn ich aus der Suchergebnisliste move - wenn ich aus dem "normalen" Dateilisten Fenster genau die gleiche Datei verschiebe bleiben die rw-rw-rw Werte erhalten.

Mich wundert halt was ist da anders? beides sollte doch der gleiche SMB Move Befehl sein der an den TrueNAS Server geht?

Vielleicht schau ich mal ob man samba irgendwie in den debug modus bringen kann.

Mir ist das auch nur deshalb zufällig aufgefallen weil ich die Datei nach dem Sortieren und Verschieben aus dem Listfenster aufrufen wollte - aber nichts ging.

Vielleicht hat ja jemand die gleiche = aktuellste TrueNAS Version und auch den Total Commander damit ich sehe liegt das an meinem System oder ist das allgemein.
 
MMn Bug in TC bzw. einfach nicht implementiert. Vielleicht mal bei den Machern oder der Community (falls es eine gibt) von TC anfragen.
 
Hmmm aber TC wird doch nicht auf TrueNas Seite die Dateiattribute ändern können?

Wie gesagt wenn ich nicht aus der Suchliste move die gleiche Datei vom gleichen Verzeichnis in ein anderes mit TC bleiben die erhalten.

Wnen niemand diese Kombination Win 11 + TC ü+ Aktuelle TrueNAS Installation auch nutzt muss ich halt wohl mal slebr einen zweiten Rechner mit einem anderen Win installieren um zu sehen ob das an Win oder an TrueNAS liegt.

Evtl ändere ich auch auf einem meiner Server die TrueNas Version dann zum testen.

Dachte nur evtl hat sowieso halt jemand auch die Kombination im Einsatz.
 
Wenn ich über den Windows-Explorer was in TrueNAS von einem in ein anderes Verzeichnis verschiebe, bekomme ich diese Meldung:

Screenshot 2025-10-20 140431.png


Das System hat also wohl Bedenken, was die Rechte der Datei anbelangt. Meine Vermutung bei dir ist, dass TC irgendwie in dem genannten Ansichtsmodus dich die Operation nicht als Admin ausführen lässt bzw. die Rechte aus Sicherheitsgründen entfernt werden.

Oder mal anders: Warum sollte es TrueNAS interessieren, aus welchem Ansichtsmodus in TC du die Operation initiierst bzw. wie soll es das wissen? TN erhält einfach einen bestimmten Befehl, den es umsetzt.
 
Naja aber Total Comamnder kann ja nicht einfach Dateiattribute auf einem Linux Server ändern?

Das kann ja nur root oder der Besitzer der Datei (hier apps:apps) nur die Unix User goibt es ja auf Windows

Das MUSS auf TrueNAS Seite sein - Total Commander unter Windows ist sicher kein universelles Hackertool mit dem man auf einem Linuxrechner root Operationen ausführen kann - apps:apps hat keinen login.

Die Rechte von rw-rw-rw auf --------- lassen sich doch nur ändern von user oder root und zwar auch nur auf dem TrueNAS Linux System - wenn das anders von aussen ginge wäre Linux doch vom Sicherheitsapket her komplett tot?

Ich hab mal ein 2. System mit WIndows 11 am Laufen und werde mal testen was da passiert.

Wenn das bei alle Move Commands so wäre würde ich sagen jo das ist in samba etc was falsch oder irgendwelche anderen Settings - aber ich habe das nur bei der einen Funktion bisher wenn das aus der Ergebnissuchliste passiert.
 
Zuletzt bearbeitet:
Uzer1510 schrieb:
Naja aber Total Comamnder kann ja nicht einfach Dateiattribute auf einem Linux Server ändern?

Die Sache läuft mit über deinen PC. Wenn du über TC eine Datei in TrueNAS verschiebst, passiert das nicht autonom in TrueNAS; das läuft über deinen PC. M.E. läuft es doch so ab:
  • Du gibst den Befehl zum Verschieben.
  • Die Datei wird auf deinen PC kopiert.
  • Die Datei wird in TrueNAS gelöscht.
  • Die Datei wird von deinem PC in TrueNAS neu angelegt (an anderem Ort).

Wenn du nun das Recht hast, die Datei von Windows aus mit deinem Benutzer in TrueNAS zu erstellen (also Admin-Rechte hast bzw. sudo ausführst), kannst du m.W. nach auch deren Rechte festlegen.


Uzer1510 schrieb:
Das MUSS auf TrueNAS Seite sein

TrueNAS erhält doch aber nur einen Befehl; dass eine Datei geschrieben und dann eine andere Datei gelöscht werden soll. Für mich macht es nach wie vor keinen Sinn, dass es an TrueNAS liegen soll, wenn der Ausgangsunkt eine unterschiedliche Ansicht bzw. Auflistung der Dateien in TC ist.
 
Zuletzt bearbeitet:
Es war auf TrueNAS Seite hehe ich hab ChatGPT gentutzt das hat ein Haufen Anpassungen mittel CLI und nfs4xdr_setfacl an den ACLs gemacht und an den Shares selber jetzt tut es.

ChatGPT meinte moven innerhalb eines eines ZFS-Share mittels SAMBA mit FileAttr Verluste ... kenn ich hold my beer :D

Hat schon echt einige Anpassungen vom ZFS gebraucht viel zu viel für hier dneke ich und sicher auch vermutlich nur für mein System relevant - aber jetzt tut es - das war echt nerVIg und auch keine Ahnung wieso das nun aufgetreten ist, die Server laufen schon seit glaub nun 3 Jahren auf TrueNAS und ich sortiere schon immer über Windows und SMB-Shares.

Hehe ich lass mein "check script" trotzdem erst mal noch ne Weile beim booten laufen damit ich sehe ob das wieder auftritt aber die bisherigen Tests waren ohne Befund.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Banned
Zurück
Oben