sysutils/fusefs-smbnetfs: WindowsServer SHARE mit unmöglichen ACLs: d--w--w--w

Eisenfaust

Well-Known Member
Hallo Forum.

Ich/wir entwickeln und arbeiten mit FreeBSD (derzeit 13.0-RELENG, 13-STABLE und 14-CURRENT) innerhalb eines Windows dominierten Netzwerkes. Die entsprechenden Datenspeicher werden hauptsächlich über einen > Windows 2016 Serverdienst bereitgestellt. Nun ist es leider so, daß wir ab und an auch auf diese SHARES zugreifen müssen, insbesondere die Ablage von Dateien eines Projektes werden über SMBv2/v3 Shares angeboten. Wir müssen auf diese Shares lesend und schreibend zugreifen können.

Aufgrund von Sicherheitsvorgaben werden diese Shares nicht mehr via SMBv1/CIFS dargeboten, weshalb der FreeBSD-eigene CIFS Dienst nicht mehr eingesetzt werden kann. Um eine bequeme Alternative einzurichten habe ich mit sysutils/fusefs-smbnetfs ein Share versucht einzubinden, mit kuriosen wie auch fatalen Folgen.

Grundsätzlich: mein FreeBSD Client "sieht" das Share, FUSE ist im Kernel vorhanden. Ich kann mein les- und schreibbares Share binden. Als Dateimanager verwenden wir Xfe (Port x11-fm/xfe) bzw. Terminal und hier wird via cd das Dateisystem traversiert. Auffällig ist, daß der Eigentümer ALLER Dateien und Verzeichnisse meine Wenigkeit ist und daß alle Dateien und Verzeichnisse krude Access Bits haben, nämlich

Dateien: --w--w---w
Verz. d--w--w--w

Von SAMBA kennt man ja eigenwillige Abbildungen der Zugriffsrechte. Nichtsahnend haben wir dann begonnen, wichtige dateien zu öffnen und zu bearbeiten. Unter FreeBSD 13.0-RELENG ging das - zu den wirren Phänomenen später mehr - die Ernüchterung kam allerdings beim Abspeichern der Dateien: die wurden im originalen Windows Dateisystem nämlich plötzlich auf 0 Bytes gesetzt, das Filehandle wurde nie mehr gelöst, entweder "frieren" Xfe ein oder das Terminal (xterm), mit dem wir den Dateibaum des SMB Shares traversieren, reagiert nicht mehr. Die von FreeBSD tatsächlich geöffnete Datei ist auf dem Windows Fileserver dann zerstört - 0 Bytes sind 0 Bytes. Wenn das zufällig die gemeinsam genutzte Keepass-DB ist, wars das dann, bis das Backup zurückgefahren ist.

Xfe und xterm verhalten sich beide nicht deterministisch, wenn wir einen derartig eingebundenen Dateibaum eines Windows Server traversieren, mal kann ich die ein oder andere Verzeichnisebene erreichen, ein anderes Mal friert freeBSD bereits beim versuch ein, mittels "cd" das Verzeichnis zu betreten, auf das das SMB Share gebunden ist, in den meisten Fällen friert Xfe einfach ein und läßt sich auch nicht mehr "killen", im Terminal erscheint dann lapidar:

total 0
ls: .: Input/output error

Versuche, mittels diversen und vielfältigen Konfigurationsoptionen die Zugriffsrechte des eingebundenen Dateisystems für das FreeBSD UNIX Dateisystem handhabbar zu gestalten, schlugen fehl.

Ich bin ratlos. Wir (vor allem ich) arbeiten mit CLI Werkzeugen, ich nutze weniger GUI gestütze Filemanager.

Hat jemand ähnliche Erfahrungen und weiß Rat?

Danke im voraus.
 
Moin,

ich habe leider keinen direkten Lösungsvorschlag oder eine Idee, was das Problem sein könnte. Hast du mal net/samba412 versucht um die Freigaben einzubinden?

HTH
 
Ich habe ein ähnliches Problem aktuell mit smbnetfs.
Problemlos kann ich in die Shares rein mit "cd" und mir Dateien mit "ls" anzeigen lassen. Ich kann auch Dateien mittels "rm" auf dem Share löschen, aber schreiben geht nicht auf dem Share. Ob jetzt ein "cp foo.txt share/" oder "echo "foo" > share/foo.txt"
es wird alles mit einem "Input/output error" quittiert. Im Log steht was von "smb_conn_srv_fstat: errno=22, Invalid argument"
 
Zurück
Oben