Hallo Forum,

auf einem UCS 3.2-3 versuche ich per CIFS einen SAMBA-Share zu mounten. Z.B. mit dem Kommando:
mount -t cifs //server2/shareA /mnt -o username=user1,password=geheim,rw
Dies klappt ansich. Doch Verzeichnisse in dem Mount werden mit falschem hardlinkcount angezeit:

ls -la /mnt/

total 4
drwxr-xr-x 2 root root 0 20. Aug 14:06 .
drwxr-xr-x 31 root root 4096 19. Jul 07:56 …
drwxr-xr-x 0 root root 0 11. Dez 2013 dir1

Dies führt dazu, daß einige Tools einen Fehler melden. Wenn man nun dieses Verzeichnis per SAMBA exportiert, werden
unter Windows diese Directories als Dateien mit Größe 0 Bytes angezeigt und ist somit nicht benutzbar.
Weitere mount-Optionen habe ich getestet und machen keinen Unterschied. Das Problem haben wir nur auf dem UCS-System. Alle anderen Server (verschiedenen Debian Versionen) zeigen das Problem nicht.
Im Netz findet man hierzu ein paar Meldungen und es sieht so aus, dass es sich um ein cifs-Modul Problem, also Linux-Kernel Fehler handelt. Als Workaround ist dann nur ein Kernelpatch zu finden. Gibt es einen anderen Fix für UCS?

Mit freundlichen Grüßen
Armin Schindler

Hallo,

von was für einem Samba-Server mounten Sie den Share? Welcher Kernel ist aktuell im Einsatz und welchen Kernel haben Sie “vorher” verwendet?
Gerne können Sie die Referenzen auf eventuelle Probleme mit dem CIFS Kernel-Modul auch hier verlinken.

Mit freundlichen Grüßen
Janis Meybohm

Hallo,

der SAMBA Server ist ein BUFFALO NAS System.
Der Kernel auf dem UCS ist 3.10.0-ucs73-amd64.
Ab welchem Kernel das Problem auftritt, kann ich nicht sagen da wir es erst jetzt festgestellt haben. Test mit anderen
Kernels auf dem UCS habe ich nicht gemacht, da es sich um ein Produktiv-System handelt.
Beispiele über die gefundenen Infos im Netz:
bugzilla.samba.org/show_bug.cgi?id=9346
serverfault.com/questions/491464 … cifs-drive

Mit freundlichen Grüßen
Armin Schindler

Hallo noch mal,

nachstellen kann ich dass die Verzeichnisse als “0 byte” angezeigt werden. Das ist allerdings auch in vorherigen UCS Versionen nicht anders gewesen.
Ich schätze daher das Problem ist nicht der CIFS mount (welcher nicht fehlerhaft oder anders als sonst ist) sondern der Re-Export des per CIFS gemounteten Share (bzw. der Zugriff eines Clients darauf).
Ich finde dazu eine Referenz im Kerbel Bugzilla unter: bugzilla.kernel.org/show_bug.cgi?id=52791

Gerne nehme ich das so als feature request auf wenn ich alles richtig verstanden habe.

Mit freundlichen Grüßen
Janis Meybohm

Hallo,

ich denke nicht, dass “0 byte” hier das Problem ist, sondern der hardlinkcount von 0. Dieser sollte bei directories immer
midestens 2 sein. Wie in dem Link von Ihnen geschrieben, ist das den meisten Programmen unter Linux egal, aber z.B. der
export über SAMBA macht dann Probleme.
Unabhängig von dem eigentlichen Problem bei uns, daß dieser re-export unter Windows nicht funktionsfähig ist, wird im Linux
der mount selbst auch zum Problem (auch ohne re-export mit SAMBA). Auf anderen Systemen ist dieser CIFS mount mit
korrekten hardlinkcounts vorhanden. Ursache ist also der CIFS-mount im UCS. Und wenn dieser funktioniert, klappt auch der re-export
mit SAMBA.

Mit freundlichen Grüßen
Armin Schindler

[quote=“arminsys”]ich denke nicht, dass “0 byte” hier das Problem ist, sondern der hardlinkcount von 0.[/quote] Stimmt, das ist blos meine zugegeben etwas nachlässige Formulierung der Darstellung von ls.

Ich schätze das die Disributionen/Systeme auf denen der hardlink count korrekt angezeigt wird einen neueren Kernel verwenden oder den entsprechenden Patch zurückportiert haben. Können Sie sagen welche Anwendungen, abgesehen von Samba, damit Probleme haben und wie sich diese äußern?

Mit freundlichen Grüßen
Janis Meybohm

Andere Anwendungen die dieses Verzeichnis nutzen habe ich bisher nicht und kann deshalb nichts definitives sagen.

Aber die normalen Shell-Tools reagieren hier schon seltsam:
Ein hardlink ansich ist in diesem CIFS mount erstellbar:
ln dir1/file1 .

Mache ich aber
find . -type f -name “file1” -exec ln {} . ;
was ja genau den gleich ln Befehl ausführt, erhalte ich:
ln: creating hard link ./file1 => ./dir1/file1: No such file or directory

Hallo,

vielen Dank.
Ich gebe das an die Kollegen in der Entwicklung weiter die das zu einer kommenden UCS Version noch einmal prüfen werden.

Sie können natürlich versuchen das CIFS Modul direkt zu patchen (debian-administration.org/ar … nel_module

Mit freundlichen Grüßen
Janis Meybohm

Ich habe nun das UCS mit einem aktuellen Ubuntu Kernel 3.13.0 ausgestattet.
Damit funktioniert es problemlos.