Kein Überschreiben möglich auf einem Linux Mount

[Shark321]

Ich nutze die Open Source WinFsp und SSHFS-Win um das Filesystem meines Linuxservers als Laufwerk unter Windows zu mounten. Nach dem Mounten (Schreibaccess) ist es das Windows Laufwerk U:\.

In Total Commander 9.21a gibt es ein Problem mit diesem Laufwerk. Beim Überschreiben von Dateien bekommt man ein Access Dienied. Man muss die Dateien Löschen, erst danach kann man sie kopieren. Im Windows Explorer funktioniert das Überschreiben auf dem Laufwerk hingegen einwandfrei. Ich kann sogar die Dateien per Drag & Drop von Total Commander zum Explorer erfolgreich überschreiben.

[Dalai]

Wie sehen die Berechtigungen der Zieldateien aus? Lassen die ein Überschreiben der Dateien zu? Welche Kopiermethode ist im TC bei dir eingestellt (siehe Konfigurieren > Einstellungen > Kopieren/Löschen)? Ändert sich etwas, wenn du dort das Laufwerk in der Liste für den Kompatibilitätsmodus ergänzt?

Grüße
Dalai

[Shark321]

Es gibt unter Linux nur Schreibrechte, keine Überschreibrechte. Diese sind vorhanden, sonst wäre kein Löschen möglich. Das Laufwerk ist eh als root gemounted.

Kompatilibitätsmodus bringt leider nichts.

Mit der Option "Use copy/paste via Explorer (only in case of copy problems)" funktioniert das Überschreiben, wie zu erwarten war. Allerdings ist das Kopieren dann langsamer.

[Dalai]

Es gibt unter Linux nur Schreibrechte, keine Überschreibrechte.

Naja, Begrifflichkeiten... Es gibt sowieso nur Schreibrechte, auch unter Windows (wenn mal das Recht "Anhängen" unter Windows mal außen vor lässt).

Diese sind vorhanden, sonst wäre kein Löschen möglich.

Das stimmt so nicht. Um eine Datei unter Linux löschen zu können, müssen für den Nutzer oder die Gruppe Schreibrechte auf dem Verzeichnis vorhanden sein, in dem die Datei liegt! Anders sieht es mit dem Ändern/Schreiben einer Datei aus, denn dann sind die Rechte der Datei selbst relevant.

Das Laufwerk ist eh als root gemounted.

Bist du sicher? Von welchem Linux reden wir? Was sagt das syslog und/oder auth.log des Linux-Systems, sowohl zum Login des Users als auch den Schreibaktionen?

Grüße
Dalai

[ghisler(Author)]

TC benutzt die Windows-Funktion CopyFileEx zum Kopieren. Offenbar bindet WinFsp das Laufwerk nicht sauber ein - wahrscheinlich haben die Entwickler nur mit dem Explorer getestet.

Sie können die Explorer-Kopiermethode auch im Total Commander verwenden, entweder von Fall zu Fall:
Strg+C, Tab, Strg+V
oder permanent für alle Laufwerke via Konfigurieren - Einstellungen - Kopieren/Löschen.

Allerdings hat diese auch Nachteile, z.B. weniger Optionen beim Überschreiben. Auch wird die Baumdatei für Alt+F10 nicht aktualisiert.

[Shark321]

Das Laufwerk ist sicher als root gemounted. Beim mounten wurde das Root password abgefragt und ich hab auch auf dem ganzen Volume Löschrechte. Es ist eine standard Debian 9.5 Installation.

Hab soeben noch Directory Opus und Free Commander getestet. Dort tritt das Problem, so wie im Explorer, nicht auf.

[Dalai]

Simpler Test: Modifiziere die Zugriffsrechte einer Datei direkt auf dem Linux-System, z.B. zu 0600 oder 0666 oder etwas ähnliches, das vom Standard abweicht. Dann überschreibe diese Datei mit dem Explorer, Free Commander oder DOpus. Prüfe nun die Zugriffsrechte der Datei. Sind die anders als vor dem Überschreiben, wurde die Datei gelöscht und neu angelegt. Sind sie immer noch so, wurde in die Datei geschrieben. Gerade letzteres bezweifle ich.

Und noch ein simpler Test: Ändere die Zugriffsrechte auf 0400 und versuche dann, die Datei mit dem Explorer zu überschreiben. Klappt das nicht, hast du definitiv keine Rootrechte.

Grüße
Dalai

[Shark321]

Hab eine test.data erstellt und ihr die Rechte 666 gegeben. Nach dem Überschreiben mit dem Explorer bleiben die Rechte bei 666.

Habe danach die Rechte auf 400 geändert. Explorer kann die Datei nicht mehr überschreiben. Gelöscht werden kann sie. Auf dem Linux Server gibt es nur den Root user, sonst keinen. Der SSH Mount geht über login/pwd vom Root user.

[Dalai]

OK, also wird in die Datei geschrieben. Das ist interessanterweise das Gegenteil dessen, was ich annahm. Meine Annahme war, dass Explorer die Datei löscht und neu erzeugt während TC in die Datei schreibt.

Welcher Nutzer/Gruppe wird denn auf Windows-Seite als Besitzer angezeigt, und wie sehen die Zugriffsrechte von dort aus? Ist in den Tools auf Windows-Seite (WinFSP, SSHFS-Win) etwas einzustellen?

Ergänzung:
Aus Neugier hab ich WinFSP und SSHFS-Win von hier runtergeladen und in einer VM installiert, und stelle fest, dass das Zeug irgendwie total verbuggt ist. Testsysteme: Win7 x64 und Ubuntu 14.04. Administrator auf Windows-Seite (UAC deaktiviert), Nutzer wartung auf Linux, Netzlaufwerk verbunden als S: mit dem Home des Nutzers wartung. Fehler, die mir innerhalb der ersten wenigen Minuten aufgefallen sind:

• Das Verbinden des Netzlaufwerks klappt nur im TC x64, im Explorer und in einer 64-bit CMD. Alle 32-bit Programme wie TC 32-bit, 32-bit CMD finden den Netzwerkpfad nicht. Das liegt wohl daran, dass die von WinFsp mitgebrachten Dienste 64-bittig sind.
• Das verbundene Netzlaufwerk S: wird im TC 32-bit und Free Commander 32-bit als "nicht verbunden" angezeigt, der Zugriff funktioniert aber.
• Beim Kopieren einer simplen Datei, die auf Laufwerk S: nicht existiert, führt selbst im Explorer zu einer Bestätigung zum Überschreiben, weil die Datei angeblich bereits vorhanden ist. Dabei ist es völlig egal, ob Copy'n'Paste oder "Senden an" benutzt wird. In einer CMD kommt keine Bestätigung.
• Das Kopieren von Dateien funktioniert im TC gar nicht, außer per Copy'n'Paste, dann aber ebenfalls mit Bestätigung zum Überschreiben.

In dem Zustand würde ich davon Abstand nehmen und lieber auf SFTP setzen.

Übrigens lassen sich weitere Details zum Verhalten dieser Software ermitteln, indem die Zeile zum SFTP-Subsystem in /etc/ssh/sshd_config geändert wird zu

Code: Select all

Subsystem sftp /usr/lib/openssh/sftp-server -l INFO

mit anschließendem Neustart des SSH-Servers. Danach kann man sich die gesendeten Befehle und deren Rückgaben in /var/log/auth.log anschauen.

Grüße
Dalai

[Shark321]

Die von dir beschriebenen Probleme hab ich nicht, also z.B. keine Meldung vom Explorer, dass er überschreiben soll wenn Datei noch nicht existiert.

Könnte an dem Zusammenspiel mit Ubuntu 14.04 liegen, vielleicht auch an Win 7 (hab 10), ist ja beides ziemlich alt.

Oder daran dass ich es nicht per command line einbinde (habe da von Problemen gelesen) sondern über den Windows Mount Dialog:

This PC -> Rechtsklick -> Map Network Drive -> \\sshfs\user@server!port\path

z.B: \\sshfs\root@homelinux\..\..

Danach wird man nach password gefragt.

p.s.

Vor WinFSP und SSHFS-Win hab ich zwei kommerzielle Tools getestet die das Gleiche machen und da hatte ich nur Kopfschmerzen. Zu 60% funktioniert gar nichts, keine Connects etc. Dafür haben sie 20 nützliche Optionen. Z.B. https://www.nsoftware.com/sftp/netdrive/ (kostenlos für Heimnutzung). Angefangen hat das gleiche überhaupt mit dem SFTP Plugin für Total Commander (zu schlechte Performance, etwa 23 mb / sek beim kopieren, SSHFS schafft 100).

[Dalai]

Es spielt keine Rolle, ob das Netzlaufwerk per "net use" oder per Explorer/TC x64 "Netzlaufwerk verbinden" verbunden wird. In beiden Fällen verbinde ich \\sshfs\wartung@192.168.0.95 als Laufwerk S: und das Ergebnis ist dasselbe: Zugangsdaten werden abgefragt und das Laufwerk dann verbunden. Das Verhalten beim Kopieren ist in allen Fällen gleich, auch mit Win10 1709, auch mit Ubuntu 16.04. Wenn nach so kurzer Zeit so viele Fehler erkennbar werden, hab ich schon keine Lust mehr, das weiter zu untersuchen oder zu benutzen (davon kann eh keine Rede sein, in dem Zustand).

Beim Kopieren einer Datei mit TC wird übrigens eine leere Datei mit 0 Byte angelegt, bevor die Fehlermeldung "Zugriff verweigert auf Zieldatei" erscheint.

[EDIT]
Wenn du schlechte Performance mit dem SFTP-Plugin im TC hast, solltest du in den Optionen der Verbindung SCP für Transfers aktivieren.
[/EDIT]

Grüße
Dalai

[Shark321]

Es ging mir nicht um net use. Es gibt noch eine command line ohne net use wo du mehr Parameter eingeben kannst (z.B. sshfs.exe root@host:/ y: -o StrictHostKeyChecking=no -o password_stdin). Dachte du verwendest ssfs.exe direkt. Hab heute noch kurz mit einer Ubuntu 18.04 VM getestet, und keine Probleme festgestellt.

Edit: Kann es sein dass du eine ganz alte Version verwendest? Ich nehme die Files direkt vom Github: https://github.com/billziss-gh/sshfs-win/releases

[Dalai]

Edit: Kann es sein dass du eine ganz alte Version verwendest?

Ich hatte ja bereits verlinkt, was ich runtergeladen hatte.

Ich nehme die Files direkt vom Github: https://github.com/billziss-gh/sshfs-win/releases

Beta-Versionen verwende ich generell nur in Ausnahmefällen, z.B. wenn ich die Software kenne oder bewusst eine Beta teste. Insofern: Vielleicht sind die von mir geschilderten Bugs in der Pre-Release-Version behoben, bis auf die Geschichte mit der Nullbyte-Datei mit anschließendem "Zugriff verweigert" im TC.

Grüße
Dalai

[Shark321]

Hab mal testweise auf 2.7 downgraded, und immer noch keine Probleme, daran liegt es also nicht.

[Dalai]

Sofern du ein Pre-Release beider Pakete (WinFSP und SSHFS-Win) verwendest, musst du auch beide ändern.

Das Problem in Verbindung mit TC wird sich nicht lösen lassen, fürchte ich. Jedenfalls nicht, solange die Situation mit WinFSP und SSHFS-Win so ist.

Grüße
Dalai