Windows verwendet von Haus aus ACLs und ist bei Dateinamen bezüglich der
Groß- und Kleinschreibung beliebig, dafür ist das Server Message Block
(SMB) Protokoll wie geschaffen.
Unix Systeme und Linux kann man ACLs zwar beibringen, haben aber von
Haus aus die typischen Unix Dateiberechtigungen (bsp. "rwxr-xr--") und
beachten die Groß- und Kleinschreibung. Dafür wurde das Network File
System (NFS) Protokoll entwickelt.
Die meisten Linux Systeme haben Samba vorinstalliert und können daher
mit SMB bis einschließlich der SMB Version 3.1.1 mit Windows Clients
kommunizieren, aber man kann manchen Windows Clients stattdessen auch
NFS beibringen.
Insofern stellt sich die Frage was ihr in einem heterogenen Netzwerk so
einsetzt und bevorzugt bzw. warum ihr es einsetzt.
Bevorzugt ihr lieber NFS und bringt dann Windows NFS bei oder nehmt ihr
doch lieber SMB wenn ihr zwischen einem Windows und Linux/Unix Client
Dateien austauschen müsst.
Fritzi schrieb:> SMB, weil ich mir Windows Server Lizenzen leisten kann und nicht> auf> Fricklersoftware angewiesen bin.
Deine Lautsprecherkabel sind ja auch aus Gold, weil dich der Händler
davon überzeugt hat, dass so der Klang besser wird.
Nano schrieb:> Insofern stellt sich die Frage was ihr in einem heterogenen Netzwerk so> einsetzt und bevorzugt bzw. warum ihr es einsetzt.>> Bevorzugt ihr lieber NFS und bringt dann Windows NFS bei oder nehmt ihr> doch lieber SMB wenn ihr zwischen einem Windows und Linux/Unix Client> Dateien austauschen müsst.
NFS ~ Not For Serious (Data); NFS ist gut aber als ich das letzte mal
nachgesehen habe ( ist 6 Jahre her) hatte die Linux Implementierung
Probleme wenn viele Daten schnell abgefragt werden das er in eine Art
Panik Modus verfällt und da nicht mehr richtig raus kommt.
SMB auf der anderen Seite ist mittlerweile ein recht Robustes Protokoll,
allerdings sind bei Samba einige Konstrukte drin welche mich den
Kopfschütteln lassen, warum zum Beispiel muss Samba ein Coredump
verwerfen wenn das Netzwerk mit EAGAIN Antwortet.
Was deine Frage angeht, was ich bevorzuge. Beides und noch einige mehr.
Daten liegen auf meinen Server oder Private der NAS. die Spricht beide
Protokolle und ist damit in der Lage alle Clients mit dem Ihnen
Bevorzugten Protokollen zu Antworten.
imonbln schrieb:> Was deine Frage angeht, was ich bevorzuge. Beides und noch einige mehr.> Daten liegen auf meinen Server oder Private der NAS. die Spricht beide> Protokolle
Was allerdings Probleme mit dem File Locking geben könnte, wenn SMB- und
NFS-Clients auf die gleiche Datei zugreifen.
Bauform B. schrieb:> Was allerdings Probleme mit dem File Locking geben könnte, wenn SMB- und> NFS-Clients auf die gleiche Datei zugreifen.
... und mit lustigen Caching-Effekten ab SMBv2.
imonbln schrieb:> Was deine Frage angeht, was ich bevorzuge. Beides und noch einige mehr.> Daten liegen auf meinen Server oder Private der NAS. die Spricht beide> Protokolle und ist damit in der Lage alle Clients mit dem Ihnen> Bevorzugten Protokollen zu Antworten.
Danke für deine Antwort.
Bei meinem NAS (FreeNAS) ist das auch so, allerdings soll man für jedes
Protokoll ein anderes Verzeichnis freigeben bzw. für die jeweiligen
Protokolle voneinander unabhängige Verzeichnisse nehmen.
Denn macht man bspw. für das gleiche Verzeichnis eine Freigabe für NFS
und gleichzeitig noch für SMB und greift dann unter NFS mittels chmod
auf die Dateien zu, dann macht man damit die ACLs kaputt.
Siehe dazu:
"Do not use chmod to attempt to fix the permissions on a SMB share as it
destroys the Windows ACLs. The correct way to manage permissions on a
SMB share is to manage the share security from a Windows system as
either the owner of the share or a member of the group that owns the
share. To do so, right-click on the share, click Properties and navigate
to the Security tab. If the ACLs are already destroyed by using chmod,
winacl can be used to fix them. Type winacl from Shell for usage
instructions."
Quelle:
https://www.ixsystems.com/documentation/freenas/11.2/services.html#troubleshooting-smb
Will man also sowohl von Linux als auch Windows auf das gleiche
Verzeichnis zugreifen, dann muss bzw. sollte man sich für ein Protokoll
entscheiden und dann auch dauerhaft bei dem bleiben.
Nano schrieb:> Will man also sowohl von Linux als auch Windows auf das gleiche> Verzeichnis zugreifen, dann muss bzw. sollte man sich für ein Protokoll> entscheiden und dann auch dauerhaft bei dem bleiben.
NetApp bietet Filesysteme mit einer Rechteverwaltung für beides. Hab
schon einfachere Themen gehabt. Der Spass fing schon beim Charset an.
imonbln schrieb:> NFS ~ Not For Serious (Data); NFS ist gut aber als ich das letzte mal> nachgesehen habe ( ist 6 Jahre her) hatte die Linux Implementierung> Probleme wenn viele Daten schnell abgefragt werden das er in eine Art> Panik Modus verfällt und da nicht mehr richtig raus kommt.
Also ich habe für einen Kunden NFS seit ~8 Jahren im Betrieb. Sind
mehrere NFS Server in seinem Rack, und die Webseite macht ~8-10TB/Monat
bei ~2-3Mio Files in den Shares. Bisher keine Probleme.
Bauform B. schrieb:> Was allerdings Probleme mit dem File Locking geben könnte, wenn SMB- und> NFS-Clients auf die gleiche Datei zugreifen.
Hausintern geht es bei mir so:
[Storage] --(NFS)-> [VM] --(NFS+SMB)-> [Clients]
Klingt erstmal komisch, aber dadurch hatte ich bisher keine
Locking/Caching Probleme weil die eigentliche Datei nur per NFS
erreichbar ist.
Windows ACLs gibt's damit zwar nicht, aber Win ist hier eh nur ein
notwendiger Klotz am Bein auf ein paar Rechnern wo ACLs egal sind.
Nano schrieb:> Insofern stellt sich die Frage was ihr in einem heterogenen Netzwerk so> einsetzt und bevorzugt bzw. warum ihr es einsetzt.
Ganz klar: SMB.
Schon in meinem (vollkommen untypischen, weil schwer linuxlastigem)
Haushalt ist das unterm Strich die deutlich einfachere Lösung. Umso mehr
im Normalfall, wo eine Linuxkiste im Netz eher die Ausnahme als die
Regel ist. Tja, Smartphones könnten das Zahlenverhältnis theoretisch
ändern (weil sie auf einem unixoiden Kernel basieren und unixoide (auch
Netzwerk-) Filesysteme leicht unterstützen könnten), aber Google hat
ihnen ja alles verboten, wofür man Google nicht braucht, damit wirklich
jedes Quantum an Information, welches Google nix angeht und Google auch
nicht gehört, am Ende trotzdem bei Google landet...
Bei Apple sieht's de facto genauso aus, nur der Weg, um den
Informationsabfluss zu erzwingen, ist leicht verschieden vom Google-Weg,
NFS jedenfalls können die überteuerten Schrott-Dinger von Hause aus
jedenfalls genausowenig wie Googles Machwerke...
Interessanterweise gilt exakt dieselbe Begründung auch in den
allermeisten Firmen. Auch hier überwiegt die Zahl der Rechner mit
Windows typisch sehr weit die Zahl der Rechner mit (NFS-fähigen)
Unix-Derivaten.
c-hater schrieb:> aber Google hat> ihnen ja alles verboten, wofür man Google nicht braucht, damit wirklich> jedes Quantum an Information, welches Google nix angeht und Google auch> nicht gehört, am Ende trotzdem bei Google landet...> Bei Apple sieht's de facto genauso aus, nur der Weg, um den> Informationsabfluss zu erzwingen, ist leicht verschieden vom Google-Weg,> NFS jedenfalls können die überteuerten Schrott-Dinger von Hause aus> jedenfalls genausowenig wie Googles Machwerke...
Das ist bei Windows 10 Mobile auch so.
Da kannst du das Smartphone entweder via USB an den Rechner anschließen
und dann so die Daten austauschen oder alles über die MS Cloud schieben.
Nano schrieb:> Das ist bei Windows 10 Mobile auch so.
Jepp, das ist so. Nur spielen die einfach keine signifikante Rolle.
Selbst in Hoch-Zeiten ihrer Verbreitung taten sie das nicht. Ja, die
Hoch-Zeit ist bereits wieder vorbei. Das gefällt Winzigweich natürlich
garnicht...
c-hater schrieb:> Nano schrieb:>>> Das ist bei Windows 10 Mobile auch so.>> Jepp, das ist so. Nur spielen die einfach keine signifikante Rolle.> Selbst in Hoch-Zeiten ihrer Verbreitung taten sie das nicht. Ja, die> Hoch-Zeit ist bereits wieder vorbei.
Du hast aber mitbekommen, dass sie es bereits eingestampft haben? Die
Weiterentwicklung ist schon vor über einem Jahr eingestellt worden.
Es gibt nur noch Support, und der wird wohl nächstes Jahr auslaufen.
Nano schrieb:> Insofern stellt sich die Frage was ihr in einem heterogenen Netzwerk so> einsetzt und bevorzugt
Bevorzugen? Ganz klar NFS, weil es schneller und stabiler ist.
Allerdings kann mein Fileserver (Linux) auch SMB. Für die paar
behinderten Geräte im Haushalt, die kein NFS können und auch für die
Windows-VMs gibt es also zusätzlich SMB.
Axel S. schrieb:> Nano schrieb:>> Insofern stellt sich die Frage was ihr in einem heterogenen Netzwerk so>> einsetzt und bevorzugt>> Bevorzugen? Ganz klar NFS, weil es schneller und stabiler ist.> Allerdings kann mein Fileserver (Linux) auch SMB. Für die paar> behinderten Geräte im Haushalt, die kein NFS können und auch für die> Windows-VMs gibt es also zusätzlich SMB.
NFS Version <= 3 oder NFS Version >= 4?
Sowohl beruflich als auch privat: SMB
Privat nutze ich ausschliesslich Linux und BSD, beruflich 60:40
Windows:*nix.
Wer mich kennt, weiss auch, dass ich kein Windows-Freund bin aber SMB
hat hier die Nase vorn. Leider.
Eric schrieb:> Wer mich kennt, weiss auch, dass ich kein Windows-Freund bin aber SMB> hat hier die Nase vorn. Leider.
Was sind deine Gründe für SMB gegenüber NFSv4?
Nano schrieb:> Axel S. schrieb:>> Nano schrieb:>>> Insofern stellt sich die Frage was ihr in einem heterogenen Netzwerk so>>> einsetzt und bevorzugt>>>> Bevorzugen? Ganz klar NFS, weil es schneller und stabiler ist.>> Allerdings kann mein Fileserver (Linux) auch SMB. Für die paar>> behinderten Geräte im Haushalt, die kein NFS können und auch für die>> Windows-VMs gibt es also zusätzlich SMB.>> NFS Version <= 3 oder NFS Version >= 4?
Welche Rolle spielt das? Aber es ist NFS v4. Selbst mein eher gut
abgehangener 4.4er Linux Kernel (Ubuntu Server) kann das. Vorher war es
bestimmt ein Jahrzehnt NFS v3. Gab auch nie Probleme. <shrug>
Das hängt ganz von der Anwendung ab:
Zugriff von allen möglichen Clients auf ein gemeinsames Fileshare ->
Samba
Teilen von Filesystem zwischen Unix/Linux-Servern: NFS
Für einen klassischen Fileserver wäre es dann also Samba, wobei
natürlich dabei Linux-Clients mit Multiuser schlecht aussehen (oder gibt
es da inzwischen etwas um den aktuellen User nur in seinem Kontext am
Samba anzumelden?).
Ich hatte viele Jahre einen gesharten Samba/NFS-Server unter Linux im
Einsatz für so 30 Leute.
Das mit der Gross/Kleinschreibung bei den Filenamen kann man mit der
Samba-Konfiguration halbwegs in den Griff bekommen. Bei den
Zugriffsrechten muss man sich auf die Basics beschränken, da Linux
nunmal nicht die Windowsrechte abbilden kann und die Linuxrechte
wiederum für Windows irgendwie abgebildet werden müssen.
Also mehr als Kein Zugriff Read-Only Read-Write auf Share-Ebene
hatte ich nicht realisiert. Evtl. geht mit ACLs mehr, aber es wird
trotzdem frickelig bleiben.
Achja, lusitge Caching-Effekte gab es auch manchmal, konnte man aber
wimre mit entsprechenden Optionen ebenfalls beheben.
Nano schrieb:> NFSv4 benötigt nur noch einen Port womit die Konfiguration per> Firewall vereinfacht wird und hat noch ein paar weitere Vorteile.
Ach so. NFS V4 hat den "Vorteil", daß es jetzt auch von Leuten benutzt
werden kann, die zu faul sind, das Handbuch™ zu lesen
<gähn>
Axel S. schrieb:> Vorher war es bestimmt ein Jahrzehnt NFS v3. Gab auch nie Probleme.Markus M. schrieb:> Für einen klassischen Fileserver wäre es dann also Samba
Habe ich jetzt mehrfach gelesen, erschließt sich mir nach wie vor nicht.
Welchen ernsthaften Grund gibt es jetzt nochmal, Filesysteme nicht
gleichzeitig per NFS und per SAMBA zu exportieren?
Axel S. schrieb:> Markus M. schrieb:>> Für einen klassischen Fileserver wäre es dann also Samba>> Habe ich jetzt mehrfach gelesen, erschließt sich mir nach wie vor nicht.> Welchen ernsthaften Grund gibt es jetzt nochmal, Filesysteme nicht> gleichzeitig per NFS und per SAMBA zu exportieren?
Wozu zwei Möglichkeiten anbieten und konfigurieren müssen, wenn einer
reicht? Und diesem Faden nach spart man sich den Ärger bzw. die Konfig
bezüglich Wechselwirkungen.
Axel S. schrieb:> Ach so. NFS V4 hat den "Vorteil", daß es jetzt auch von Leuten benutzt> werden kann, die zu faul sind, das Handbuch™ zu lesen
Ich habe eher den Eindruck, dass man aufgrund massiver Unterschiede auch
dann das das Handbuch für NVSv4 lesen muss, wenn man NFSv3 schon gewohnt
ist.
> Habe ich jetzt mehrfach gelesen, erschließt sich mir nach wie vor nicht.> Welchen ernsthaften Grund gibt es jetzt nochmal, Filesysteme nicht> gleichzeitig per NFS und per SAMBA zu exportieren?
Race conditions beispielsweise. Eine Anwendung erzeugt auf Rechner 1 mit
Protokoll A ein File (oder benennt es um, oder sowas in der Art). Sie
teilt dann einer anderen Anwendung auf Rechner 2 das auf einem dritten
Kanal mit. Der erlebt manchmal via Protokoll B eine Überraschung. BTDT.
A. K. schrieb:> Race conditions beispielsweise. Eine Anwendung erzeugt auf Rechner 1 mit> Protokoll A ein File (oder benennt es um, oder sowas in der Art). Sie> teilt dann einer anderen Anwendung auf Rechner 2 das auf einem dritten> Kanal mit. Der erlebt manchmal via Protokoll B eine Überraschung. BTDT.
Die erlebt man ggf. auch, wenn Rechner 2 ebenfalls über Protokoll A
zugreift. Zumindest bei NFS kenne ich diesen Fall. Rechner 2 hat dort
die Datei nach einer Änderung durch Rechner 1 neu geladen - und bekam
noch die alte Version zu sehen, obwohl die gar nicht mehr existieren
sollte. Irgendwann (ggf. Minuten später) geht's dann, aber es hat sich
mir nicht erschlossen, wovon das abhängt.
Reinhard S. schrieb:> Axel S. schrieb:>> Markus M. schrieb:>>> Für einen klassischen Fileserver wäre es dann also Samba>>>> Habe ich jetzt mehrfach gelesen, erschließt sich mir nach wie vor nicht.>> Welchen ernsthaften Grund gibt es jetzt nochmal, Filesysteme nicht>> gleichzeitig per NFS und per SAMBA zu exportieren?>> Wozu zwei Möglichkeiten anbieten und konfigurieren müssen, wenn einer> reicht?
Tun sie ja nicht. Ein SMB Share muß ich immer als ein bestimmter User
mounten und dann gehören alle Files, die der Client anlegt, eben diesem
User. Das nutzt mir genau gar nichts, wenn ich bspw. ein Backup auf das
Backup-Volume machen will. Mit NFS funktioniert das 1A, alle Files die
das Backup-Programm (storeBackup) anlegt, behalten Eigentümer und
Zugriffsrechte.
Und wie gesagt: sogar mit NFS v3, wo das etwas mehr Kooperation seitens
des Admins erfordert, hat das sauber funktioniert.
Außerdem: der Teil, der aufwendig(er) zu konfigurieren ist, ist Samba.
NFS ist im Vergleich Pillepalle. Selbst wenn beide Alternativen
gleichmächtig wären, wäre SMB aufwendiger zu konfigurieren.
> Und diesem Faden nach spart man sich den Ärger bzw. die Konfig> bezüglich Wechselwirkungen.
Ist das so? Ich habe es persönlich noch nie erlebt, habe aber
zugegebenermaßen fast nur Lesezugriffe per SMB. Bzw die Daten, die per
SMB geschrieben werden, werden nicht auch per NFS (oder überhaupt)
geschrieben. Ich halte das mit den Konflikten für eine urbane Legende
und wäre an Tatsachenberichten interessiert.
A. K. schrieb:> Race conditions beispielsweise. Eine Anwendung erzeugt auf Rechner 1 mit> Protokoll A ein File (oder benennt es um, oder sowas in der Art). Sie> teilt dann einer anderen Anwendung auf Rechner 2 das auf einem dritten> Kanal mit. Der erlebt manchmal via Protokoll B eine Überraschung. BTDT.
Und das war sicher wegen SMB vs. NFS? Und wäre nicht auch passiert, wenn
beide Clients NFS (oder meinetwegen SMB) benutzt hätten?
Axel S. schrieb:> Und das war sicher wegen SMB vs. NFS? Und wäre nicht auch passiert, wenn> beide Clients NFS (oder meinetwegen SMB) benutzt hätten?
Es war zumindest weg, nachdem ich Samba ziemlich strikt in Protokoll und
Caching einschränkte.
Rolf M. schrieb:> Die erlebt man ggf. auch, wenn Rechner 2 ebenfalls über Protokoll A> zugreift. Zumindest bei NFS kenne ich diesen Fall. Rechner 2 hat dort> die Datei nach einer Änderung durch Rechner 1 neu geladen - und bekam> noch die alte Version zu sehen, obwohl die gar nicht mehr existieren> sollte. Irgendwann (ggf. Minuten später) geht's dann, aber es hat sich> mir nicht erschlossen, wovon das abhängt.
Das ist nur das Offensichtliche...
Wenn du tiefer absteigst in's (partielle) Locking wirst du noch viel
dramatischere Effekte erleben. Damit haben vor allem file-orientierte
Datenbanken zu kämpfen, also Datenbanken, die sich auf die
Locking-Mechanismen des zugrunde liegenden OS (bzw. des Filesystems)
verlassen, statt eigene zu implementieren.
Kurzfassung: NFS war niemals fertig. NFSv4 ist auch nicht fertig, hat
nur mit einigen grundsätzlichen Sicherheitsproblemen von NFSv3
aufgeräumt.
Bezüglich der Sicherheit ist die Entwicklung bei SMB übrigens eigentlich
ganz ähnlich. Auch hier gibt es ziemlich dramatische Brüche wegen dieser
Sache.
Der Unterschied zwischen SMB und NFS ist: SMB hat von Anfang an (auch
partielles) File-Locking als essentielles Feature betrachtet und
dementsprechend unterstützt. Das tut NFS aber auch in der aktuellen
Version nur eher notdürftig. Ja, die Entwickler wissen, dass es
eigentlich wichtig ist, haben aber offensichtlich keine große Lust dazu,
sich da durch zu quälen. Oder ihnen fehlt schlicht die notwendige
Entwicklungszeit dafür.
Dementsprechend Scheisse funktioniert es in der bösen Realität, wo ein
Netz, selbst ein LAN, halt nicht immer perfekt funktioniert...
Aber natürlich: in einer nicht perfekten Umgebung funktioniert auch SMB
nicht perfekt. Das liegt in der Natur der Sache. Aber es funktioniert
halt doch deutlich zuverlässiger als NFS. Insbesondere halt dann, wenn
partielles File-Locking eine Rolle spielt.
Rolf M. schrieb:> Die erlebt man ggf. auch, wenn Rechner 2 ebenfalls über Protokoll A> zugreift. Zumindest bei NFS kenne ich diesen Fall. Rechner 2 hat dort> die Datei nach einer Änderung durch Rechner 1 neu geladen - und bekam> noch die alte Version zu sehen, obwohl die gar nicht mehr existieren> sollte. Irgendwann (ggf. Minuten später) geht's dann, aber es hat sich> mir nicht erschlossen, wovon das abhängt.
Das sollte bei NFSv4 nicht mehr passieren:
"Ein NFSv4-Server kann Dateioperationen an einen Client delegieren. Ein
Client verändert oder löscht eine delegierte Datei damit im eigenen
Cache und spart wiederum Netzwerkverkehr. Erkennt der Server, dass
andere Clients auf die Datei zugreifen wollen, widerruft er die
Datei-Delegation und der Client schickt seine Änderungen zum Server.
Solche Rücknahmen bewerkstelligt NFSv4 über Callback-RPCs. Da Firewalls
die Rückrufe blockieren könnten, testen NFSv4-Server beim
Verbindungsaufbau die Fähigkeiten der Clients und passen ihr Verhalten
dem Ergebnis an. "
Quelle:
https://www.heise.de/ct/artikel/Das-Netzwerk-Dateisystem-NFSv4-221577.html?seite=2
Den Artikel zu NFS v4 sollte man sich mal durchlesen.
NFS v4 ist schon klasse und mit NFS v4.1 und v4.2 kam noch einiges mehr
dazu.
https://tools.ietf.org/html/rfc5661https://tools.ietf.org/html/rfc7862
