"verschwundene" Verzeichnisse bei cifs mount

[Theophil T.]

Hallo,

ich mounte von einem Debian-Server (Kernel 6.1.0-20-amd64, Samba 2:4.17.12+dfsg-0+deb12u1) ein Samba-Verzeichnis mit einem Debian-Client (bookworm), ebenfalls Kernel 6.1.0-20-amd64:

Code: Alles auswählen

# mount
//server/share on /mountpunkt type cifs (rw,relatime,vers=3.1.1,cache=strict,username=<name>,domain=<domain>,uid=1000,noforceuid,gid=1000,noforcegid,addr=<IP>,file_mode=0660,dir_mode=0770,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,_netdev)

Ich habe jetzt festgestellt, dass bei jedem mount-Versuch wechselnde Unterverzeichnisse der Freigabe auf dem Client verschwinden, auf dem Server sind sie mit korrekten Rechten vorhanden.

journalctl gibt auf dem Client Folgendes aus:

Code: Alles auswählen

Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: Autodisabling the use of server inode numbers on \\...........
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: The server doesn't seem to support them properly or the files might be on different servers (DFS)
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000a18bb84d
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000002b19fed0
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000e18517d1
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000005da0210f
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000caff39e8
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000a0276a78
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000226d34e0
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000ceee5bda
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000008bda50e4
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000be321c3f
Apr 16 14:33:13 tmx314 kernel: num_entries: 823 callbacks suppressed
Apr 16 14:33:13 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000bed690d6
Apr 16 14:33:13 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000008fd2da11

Einfügen der mount-Option "noserverino" bringt nichts. Der Fehler scheint seit ca. 1-2 Wochen zu existieren.
Wenn ich den Client mit dem Kernel 6.1.0-15-amd64 starte, ist der Fehler weg, andere Kernel habe ich noch nicht geprüft.

Eine Suche nach dem Fehler im Internet hat kein Ergebnis gebracht, könnte es sich um einen neuen Bug im Kernel handeln?

Theophil

[Theophil T.]

Auch ein 2. Client mit Debian Bookworm zeigt diesen Fehler, beide Clients arbeiten fehlerfrei nicht nur mit Kernel 6.1.0-15-amd64, sondern auch 6.1.0-18-amd64.

Ich denke, am ehesten ist das ein Bug, abhängig von der Kernel-Version. Da mir das hier schwerwiegend erscheint, werde ich versuchen, den passenden Ansprechpartner zu finden (pkg-samba-maint@lists.alioth.debian.org? debian-kernel@lists.debian.org?) und den Fehler melden.

Für alle die es hier interessiert noch mal zusammengefasst:

Mountet man eine Freigabe eines aktuellen Debian-Samba-Servers mit einem aktuellen Debian-Client, verschwinden auf dem Client einige Unterverzeichnisse und Dateien innerhalb der gemounteten Freigabe.
Die Rechte auf dem Server für die Dateien/Verz. sind unverändert gesetzt wie es notwendig ist, die Daten selbst sind auch unverändert auf dem Server existent.
Booten des Clients mit Kernel 6.1.0-15-amd64 oder 6.1.0-18-amd64 beseitigt dem Fehler.

Sambaserver, Debian Bookworm, Kernel 6.1.0-20-amd64, Samba 2:4.17.12+dfsg-0+deb12u1

# testparm
interfaces = 127.0.0.0/8 192.168.1.0/24
log file = /var/log/samba/log.%m
logging = file
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
preferred master = Yes
server min protocol = SMB2
server role = standalone server
unix password sync = Yes
usershare allow guests = Yes
workgroup = theo
idmap config * : backend = tdb

......
[daten-theo]
create mask = 0660
directory mask = 0770
force create mode = 0020
force directory mode = 0030
force group = theo
force user = theo
path = /daten/daten-theo
valid users = user1 user2 ...
write list = user1

Client ebenfalls Debian Bookworm, Kernel 6.1.0-20-amd64, cifs-utils 2:7.0-2
/etc/fstab:
....
//server/daten-theo /home/theo/daten-theo cifs vers=default,_netdev,credentials=/root/smbcredtheo,uid=theo,gid=theo,rw,file_mode=0660,dir_mode=0770,nofail 0 0
.....

Nach dem Start des Clients zeigt journalctl dort viele Zeilen wie:
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 00000000a18bb84d
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow frame end of buf 000000002b19fed0
......

Auf dem Server habe ich keine Fehlermeldungen gefunden.

[rhHeini]

Meine Meinung: Samba/cifs ist was für Windows-Clients, stell um auf nfs4 für die Linux-Clients.

[QT]

Mit Kernel 6.1.0 hatte ich bei Unstable auch so manches Problem mit CIFS Mounts. Unter anderem den ENOENT Fehler, der dann von coreutils notgedrungen gelöst wurde:

https://git.savannah.gnu.org/cgit/coreu ... 26bf548a7c

Das Problem wird dann Upstream schon längst gefixt sein, der Fix kam sicher noch nicht in einem Debian Stable an und wird es vielleicht nie. Problem kannst Du natürlich gegen das Stable Paket melden (reportbug).

[Theophil T.]

@QT:
Danke für den Hinweis, habe jetzt auch eine Meldung mit reportbug gemacht

@rhHeini:
Konsequenter wäre es ja, den Fehler zu beheben, derzeit boote ich als workaround mit Kernel 6.1.0-18-amd64.
nfs ist ein Dienst mehr, um den man sich kümmern muss und der Fehler produzieren kann, wie man auch hier sieht. Je weniger Software notwendig ist, desto besser.
Es könnte auch sein, dass sich bestimmte Rechte-Konstellationen auf Client-Seite mit nfs schwerer realisieren ließen, hab es jetzt nicht mehr genau in Erinnerung.

[Theophil T.]

Meine Meinung: Samba/cifs ist was für Windows-Clients, stell um auf nfs4 für die Linux-Clients.

Zu nfsv4 habe ich mich zwar oben wenig begeistert geäußert, aber dann doch aus Interesse nachgelesen. Der Export nur auf Basis der IP-Adresse und fehlende Benutzer-Authentifizierung am Server scheint nachteiliger als bei Samba zu sein, im LAN ggf. noch akzeptabel. Mit Kerberos habe ich keine Erfahrung, evtl. ist das für ein kleines LAN auch eine Nummer zu groß. Die Idee in einem Heise-Artikel, nfs über ssh zu tunneln, halte ich auf den ersten Blick für überlegenswert. Mal sehen, wie es mit meinem Samba/Kernel-Problem weitergeht....

[rhHeini]

Der Export nur auf Basis der IP-Adresse und fehlende Benutzer-Authentifizierung am Server scheint nachteiliger als bei Samba zu sein, im LAN ggf. noch akzeptabel.

Ich frage mich wie Du darauf kommst dass Du da ohne Benutzerauthentifizierung unterwegs bist. Das ist keineswegs der Fall.

Ich betreibe hier daheim seit Sarge einen kleinen Fileserver. Damals für 5 Personen, anfangs alles Windows-Clients, dann hab ich angefangen parallel dazu Debian zu probieren, seit 12 Jahren sind die Clienten per Default auf Linux, habe noch ein paar Windows-VMs und 2 Windows7-Rechner rumstehen die gelegentlich laufen (ohne Internetzugriff). Die Kinder sind inzwischen aus dem Haus, damit greifen nur noch 2 Personen aufs Netzwerk zu.

Der Server war von Anfang an so aufgesetzt dass die Daten auf mehreren Shares damals mit ext2 aufgeteilt wurden, die Shares liefen auf separaten SCSI-Platten. Habe da von Anfang an 5 User mit immer dem gleichen Schema aufgesetzt, ich die UID 1001, meine Frau die 1002, die Kinder 1003 bis 1005, und passende Gruppen. Diese User in Samba importiert und die Windows-Passwörter in Samba hinterlegt. Hard- und Software sind natürlich längst anders, das Basisschema ist aber gleich geblieben.
Die Linux-Passwörter sind auf dem Server und den Clients gleich. Wenn da ein File nicht die passenden Linux-Rechte hat kann der User auf dem Client zwar den Share öffnen, hat aber entweder nur Lese- oder keine Rechte auf Directories und Dateien. Wird durch entsprechende Optionen in den exports sichergestellt. Ich brauch hier kein Kerberos oder LDAP. Und die Linux-Clients haben immer nfs verwendet. Anfangs noch nfs3, seit es nfs4 gibt verwende ich nur noch das.

Du kannst auch im Kleinen Zugriffsrechte über nfs(4) sicherstellen.

[Theophil T.]

Der Export nur auf Basis der IP-Adresse und fehlende Benutzer-Authentifizierung am Server scheint nachteiliger als bei Samba zu sein, im LAN ggf. noch akzeptabel.

Ich frage mich wie Du darauf kommst dass Du da ohne Benutzerauthentifizierung unterwegs bist. Das ist keineswegs der Fall.
...............

Wenn ich die Artikel zu nfs richtig verstehe, werden die Daten stumpf an eine oder mehrere IP-Adressen exportiert. Die Zugriffsrechte werden durch die Rechte der Benutzer auf dem Server vorgegeben. Wenn die Client-Anfrage mit Client-seitigem "user1" erfolgt, erhält dieser die Rechte, die "user1" auf dem Server hat. So wie ich es sehe, mussten bis nfsv3 UID/GID auf Server und Client dazu übereinstimmen, ab nfsv4 reicht evtl. der gleiche Benutzername, also hier "user1". Eine Authentifizierung zwischen Client und Server findet nicht statt.
Die folgende Überlegung ist für ein kleines gut abgesichertes privates LAN vielleicht zu vorsichtig, aber: Ein Angreifer könnte eine System mit einer entsprechenden IP aufsetzen (Der richtige Client dürfte natürlich nicht laufen) und einem Benutzer mit gleichem Namen oder UID/GID, dann hätte er vollen Zugriff auf die exportierten Daten. U.a. darum gibt es wohl auch die Option "root_squash", damit root eines angreifenden Systems keinen Vollzugriff hat.

Bei Samba muss sich der Client-Benutzer, wie Du ja auch schreibst, mit seinem Passwort am Server authentifizieren, dies findet nach meinem Verständnis bei nfs nicht statt.

[rhHeini]

Du musst es wissen.

Für mich nehmen Deine Daten einen zweifachen Umweg. Die liegen auf einem Linux-Filesystem auf Deinem Fileserver. Beim Ausliefern verbiegst Du die über Samba zu einer nicht notwendigen Windows-Kompatibilität, die Dein Client auf Deiner Workstation wieder zurückkonvertieren muss auf Linux-Konventionen. Das dabei auch mal was auf der Strecke bleiben kann ....

nfs ist nativ Linux/Unix. Keep it simple stupid ....

[Theophil T.]

Du musst es wissen.

So würde ich es nun auch wieder nicht sagen.....
Ich verstehe halt die Manpages und einige Howtos so.

Die Frage nach der besten Wahl eines oder mehrerer Fileserver-Dienste wird wahrscheinlich jeder etwas unterschiedlich beantworten. Bei mir ist Samba wegen zweier notwendiger Windows-Clients erforderlich. Dann stehe ich vor der Frage: Alles mit Samba oder 2. Dienst? Was ist in der Summe mehr "simple stupid"?

Bis auf diesen Bug ist Samba bisher auch mit den Linux-Clients problemlos gelaufen, NFS als 2. Dienst bedeutete für mich den Extra-Aufwand, ihn einzurichten, und mir vielleicht NFS-spezifische Probleme, von denen ich noch nichts weiß, einzuhandeln. Die fehlende Authentifzierung bei NFS empfinde ich als Nachteil.

Aber wie oben schon angedeutet, werde ich ja vielleicht auch noch zu so einem NFS-Fan wie Du!

[rhHeini]

Falls Du keine öffentliche IP hast sondern hinter so etwas wie einer Fritzbox hockst: Für einen Angriff muss derjenige schon vor Ort sein. Der wird gleich die Rechner mitnehmen.

Schau Dir mal die nfs4-Option secure an.

[debilian]

Die fehlende Authentifzierung bei NFS empfinde ich als Nachteil.

Ohne Anmeldung am Rechner und die richtigen Rechte des nfs-shares
kommts du da auch nicht dran - somit ist da kein "Nachteil"

ich sehe es so wie rhHeini, smb nur für Mischstrukturen mit Windows Clients,
für reine GNU/Linux Netze; nfs

[Theophil T.]

Eigentlich sollte man fast die Diskussion zu diesem Punkt in einem eigenen Thread im Forum Dateiserver führen - ich möchte aber doch noch hier darauf antworten. Wie viel tatsächliches Risiko in einem bestimmten Szenario besteht, lasse ich dabei jetzt unberücksichtigt.

So wie ich die Dokumentationen verstehe, bräuchte ich als böser Bube nur einen zusätzlichen Rechner mit passender IP und passendem Benutzer ins LAN zu setzen und schon habe ich Zugriff auf die exportierten Daten. NFS deligiert die Authentifizierung an den Clientrechner. Falls der Export für das gesamte Subnet eingerichtet ist, reicht eine beliebige LAN-Adresse, sonst müsste ich vorher ein wenig probieren und die eigentliche Client-IP-Adresse dürfte nicht aktiv sein. Falls am Server "no_root_squash" eingestellt ist, brauche ich noch nicht einmal einen passenden Benutzer.
Dies ist gegenüber Samba ein prinzipieller Unterschied und somit schon ein Nachteil.

Wenn ich etwas mehr Zeit habe, werde ich mal eine VM aufsetzen und das testen.

[TRex]

Ich verwende ebenfalls smb für die Linux-Clients im Netz. NFS verhält sich äußerst eklig, wenn man ohne umount das LAN verlässt oder der Server aus anderen Gründen nicht erreichbar ist.

[Theophil T.]

Danke für den Hinweis!

Ein weiteres Problem (bei Freigabe des gleichen Datenbestandes über Samba und nfs) könnte noch entstehen, wenn 2 Clients gleichzeitig schreibend, der eine über Samba, der andere über NFS auf dieselbe Datei zugreifen. Einige Mitteilungen, die ich bei einer Suche im Internet gesehen habe, deuten zumindest darauf hin.