macOS auf 9.10.2 (SMB) massive Probleme

[coolblue81]

Hallo,
ich stell gerade privat zu Hause von einem Windows 2008 R2 Server auf FreeNAS 9.10.2 um und stoße dabei auf massive Probleme mit dem Zugriff von Apple OS X (macOS) auf Samba Shares des FreeNAS Systems.

Ich habe bereits sämtliche Hilfestellungen ausprobiert, welche ich via Google usw. gefunden habe.
z.b.:
1) "smb_neg=smb1_only" in /etc/nsmb.conf
2) Samba min & max Version = NT1 (oder SMB2 oder SMB3.. mal durchprobiert)
3) Samba Share vfs objects: catia, fruit, streams_xattr

Es läuft einfach nicht rund und ich verstehe warum das so schwierig ist. Mit OS X (egal welche Version, aktuell El Capitan) hatte ich mit Windows 2008 R2 nur wenig bis keine Probleme. Ein Speed Problem bezüglich des SMB Signing gab es mal.. das konnte man aber simpel mit "signing_required=no" lösen.. aber ansonsten läufts.

Aktuelle Situation:
ZFS Dataset "Daten"
- Share Type: Windows
- Compression Level: lz4
- Case Sensitivity: Mixed
- Permission Type: Windows

Samba Global
- DOS Charset CP850
- UNIX charset UTF-8
- Local Master: checked
- Time Sever: checked
- Guest Account: nobody
- Unix extensions: checked
- Zeroconf: checked
- Aux Params: map to guest = Never
- Minimum Protocol: NT1
- Maximum Protocol: SMB3

Samba Share "Daten"
- Apply Default Permissions: checked
- Browseable to Network Clients: checked
- VFS Objects: aio_pthread, streams_xattr

MacOS Finder > CMD+K > cifs://192.168.178.31/Daten

Damit einhergehende Probleme:
a) TextEdit
Öffnen der Textdatei "blub.txt" in TextEdit. Ändern des Inhalts. Ablage > Sichern
Fehlermeldung: Das Dokument "blub.txt" konnte nicht gesichert werden.
Danach verwerfe ich die Änderungen und schließte TextEdit. Auf der NAS ist weiterhin die alte Version

Speichere ich die Datei auf dem Desktop und kopiere sie dann auf die NAS, klappt das wunderbar.

b) Microsoft Word
Öffne ich die Textdatei "blub.txt" in MS Word. Ändere den Inhalt und sage dann auch wieder "speichern". Dann tut er dies ohne zu meckern.
In der Datei sind auch die Änderungen vorhanden. Jedoch habe ich jetzt einen zusätzlichen Ordner "blub.txt.sb-a4d24b4b-sl7J4Y" neben der eigentlich Datei "blub.txt".

Mit oben genannten Einstellungen ist es halbwegs aushaltbar. In anderen Konstellationen waren die Probleme noch schlimmer. Z.b. konnte TextEdit erfolgreich speichern ohne zu meckern. Jedoch war die Original Datei nicht geändert.. der User merkts aber nicht oder die *sb-xxx" Verzeichnisse sind nicht mehr löschbar und enthalten die Text-Datei wie sie geändert wurde. Nur über die Shell (SSH) kann ich dir Ordner löschen.

c) Datei auf die NAS kopieren
Wenn ich eine Datei auf die NAS kopiere verdoppelt der Finder in der Ansicht den ersten Ordner. Erst wenn ich rausklicke und wieder rein in das Finder Fenster verschwindet der doppelte Ordner und die eigentliche Datei erscheint.

In anderen Konstellationen (obige Einstellungen) wars sogar so, das die Datei ausgegraut wurde und weder zu öffnen noch löschbar war. (nur via Shell)
Sehr merkwürdig.

Ich kann ja verstehen das die SMBX Implementation von Apple nicht die beste sein mag und das Samba auch nur eine reversed engeneered Implementation darstellt. Dennoch wunderts mich das es mit Windows 2008 R2 einwandfrei läuft und das sogar schon seit der Umstellung von Samba auf SMBX in OSX vor einigen Jahren. Daher glaube ich das Problem ist bei Samba zu suchen.

Es wäre schön wenn es irgendwo ein Howto oder FAQ gibt, wie man das korrekt (best möglich) einstellt. Da es nur zwei Macs im Haus gibt, bin ich auch bereit lokale Einstellungen am Mac zu ändern damit das einwandfrei rockt.

Ebenfalls bin ich Linux sehr fit (BSD so lala) und kann auch hier und da etwas tiefer graben, wenn erforderlich.

 

[Henning Kessler]

Es gibt in freenas zur Zeit wohl ein Problem mit Samba und vfs_fruit.

Guck mal hier https://bugs.freenas.org/issues/18595

Grüße

Henning

 

[coolblue81]

Hallo Henning,
danke für die Info, das erklärt zumindest ein anderes Phänomen was ich bei meinen Tests mitbekommen habe.

Ich denke ich hab die Lösung jetzt. Manchmal hilft es laut zu schreien und seine Problem irgendwo kund zu tun (Thread hier) :)

Damit auch andere davon hier profitieren:

1) In den Samba Einstellungen "UNIX Extensions" deaktivieren.
Apple erkennt das und glaubt er könne wie bei HFS+ erweiterte Attribute (oder sowas?) verwenden. Hab das in den letzten Tagen beim Googlen schonmal nachgelesen und nun erklärt es auch das Problem. Nur ist ZFS nicht HFS+ zumindest nicht bei einem Windows Dataset (andere Arten hab ich jetzt nicht getestet). Nachdem ich die Option abgeschaltet habe, erkennt Apple den Samba Share wohl als normale Windows Freigabe und nutzt wieder seine ._xyz Ressource Dateien.

Ich habe danach auf SMB3 (smb:// statt cifs://) umgeschaltet und siehe da.. auch damits geht. Läuft soweit einwandfrei.

Eine Sache blieb jedoch. Obiger Punkt c) Doppelte Ordner beim kopieren.

2) Die Module vfs_fruits und vfs_catia.
Nach aktivieren des Fruits Module mit den Default Einstellungen bricht alles zusammen. TextEdit will nich mehr speichern. Ordner mit .sb extension werden erstellt aber nicht gelöscht.. usw.

Scheinbar ist das fruits Module wenn es für die Kompatibilität mit AFP benutzt werden soll buggig. Ggf. liegts auch an FreeNAS mit ZFS und unter Linux geht es vielleicht.

Ich benötige hier aber weder Kompatibilität zu AFP noch zu NFS (auch da soll vfs_fruits helfen) sondern der Mac und alle Windows Systeme greifen auf Samba zu mit einem ZFS Windows Dataset.

Ich habe im Manual ein wenig gelesen und dann ausprobiert. Folgendes funktioniert:
Auxiliary Parameters:
fruit:resource = xattr
fruit:metadata = netatalk
fruit:locking = none
fruit:encoding = private
veto files = /.snapshot/.windows/.mac/.zfs/.TemporaryItems/.DS_Store

ressource=xattr
Der Parameter xattr sorgt dafür das die Ressource Files in den ZFS Streams gespeichert werden, genauso wie die NTFS streams.
Das hat den netten nebeneffekt das keine ._xyz Ressource Dateien mehr angelegt werden! Genial!

fruit:metadata=netatalk
Hier werden die Metadata im netatalk "style" gespeichert. Das zusammen mit xattr funktioniert.

locking=none
Da ich nicht mit AFP darauf zugreifen will, habe ich das deaktiviert. Musste ich aber sowieso, ist das nämlich an.. funktioniert TextEdit und co nicht mehr. Buggig?

veto files
Der Mac legt immer noch .DS_Store und .TemporaryItems an, da die unnötigt sind, habe ich die in veto files hinzugefügt. Ergo cluttert die NAS damit nicht voll.

Sonstiges:
"Show hidden Files" hab ich aktiviert, so dass ich unter Windows (auch Mac wenn ich will) alle Punktdateien sehen kann. Da keine Apple Ressourcfiles mehr angelegt werden, ist es auch nicht mehr nötig die .Dateien zu verstecken.

vfs_catia:
Das Module ist schrott. Einfach nur aktiviert, macht es nix. Wenn man die empfohlene Zeichenersetzung aus dem Manual nutzt, dann ist das erstmal cool.. denn eine Datei namens "hallo:wie:gehts.txt" wird unter Mac und Windows dann als hallo÷wie÷gehts.txt angezeigt anstatt in der kurzen 8.3 notation mit ~1.txt.

Leider wars das aber auch schon. Denn ein Zugriff auf die Datei ist weder unter Apple noch Windows möglich. Jegliches öffnen oder kopieren der Datei schlägt fehl. Also hab ich catia wieder deaktiviert. Brauch ich nicht.

Dateien sofort sichtbar:
Durch die Aktivierung von vfs_fruits mit den richtigen Einstellungen, erscheinen auf den Share kopierte Dateien sofort richtig im Finder! *freu*

-----
Bug Editing/Löschen von vfs_fruit Dateien:
Ich hatte das Problem beim testen auch.. allerdings nur wenn die Einstellungen geändert wurden oder falsch waren. Wenn ressource=file steht und man Dateien drauf kopiert udn danach umschaltet auf ressource=xattr. Dann sind die alten Dateien auf dem Mac nicht mehr löschbar. Unter der Shell jedoch schon.

Keine Ahnung was sein soll.. ich hoffe mal das ich mir mit der Nutzung von vfs_fruit keine nachträglichen Probleme einhandel. Ist aber auch nicht so wichtig.. denn ich kann die Dateien unter Windows oder Shell jederzeit kopieren und das original löschen.

 

[Henning Kessler]

uff das nenne ich mal ausführlich ;-).

Vielen Dank für die vielen Hinweise. Mal sehen ob ich auf meiner Testmaschine wieder ein paar Tests mache. Zur Zeit läuft es auf meinem Produtionsserver mit 9.10.1 noch alles gut. Meine gegenwärtige Strategie ist noch auf den Fix von den Entwicklern zu warten...

Liebe Grüsse und einen guten Rutsch

Henning

 

[ObiTobi]

Also für mein Gefühl, rühen "alle" Deine Probleme auf dem Ur-alten "locking Problem" mit Samba bzw. der SMB Implementierung unter Samba.

Mit folgenden Einstellungen habe ich seit Jahren keine Probleme damit. (Achtung - ich will es einfach nutzen und nicht jeden Tag nach irgendwelchen Versuchen zu googlen o.ä Es mag also gut sein, dass es in der Tat andere Möglichkeiten gibt)

in Global

socket options = TCP_NODELAY


Auf einem Share wo Dateien wie Word/ Excel & Co abgelegt/ Editiert werden.

hide dot files = yes
kernel oplocks = no
oplocks = no
level2 oplocks = no
blocking locks = no
veto oplock files = /*.doc/*.DOC/*.docx/*.DOCX/*.docm/*.DOCM/*.dotm/*.DOTM/*.xltm/*.XLTM/*.xltx/*.XLTX/*.xlsx/*.XLSX/*.xlsm/*.XLSM/*.xlsb/*.XLSB/*.xls/*.XLS/*.ppt/*.PPT/*.pst/*.PST/*.mdb/*.MDB/*.ldb/*.LDB/*.vsd/*.VSD/*.mpp/*.MPP/*.qbw/*.QBW/*.qbb/*.QBB/*.qbI/*.qbl/*.dxf/*.DXF/*.dwg/*.DWG/*.cdr/*.CDR/*.bak/*.BAK/*.ord/*.xlo/*.igs/*.ipt/*.ipj/*.slp/*.stp/*.opt/*.xli/*.stl/*.cur/*.sjb/*.log/*.LOG/*.sbs/*.iam/*.idv/*.pcbdoc/*.PcbDoc/*.PCBDOC/*.dbf/*.DBF/*.cdx/*.CDX/

Die Settings habe ich mir gesetzt als ich noch komplett unter Linux Unterwegs war. Sind also gut 12-13 Jahre alt. Funktionieren hier immer noch bestens. Auch mit OSX :D
Auch wenn ich bei OSX doch AFP bevorzuge, zumal ich min. Ein Sahre mit AFP für Time Maschine brauche.

 

[coolblue81]

Hi,

sind oplocks nicht wichtig, um zu vermeiden das zwei Clients die gleiche Datei editieren können? In der Regel deaktiviert man oplocks nur für Database Files z.b. *.mdb

Ich habe grade mal geschaut, in meiner smb4.conf ist oplocks aktiv und eben unix extensions ausgeschaltet. Seit dem läufts bisher hier sehr gut.

Wozu eigentlich die liste der veto oplock files wenn du oplocks sowieso global deaktiviert hast?

 

[ObiTobi]

Das Problem mit oplocks bzw der SMB Implementierung ist - die Anwendung will sicherstellen, dass keine andere die offene Datei verändert.
Und die Samba Entwickler haben es als etwas zuschaltbares entwickelt. Für mich ein Unding

Ob das mit der Liste immer noch so sein muss kann ich dir nicht sagen. Damals war es so. Und als ich vor 3 Jahren Freenas aufgebaut habe und auf erste Probleme stieß, habe ich meine alte Samba konfig geholt und die Teile eingebaut. Es läuft.

Um es vielleicht frech/überheblich zu sagen - ich habe keine Zeit und auch keine Lust mehr Monate und Wochen Experimente zu machen wie noch vor 20 Jahren. Jetzt will ich einfach nur arbeiten können

Wenn ich mit Windows Server die gleiche Möglichkeiten hätte zfs und dann AFP und NFS zu machen, wurde ich auch Windows nehmen.

Gesendet von meinem SM-G920F mit Tapatalk

 

[coolblue81]

Also nach allem was ich in der Samba smb.conf Manpage gelesen habe, ist die Default Einstellung für oplocks absolut korrekt. Grade der Performance Vorteil das die Clients die Datei komplett ohne Rückfragen cachen dürfen, ist sicherlich von großem nutzen.

Als langjähriger Windows Administrator bin ich auf reiner Windows Ebene bestens mit Dateisperren vertraut, denn dort sind sie default auch enabled.

Das schließt natürlich nicht aus, das sie ggf. buggig implementiert wurde oder ggf. mit ZFS nicht richtig zusammen arbeitet. Wobei laut Manpage die Oplocks Tabelle im RAM des Samba Daemons gespeichert wird. (Ausser kernel oplocks ist auf enabled.. default ist das aber aus)

Da ich noch ein ZFS installieren muss, kann ich das da (deine obige Beispiel Konfig) mal bei Gelegenheit testen.. dann hab ich zwei Vergleichswerte.