staging.inyokaproject.org

Ich habe jetzt die Einleitung wie folgt geändert:

Beginn

Dieser Artikel betrifft das Einbinden von Windows- bzw. Samba-Freigaben als virtuelles Dateisystem CIFS vfs 🇬🇧 in das lokale Dateisystem des Clients. Dazu wird das Kernel Modul cifs.ko 🇬🇧 in Verbindung mit dem Programm mount.cifs 🇬🇧 genutzt. mount.cifs ist Bestandteil der cifs-utils 🇬🇧. In vielen Fällen bietet auch das GVfs eine einfachere Alternative zum CIFS vfs (siehe hierzu gio mount und Samba Client GNOME). Im Vergleich zum GVfs, das von den gtk-orientierten Dateimanagern (z. B. Nautilus oder Thunar) zum Einhängen entfernter Orte verwendet wird, unterstützt das CIFS vfs mehr Optionen des jeweiligen SMB-Protokolls. Allerdings können ins CIFS vfs nur einzelne Freigaben eingehängt werden. Man kann damit nicht ganze Server oder das gesamte Netzwerk als Orte einhängen und auf diesen browsen.

Ende

Damit sind alle Schlagwörter (wie Kernel Modul, cifs-utils, mount.cifs, CIFS vfs, ...) aufgeführt.

chr123 schrieb:

[…]

Dies ist noch ein wenig inkorrekt:

Dieser Artikel betrifft das Einbinden von Windows- bzw. Samba-Freigaben […]

Es geht ausschließlich um SMB-Freigaben (wenn man in SMB in großzügiger Weise auch CIFS und Vorgänger mit einschließt.). MS-Windows hat kein Monopol auf SMB, auch wenn das mache gerne so wünschen und darstellen. Dagegen kennt Windows durchaus spezifische eigene SMB-ähnliche, aber zu SMB inkompatible Freigaben, z.B. die berüchtigte HOMEGROUP bei Windows 7. (Welche mit Linux überhaupt nicht funktioniert.)

Deshalb Vorschlag:

• Dieser Artikel betrifft das Einbinden von SMB-Freigaben von z.B. Windows- und Samba-Servern …

Ich bin mir auch unsicher über die angemessene Schreibweise: CIFS vfs. CIFS VFS, CIFS Vfs, CIFS-VFS (meine Präferenz), …

Sonst gut!

kB schrieb:

Es geht ausschließlich um SMB-Freigaben (wenn man in SMB in großzügiger Weise auch CIFS und Vorgänger mit einschließt.).

Deinen Vorschlag finde ich gut.

Ich bin mir auch unsicher über die angemessene Schreibweise: CIFS vfs. CIFS VFS, CIFS Vfs, CIFS-VFS (meine Präferenz), …

Da bin ich leidenschaftslos. Wenn man sich an GVfs als Referenzbezeichnung für virtuelle Dateisysteme orientiert, dann müsste man wohl CIFS Vfs wählen 😇

Ich habe jetzt überall CIFS vfs hinterlegt. Dazu habe ich die aus meiner Sicht unnötigen Teile entfernt (Verweise auf die smb.conf, die von mount.cifs nicht berücksichtigt werden, Verweise auf die SMB Protokollversion, ...) sowie Straffungen vorgenommen. Das einzige, was jetzt noch fehlt, wäre aus meiner Sicht eine Umbenennung der Artikels in mount.cifs.

Hallo,

Artikel ist umbenannt, Backlinks sind korrigiert, Redirect angelegt.

Gruß, noisefloor

Kleine Änderungen im Satz:

Möchte man zur besseren Übersichtlichkeit trotzdem lieber Namen ("Netbios-Namen") verwenden, müssen diese entweder vom Domain Controller bereitgestellt werden oder auf dem Client in einer der Dateien /etc/samba/lmhosts (nötigenfalls anlegen) oder /etc/hosts eingetragen sein.

• Es gibt durchaus noch andere Möglichkeiten für eine funktionierende Namensauflösung per Netbios, das würde aber diesen Artikel sprengen. Bei mir funktioniert es z.B. ganz ohne winbind, lmhosts und Domain-Controler per Broadcast. Deshalb „können“ anstatt „müssen“.

• /etc/hosts ist nicht für Netbios vorgesehen, sondern ausschließlich für DNS-Namen. Deshalb gibt es ja /etc/samba/lmhosts für Netbios. Das (oft empfohlene) Ablegen von Netwios-Namen in /etc/hosts ist unsauberes Arbeiten und man sollte es im Wiki deshalb nicht empfehlen, sondern davon abraten.

Im folgenden Beispiel habe ich die Option _netdev mit Begründung ergänzt.

Ich bin jetzt ziemlich irritiert.

Früher führte mount.cifs im Gegensatz zum GVfs keinen Rundspruch zur Namensauflösung durch. Im Mount-Befehl musste deshalb statt des Netbios-Namens die IP des Servers direkt angegeben werden. Auf dem Client eingetragene DNS-Namen (eingetragen in /etc/hosts) oder Netbios-Namen (eingetragen in /etc/samba/lmhost) konnten aber statt der IP verwendet werden. Später (wann?) kam dann Avahi dazu.

Ich habe nie mehr überprüft, ob mount.cifs jetzt eine Namensauflösung wie das GVfs vornimmt, da bei mir immer die IP direkt eingetragen ist.

Offenbar stimmt das jetzt so nicht mehr (?). Ich habe versucht, mit mount.cifs über Netbios-Namen zu mounten. Das klappte ohne jeden Eintrag in /etc/hosts und ganz ohne /etc/samba/lmhost. Auch Avahi musste nicht bemüht werden.

Damit stimmt aber offenbar alles, was zum Thema Namensauflösung im Artikel mount.cifs geschrieben ist, so nicht mehr. Kann man jetzt grundsätzlich bei mount.cifs ohne Umstände statt der IP den Netbios-Namen verwenden? Dann wäre das Thema schnell erledigt.

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

Offenbar stimmt das jetzt so nicht mehr (?). Ich habe versucht, mit mount.cifs über Netbios-Namen zu mounten. Das klappte ohne jeden Eintrag in /etc/hosts und ganz ohne /etc/samba/lmhost. Auch Avahi musste nicht bemüht werden.

Den Absatz hatte ich als gegeben hingenommen. Aufgrund deiner Beschreibungen habe ich mal nachgeforscht. Leider findet man keine wirklich guten Beschreibungen, was mount.cifs konkret macht, um den Namen aufzulösen. Ich habe zu Testzwecken folgendes gemacht:

• hostname: rechner

$ hostnamectl status 

   Static hostname: rechner
...
  Operating System: Ubuntu 20.04.2 LTS
            Kernel: Linux 5.4.0-66-generic
      Architecture: x86-64

• netbiosname: NETBIOS-TEST (per smb.conf: netbios name)

$ nmblookup -A 192.168.1.58

Looking up status of 192.168.1.58
	NETBIOS-TEST    <00> -         B <ACTIVE> 
	NETBIOS-TEST    <03> -         B <ACTIVE> 
	NETBIOS-TEST    <20> -         B <ACTIVE> 
	..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> 
	WORKGROUP       <00> - <GROUP> B <ACTIVE> 
	WORKGROUP       <1d> -         B <ACTIVE> 
	WORKGROUP       <1e> - <GROUP> B <ACTIVE> 

	MAC Address = 00-00-00-00-00-00

• lmhosts: NETBIOS

$ cat /etc/samba/lmhosts 
192.168.1.58 NETBIOS

Also bewußt 3 verschiedene Namen gewählt. Anschließend per tcpdump den udp Traffic mitgeschnitten, der per mount.cifs entsteht:

$ sudo mount -t cifs --verbose -o guest,uid=1000 //NETBIOS-TEST/test ~/mount_cifs

mount error: could not resolve address for NETBIOS-TEST: Unknown error

$ $sudo tcpdump -eni any udp

192.168.1.58.33383 > 192.168.1.1.53: 51823+ [1au] A? NETBIOS-TEST.lan. (45)
192.168.1.1.53 > 192.168.1.58.33383: 51823 NXDomain 0/1/1 (120)
192.168.1.1.53: 51823+ A? NETBIOS-TEST.lan. (34)
192.168.1.1.53 > 192.168.1.58.33383: 51823 NXDomain 0/1/0 (109)

Offensichtlich fragt mount.cifs meinen DNS Server nach der IP in meinem lokalen Netz. Die Einträge in der lmhost bzw. per smb.conf (netbios name) werden von mount.cifs - in der Standardinstallation - nicht berücksichtigt. Bist du sicher, dass der netbios-name und der (DNS) hostname bei dir funktioniert?

Meine (unveränderte) nsswitch:

$ cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Also falls - wie bei mir - unter (X)Ubuntu 20.04 von mount.cifs doch ein Rundspruch durchgeführt wird, kann man das Wiki an dieser Stelle aktualsieren. Vielleicht kann das noch jemand weiteres verproben?

Max-Ulrich_Farber schrieb:

Ich bin jetzt ziemlich irritiert. […]

Ich auch!

Bei mir funktioniert die Netbios-Namansauflösung auch bei 20.04 per Broadcast:

$ nmblookup router
192.168.178.1 router<00>
192.168.179.1 router<00>
169.254.1.1 router<00>

Kein lmhosts, kein WINS, kein winbind.

Seit 15 Jahren verwende ich eine solche Zeile in /etc/fstab:

$ grep Fritz /etc/fstab 
//ROUTER/FBOX	/media/Fritz.NAS	cifs	_netdev,noauto,users,rw,credentials=/media/Fritz.NAS/credentials	0 0

(_netdev ist erst vor ca. 5 Jahren dazugekommen.)

Und es funktioniert tadellos:

$ findmnt -t cifs
TARGET           SOURCE        FSTYPE OPTIONS
/media/Fritz.NAS //ROUTER/FBOX cifs   rw,nosuid,nodev,noexec,relatime,vers=3.1.1, …

(Optionen gekürzt.)

Allerdings verwende ich einen Master Browser Server. Die Verwendung von Netbios-Namen scheint hakelig zu sein, aber es funktioniert. Für das Wiki empfehle ich deshalb, sich auf IP-Adressen zu beschränken.

Bist du sicher, daß der netbios Name funktioniert? Schau mal in den Programmcode. Nach meinen laienhaften Kenntnissen in der Programmierung ruft mount.cifs die Funktion resolve_host.c auf. resolve_host.c bezieht sich auf DNS.

Ich bin leider gar nicht sicher und deshalb froh, wenn Ihr da noch etwas recherchiert und die Aussagen im Artikel anpasst.

@kB:

Allerdings verwende ich einen Master Browser Server

Ich nicht. – Das könnte vielleicht manches verändern

$ nmblookup router

Ja, nmblookup funktioniert auf jeden Fall. Das heißt aber noch nicht, dass es in mount.cifs auch funktioniert.

Für das Wiki empfehle ich deshalb, sich auf IP-Adressen zu beschränken.

Wenn die Verwendung von Netbios-Namen ohne zusätzliche Bedingungen sicher funktioniert (?), dann würde ich dies aber schon ins Wiki schreiben. Mit DHCP ist das auf jeden Fall praktisch.

Noch eine Frage: Spielt es in einem kleinen (Heim-)Netzwerk ohne Domain-Struktur überhaupt eine Rolle, ob DNS- oder Netbios-Namen? Wann wird der Unterschied überhaupt wichtig?

Gruß – Max-Ulrich

P.S.:

$ grep Fritz /etc/fstab 
//ROUTER/FBOX	/media/Fritz.NAS	cifs	_netdev,noauto,users,rw,credentials=/media/Fritz.NAS/credentials	0 0

Bei mir funktioniert Fritz.NAS nur mit der zusätzlichen Option noserverino zuverlässig. Ist das bei Anderen auch so?

Nach meinem Verständnis läuft die netbios Namensauflösung über Port 137 (UDP). Ich habe per mount.cifs aber nur UDP Traffic auf Port 53 (= DNS) gesehen. Ich denke, wenn man den Traffic auf 137 komplett blockiert und dann die Namensauflösung immer noch funktioniert, haben wir die Gewissheit, das netbios nicht mehr für mount.cifs relevant ist. Ich tendiere allerdings auch dazu, lieber nur die IP als Server im Wiki aufzuführen. Ggf. als Zusatz dann den hostname des Servers aufführen, der per DHCP kommuniziert wird oder eben statisch per /etc/hosts.

Spielt es in einem kleinen (Heim-)Netzwerk ohne Domain-Struktur überhaupt eine Rolle, ob DNS- oder Netbios-Namen? Wann wird der Unterschied überhaupt wichtig?

Imho ja. Eine Domain hat jedes Netz, sei es nun .box wie bei fritz.box oder wie bei mir .lan. netbios würde ich gar nicht mehr aktiv kommunizieren, da es eigentlich veraltet ist.

Max-Ulrich_Farber schrieb:

[…]

Für das Wiki empfehle ich deshalb, sich auf IP-Adressen zu beschränken.

Wenn die Verwendung von Netbios-Namen ohne zusätzliche Bedingungen sicher funktioniert (?), dann würde ich dies aber schon ins Wiki schreiben.

Momentan bin ich mir nur sicher, dass …

1. es bei mir zuverlässig funktioniert,

2. aber ich ganz sicher anderen nicht sicher erklären kann, wieso bei mir und bei vielen anderen gar nicht.

Bei 1 mag ich mich im Irrtum befinden, aber jedenfalls kann ich Netbios-Namen in der /etc/fstab wie von mir beschrieben verwenden.

Bei 2 mag die unübersehbare Variabilität von SMB und des SMB-Umfeldes eine Rolle spielen.

Jedenfalls traue ich mich unter diesen Umständen nicht, dies im Wiki zu beschreiben. Der Weg über die IPv4-Adresse scheint viele mögliche Probleme zu umgehen und ist daher aus meiner Sicht Wiki-tauglich. Ich empfinde die momentane Darstellung als richtig und angemessen.

Lustigerweise funktioniert es bei mir nicht, wenn ich in der /etc/fstab eine IPv6-Adresse angebe. Andererseits bekomme ich bei der Angabe des Netbios-Namens eine saubere SMB-3.1.1-Verbindung über IPv6!

Jedenfalls traue ich mich unter diesen Umständen nicht, dies im Wiki zu beschreiben.

Ich auch nicht! Und ich will und kann mich in das Gewirr auch nicht mehr einarbeiten.

The mount utility calls a mount helper, usually mount.cifs which calls into the kernel. The mount helper mount.cifs is the user space helper and needed to parse tcp/ip names and retrieve userid and password, and also does simple formatting of the mount options.

Server's listen for incoming client connections via TCP/IP and thus have ip addresses, and usually tcp host names configured for them, but users often refer to the server by its "netbios name" (RFC1001 name). To mount using the cifs client, a tcp name (rather than netbios name) must be specified for the server. To resolve the <server> to a ip address, you need either a DNS server which knows the ip address or your client needs the nss module wins. It is a shared library which must be in the path of your ldd. Usually under /usr/lib. You also have to add the wins option to hosts in your /etc/nsswitch.conf. The smbclient utility can also be used to identify the tcp name or ip address of a server (identified by its netbios name).

Link.

DNS scheint der Defaultweg für mount.cifs zu sein. Da aber offensichtlich der Wiki Eintrag zu Nachfragen führen kann, wäre mein Vorschlag folgender:

Hinweisbox anbringen, dass die Servernamen zwar grundsätzlich per DNS aufgelöst werden, die Verwendung der IP jedoch mögliche Fehlerquellen bei der Namensauflösung ausschließt und daher die bevorzugte Methode ist.

In diesem Zusammenhang dann den Abschnitt mit dem Broadcast komplett streichen.

Edit: erledigt.