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.
SMB, weils der kleinste gemeinsame Nenner ist. Hätte schon Probleme damit, das mein Scanner die Scans nur auf SMB Freigaben legen kann.
NFS konnten meine Rechner schon, als SMB noch nicht mal existent war. Bei den richtigen Windowsversionen muss man NFS praktisch nur einschalten.
SMB, weil ich mir Windows Server Lizenzen leisten kann und nicht auf Fricklersoftware angewiesen bin.
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.
Der beisst nicht, der will nur spielen.
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.
Ganz klar SMB, das ist zwar lahm aber am Kompatibelsten mit allen Geräten.
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.
:
Bearbeitet durch User
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?
Rolf M. schrieb: > Du hast aber mitbekommen, dass sie es bereits eingestampft haben? Genau das meinte ich ;o)
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>
NFSv4 benötigt nur noch einen Port womit die Konfiguration per Firewall vereinfacht wird und hat noch ein paar weitere Vorteile. Aber das steht im Grunde alles hier: https://de.wikipedia.org/wiki/Network_File_System#NFS_Version_4
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.
:
Bearbeitet durch User
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/rfc5661 https://tools.ietf.org/html/rfc7862
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.