staging.inyokaproject.org

Hallo Ubuntuusers,

ein seltsames Problem, an dem ich schon einige Tage (leider ohne Erfolg) arbeite, möchte ich hier beschreiben.

Ich habe einige identische Dateien, die in einem Ordner einer Samba-Verbindung anders angezeigt werden als in einem anderen Ordner der selben Verbindung.

Beide Versionen der selben Dateien sind auf dem Server als Datei vorhanden und werden im Client in einem Ordner als Ordner, im anderen Ordner als Datei angezeigt.

Die betrifft sowohl *.xcf, *.png, *.html, *.ods *.txt als auch *.pdf - Dateien:

Das seltsame ist, dass teilweise andere Dateien des gleichen Typs die im gleichen Ordner vorhanden sind richtig angezeigt werden.

Das fällt mir auf, seit ich auf Ubuntu 20.04 upgedatet habe.

Beide Rechner laufen aber identisch unter 20.04 und mit Samba 4.11.6

Das Problem wirkt sich dabei besonders auf den Datenabgleich mit Grsync aus. Das Abgleichen der Dateien, die als Ordner angezeigt werden bricht mit der Fehlermeldung ... is not a folder (20) ab.

Vielleicht hat ja jemand schon mal so etwas erlebt und kann mir helfen.

Als Beispiel füge ich noch zwei Bilder der Eigenschaften einer dieser Dateien bei.

MfG L-H

Wie greifst du auf die Freigabe zu? Per gio oder mount.cifs?

Das Problem gab es hier schon mal (allerdings in Kombination mit der Fritzbox - meine ich mich jedenfalls zu erinnern).

chr123 schrieb:

Wie greifst du auf die Freigabe zu? Per gio oder mount.cifs?

Normalerweise stelle ich die Verbindung vom Notebook zum PC direkt mit Gigolo her. Gigolo benutzt meines Wissens Gio. Aber auch, wenn ich direkt in Nautilus über die Eingabe: smb://Server/Freigabe verbinde werden die Dateien als Ordner angezeigt.

Das gleiche ist der Fall, wenn ich im Nautilus auf die "Windows-Freigabe" klicke, die in "Andere Orte" unterm PC angezeigt werden.

mount.cifs ⇒ kenn ich nicht, habe ich noch nie benutzt.

Gruß und schöne Weihnachten und vielen Dank an alle, die mir bisher hier geholfen haben.

Leo-Hubert

mount.cifs ⇒ kenn ich nicht, habe ich noch nie benutzt.

Dann könnte man testen, ob mit mount.cifs auch das Fehlerbild auftritt.

1

sudo apt install cifs-utils

1
2

mkdir ~/test_123 #erstellt den Ordner test_123 in deinem home
id #deine User ID ermitteln

sudo mount -t cifs --verbose -o username=abc,uid=1000 //192.168.a.b/FREIGABE ~/test_123

Die gelben Markierungen jeweils noch korrekt anpassen.

• abc = deine Benutzer auf dem NAS

• 1000 = siehe Ausgabe von id

• IP inkl. Freigabename = noch anpassen

Dann sollten in deinem Home unter test_123 die Dateien sichtbar sein.

chr123 schrieb:

Dann könnte man testen, ob mit mount.cifs auch das Fehlerbild auftritt.

Habe ich gerade getestet.

Das Fehlerbild ist auch mit mount.cifs das Selbe.

Gruß L-H

Update!

Zusätzliche Informationen: Ich habe jetzt mal noch einiges getestet. Die betroffenen Dateien sind innerhalb eines Ordner-Systems, das sich als Kopie eines anderen Ordnersystems erstellt habe. Die Dateien im originalen Ordnersystem werden alle korrekt angezeigt. Auch wenn ich die betroffenen Dateien aus dem original-Ordnersystem erneut in das neue Ordnersystem kopiere bleibt die Anzeige weiterhin falsch. Auf dem "Server" wird alles richtig angezeigt. Auch, wenn ich auf dem Server eine der betroffenen Dateien öffne und unter anderem Namen speichere, wird diese neue Datei falsch angezeigt.

Ich hatte das vorher schon mal mit *.odb-Dateien, die ich mit ARC geöffnet, bearbeitet und wieder geschlossen hatte. Dort war das Beheben des Problems dadurch möglich, dass ich die betroffenen Dateien erneut in ARC öffnete und dann mittels speichern unter.. mit neuem Namen speicherte. Nach dem Umbenennen dieser Datei (zurück zum alten Namen) war dort das Problem behoben. Diese Methode funktioniert aber bei den nun betroffenen Dateien nicht.

Irgendwie wird vom "Client" aus bei den betroffenen Dateien die Inode für einen Ordner erkannt, obwohl es sich um eine Datei handelt.

Vielleicht helfen diese Informationen noch weiter...

Gruß L-H

Hallo Ubuntuusers,

ich habe das Problem nun (hoffentlich dauerhaft) selbst lösen können. Was nun letztendlich der Auslöser war, kann ich allerdings nicht sagen.

Für alle, die mal ein ähnliches Phänomen beobachten, hier meine Lösung: Alle folgende Tätigkeit wurden im "Client" mit dem verbundenen Laufwerk ausgeführt.

Zunächst die vorgefundene Situation:

Die Ausgangs-Situation war ja die, dass innerhalb dieser Verbindung mehrere Unterordner mit unterschiedlichen Namen (Datenbank, Datenbank_Test und Datenbank_leer) vorhanden waren, in denen identische Unterverzeichnisse und darin enthalten auch identische Dateien vorhanden waren. In einem dieser Ordnersysteme (Datenbank_leer) wurden in zwei Unterordnern (/eingebundene und /Symbole) manche (nicht alle!!) Dateien als Ordner und nicht, wie es richtig gewesen wäre als Datei angezeigt. Ein Abgleich dieser Dateien war mit rsync und Grsync nicht mehr möglich.

Folgende Schritte habe ich für jede betroffene Datei zur Behebung durchgeführt:

• 1. In einem Ordner, in dem die Datei richtig dargestellt wurde (Datenbank) diese Datei kopiert

• 2. Im Ordner, in dem die Datei als Ordner dargestellt wurde (Datenbank_leer) diese Datei eingefügt.

      Dadurch änderte sich zunächst nichts, auch der Ablauf des Kopiervorgangs wurde nicht dargestellt.
      Es war nun aber möglich, die als Ordner dargestellte Datei zu löschen.

• 3. Die als Ordner dargestellte Datei (in /Datenbank_leer) dauerhaft gelöscht.

• 4. Im Ordner, in dem die Datei richtig dargestellt wurde (Datenbank) diese Datei wieder kopiert.

• 5. Im Ordner, in dem die Datei vorher als Ordner dargestellt wurde (Datenbank_leer) diese Datei eingefügt.

• Damit wurden alle betroffenen Dateien wieder als Dateien innerhalb der Laufwerksverbindung richtig angezeigt.

Auch nach einem Neustart beider Systeme sind nun die Dateien richtig angezeigt. Der Abgleich mittels rsync und Grsync ist wieder ohne Fehlermeldung möglich.

Vielleicht kann ja jemand aus meiner Erklärung auch den Auslöser für den Fehler erkennen. Dann könnte man so etwas in Zukunft vermeiden. Bei mir waren von diese Problem lediglich ca. 20 Dateien betroffen. Wenn der Umfang größer gewesen wäre, wäre unter Umständen auch der Arbeitsaufwand enorm gewachsen.

MfG L-H