Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Paragon "extFS für Mac" - Erfahrungsberichte?

Paragon "extFS für Mac" - Erfahrungsberichte?

xcomma13.02.2315:17
Hallo!

Kurze Frage: hat jemand Erfahrungen gemacht mit dem Produkt "extFS für Mac" von Paragon und kann dazu ein bisschen was berichten?

Ausgangssituation bzw. Anforderung:
  • auf eine ext4 Festplatte lesend wie auch schreibend zuverlässig zugreifen zu können (optimalerweise auch die Funktionen Partitionieren und Formatieren)

Denkbare Optionen:
  • via einer lokalen Linux VM "einbinden und durchschleifen"
  • via Produkt "extFS für Mac"
  • via macFUSE
  • via fuse-ext2
  • via separater Linux Maschine (Netzwerkfreigaben)

Lokale Linux VM
Die Option scheint sich gut zu eignen, wenn der Use Case nur selten bzw. gelegentlich mal anfallen sollte. Daher keine Option in meinem Falle.

macFUSE
Gemäss diverser "Internetberichte", sowie spätestens auch der Info auf der offiziellen Webseite, ist es für schreibende Zugriffe nicht geeignet bzw. nicht angeraten (rein für lesende Zugriffe sei macFUSE wohl eine gute Option):
https://github.com/osxfuse/osxfuse/wiki/Ext
Although write support is available (and pretty stable) please do not mount your filesystems with write support if you have something to lose.

fuse-ext2
Ich bin nicht sicher, ob dieses dasselbe darstellt oder eine Art "Dropin Replacement" ist für den Ext Support via macFUSE, da dieses Projekt ebenfalls auf macFUSE hinweist.
Jedenfalls verweist es ebenfalls auf Unsicherheiten hin bzgl. des Write Supports und kann damit nicht als gute Option eingesetzt werden, selbst wenn in einem (paywalled, hab leider den vollständigen Artikel nicht) heise Artikel "gute Erfahrungen" damit erwähnt werden.
https://github.com/alperakcan/fuse-ext2
Even though write support is available, please do not mount your filesystems with write support unless you have nothing to lose.

Netzwerkfreigabe via separater Linux Maschine
Zuguterletzt, die Platte direkt an eine reine Linux Maschine hängen und Zugriff via Netzwerkshare ermöglichen.
Mir wäre das direkte dranhängen aber lieber, wäre aber "zur Not" eine denkbare Option, sollte sich ein Eindruck ergeben, dass das extFS Produkt sich nicht als sonderlich zuverlässig / stabil / "angesehen" herausstellt.

--

Auf den ersten Blick also derzeit Paragons extFS - soweit sich keine Negativberichte auffinden lassen.
Gibt es sonst weitere Hersteller/Produkte oder ist Paragon hier der einzige Anbieter?
Und ist dieser für Qualität / Zuverlässigkeit bekannt? Speziell auch mit diesem Produkt?

Danke für eure Erfahrungsberichte.
+1

Kommentare

Legoman
Legoman13.02.2315:48
Habe Paragon genutzt.
Allerdings nur, um die Daten einer Platte zu überspielen.
(Ist schön, wenn man die von nem Linux-Nutzer bekommt, der dann nur mit den Schultern zuckt.)
Hat soweit alles gemacht, was es sollte.
0
KarstenM
KarstenM13.02.2317:19
Ich stehe auch schon seit Wochen vor der Überlegung, mir dieses Produkt zu kaufen, konnte mich aber noch nicht dazu durchringen. Die Demo lief zufriedenstellend.
+1
113713.02.2318:06
Seit Jahren ist Paragon auf all meinen Macs installiert gewesen, (und ist es noch) hat immer tadellos funktioniert. Hatte vorher andere Programme zum testen Tuxera, Fuse aber keins hat mich überzeugt. Mit Paragon bin ich glücklich geworden.
+4
Apfel
Apfel14.02.2310:07
1137

Ist es auch möglich mit paragon eine Festplatte zu formatieren?
+1
jeti
jeti14.02.2311:13
Nutze seit vielen Jahren NTFS für Mac:
läuft zuverlässig und verrichtet unauffällig seinen Dienst.
+1
xcomma14.02.2313:09
Danke soweit für's Feedback. Paragon kennt man in erster Linie für ihre NTFS Treiber vermutlich, die wohl auch ihren Dienst gut verrichten. Die Differenzierung nach Produkt ist dann angesagt. Habe gestern Abend "ExtFS for Mac" (Trial Periode) installiert und bin wider Erwarten auf erhebliche Probleme gestossen. Da ich nicht mit so was gerechnet hatte, habe ich auch nicht von Anfang an eine sauber strukturierte Testreihe angelegt, die hier aber nun notwendig zu sein scheint. Jedenfalls ist meine Ext4 Platte (Testplatte noch, daher noch kein eigentlicher Datenverlust zu beklagen) 2x in einen korrupten Zustand gelangt.

An was ich mich erinnere in dem ganzen Gewusel:
ExtFS installiert; dies hat zur Folge, dass dann die Ext-Auswahl auch im regulären Disk Utility zur Auswahl steht, so dass man die Formatierung dort vornehmen kann - oder aber über die GUI von ExtFS ("erase" in beiden Situationen).
Zunächst erstmal eine kleine Verwirrung, da Paragon hier die Dateisysteme mit "ExtFS 4" usw. betitelt, anstatt "ext4". Es wird hoffentlich nur eine (aus meiner Sicht etwas unglückliche) Benamsung sein und hoffentlich ein "normales" ext4 angewendet und keine eigene Abwandlung davon.
Eine damit formatierte Platte war dann im Finder grundsätzlich zugreifbar und hat soweit funktioniert (keine grossen Kopier-Aktionen etc. gemacht).

Als nächstes wollte ich schauen, ob eine von "Paragon ExtFS" Platte auch in einem Linux "sauber als ext4" erkannt wird. Und hier fingen die Probleme an, die ich allerdings wegen unstrukturiertem Vorgehen nicht eindeutig dem ExtFS Produkt im Moment zuordnen kann.

Ich habe in Virtualbox V7 ein Linux Mint eingerichtet, bekam aber die "ExtFS 4" Platte einfach nicht ran.
Habe dasselbe unter VMWare Fusion Pro (Trial Version installiert) probiert, ebenfalls ohne Erfolg.
Es war dann bereits schon seltsam, dass die Virtualisierungslösungen die "Ext"-Platte mit teils unterschiedlichen Labeln (zunächst) erkannt haben wollen (also um sie in der Auswahl zur Verfügung zu stellen zum Hinzufügen zur VM). Das eine Label war "EFI", das andere Label war "Boot OS X" - die überhaupt gar nicht auf dieser Testplatte vorhanden waren. Irgendwann aber zeigte es auch mal (hier bereits nach mehreren weiteren, nicht mehr nachvollziehbaren Schritten) den erwarteten Namen (diverse Varianten im Laufe der Zeit, in der Art von "testext4" usw.) an. Unter Linux Mint - bei Virtualbox wie auch VMware - ging jedenfalls nichts. Und in dem Zuge wurde die Testplatte korrupt, so dass das Disk Utility diese nicht mehr öffnen könnte um z.B. sie neu zu "erasen" bzw einzurichten. Mehrfaches Neustarten des Systems hat nicht geholfen. Erst - leider habe ich 2 Schritte zusammen gemacht - als ich das ExtFS deinstalliert habe und dazu auch die externe USB Platte einmal komplett abgeschaltet habe (also vom Strom genommen habe), konnte Disk Utility letztendlich wieder die Platte "öffnen" und eine Formatierung war dann wieder möglich. Um auszuschliessen, dass generell etwas mit der USB Platte ist, habe ich diese in HFS formatiert und problemlos in eine Monterey VM (VMware Fusion) einhängen können.
Erneut habe ich ExtFS installiert, in "ExtFS 4" formatiert und ein anderes Linux ausprobiert (Ubuntu in VMware). Dieses Mal klappte die Erkennung auch wie man es sich vorstellt (allerdings hatte ich später auch wieder die Situation, dass Ubuntu+Vmware die Platte auch nicht mehr erkannt haben, was evtl. ein "Testaufbau" war, wo die Platte zwischenzeitig bereits von VirtualBox wieder "verunreinigt" wurde). Dann der Test mit Ubuntu auf Virtualbox und es hat dann nicht mehr geklappt. Die Platte ist dann in den diversen Versuchen auch wieder korrupt geworden.
Eine identische Fehlerbeschreibung habe ich in Foren gefunden und einer hatte für sich zumindest das Problem lösen können in dem man anstelle von Version 7 Virtualbox auf Version 6 runtergeht. Das hat aber leider nicht in meinem Falle geholfen.
Anbei ein paar Screenshots, aber wie gesagt, es ist leider keine sauber strukturierte Testreihe, da ich unvorbereitet auf diese Szenarien gestossen bin.
Mein "Glaube" derzeit ist, dass es an Virtualbox liegt, kann aber noch nicht ausschliessen, dass ExtFS nicht auch einen Anteil an den Problemen haben könnte.
Es bräuchte strukturierte Testabläufe um das eine / andere belegen bzw. widerlegen zu können.

Es gibt keine Partition die "Boot OS X" heisst auf der Testplatte:


Ebenfalls gibt es keine "EFI" Partition auf besagter externer Testplatte:


Irgendwann war das Plattenlabel mal korrekt, aber die Platte wurde nicht ordentlich erkannt und VMware bietet keinen Abbruch an, sondern bietet nur einen "Ok" Button an, so dass man den Versuch die Platte einzubinden nicht generell hier abbrechen kann, sondern der Versuch wird definitiv ausgeführt - und in diesem Zuge vermute ich könnte mit ein Grund liegen, dass die Platte korrupt wird:


Fehlermeldung bei Virtualbox, dass die Platte nicht zur VM eingebunden werden konnte:


Obwohl in einem ersten Anlaufversuch Ubuntu + VMware die Testplatte erkannt wurde (auch mit richtigem Label), ist zu einem späteren Test - evtl. hatte ich dazwischen mal wieder einen Virtualbox Versuch gestartet - wiederum mit Ubuntu die Platte wieder im Problemzustand, dass schon das Label nicht mehr korrekt ist:


Eine korrupte gewordene Platte durch diese "Einbinden in eine VM"-Versuche, ist dann auch nicht mehr erkennbar in ExtFS:


Mehrere MacOS Neustarts halfen nicht - man wird so begrüsst bzgl. dieser Platte:


Zu einem Zeitpunkt X hatte ich die Platte dann in einer der Linux VM mal wieder, die ein "structure needs cleaning" Fehlermeldung hervorbrachte und ich eine "repair"-Aktion unter Linux laufen liess. Danach war die Platte im Linux sichtbar, zugreifbar, Testdaten waren da:


Aber direkt danach (VM beendet) und via ExtFS GUI ein "verify" drüberlaufen lassen, brachte diese Fehlermeldung, sowie hing der Prozess eine ganze Zeit lang (zu lang) und hab den Prozess killen müssen, da ExtFS nicht zu Potte kam:


Sobald die Testplatte in diesem seltsamen Zustand war, konnte auch Disk Utility diese nicht mehr bearbeiten. Es kam immer dieser Fehler, selbst nach mehreren MacOS Neustarts. Erst nachdem ich ExtFS deinstalliert habe und (leider "und", hatte in dem Moment nicht an separate Testeinzelschritte gedacht) die USB Platte einmal komplett vom Strom nahm (während der Mac aus war), kam dieser Fehler nicht mehr und es war möglich sie dann neu einzurichten:
+1
Wellenbrett14.02.2313:40
Hi xcomma, ich habe Deinen langen Beitrag bis zur Hälfte gelesen und bis dahin ist mir eine Sache aufgefallen, die Dir vielleicht schon weiterhilft:

Eine externe Festplatte im ext4-Format zu formatieren, um sie mit eigenen Nutzerdaten zu beschreiben ist wesentlich simpler, als eine Festplatte einzurichten, damit ein Betriebssystem damit arbeiten kann. Ein Linux-Installer partitioniert die Festplatte beispielsweise (meistens in drei Partitionen). Diese Einrichtung der Festplatte für die Verwendung durch das jeweilige Linux-System würde ich dem Linux-Installer überlassen (das geht auch wenn sich das zu installierende Linux-System in einer VM befindet) und nicht auf dem Mac mit dem Festplattendienstprogramm oder der Paragon-Software durchführen. Wenn Du dann diese Platte mit dem so eingerichteten Linux-System am Mac mountest, solltest Du mit installiertem Paragon-Treiber lesend und schreibend daran zugreifen können, außer Benutzerrechte sprechen dagegen - die können aber per Finder-Einstellung umgangen werden.

Eine Festplatte nur für Nutzerdaten dagegen, die Du mit der Paragon-Software im ext4-Format formatierst, sollte problemlos unter Linux funktionieren, ebenso eine separate Festplatte, die Du unter Linux formatierst, auf dem Mac (mit Paragon-Treiber).
+1
xcomma14.02.2313:54
Hallo Wellenbrett,
Danke für die Differenzierung nach Einsatz "als Systemplatte" oder "als Datenplatte".
Das hätte ich besser beschreiben sollen. Und der Einsatz wäre auch genau so wie du es beschreibst. Also die "Ext4 als Datenplatte" zu nutzen - und nicht als Systemplatte.

Die Linux VMs bzw. deren Installer habe ich einfach machen lassen mit dessen Default-Einstellungen, da ich die Test-VMs danach wieder lösche und es dann auf ein ausgefeiltes Partitionierungsschema nicht ankommt.
Die VMs sollten nur als Test-Vehikel dienen.

Selbst wenn man eine Ext4 Platte mittels ExtFS for Mac problemlos auf dem Mac betreiben kann - so ist es brandgefährlich (nach meinem aktuellen "Test"-Stand), sollte man jemals meinen diese an eine VM zu hängen - die die ganze Platte in Mitleidenschaft ziehen kann.

Leider ist im Moment unklar, wo das Übel herkommt. Also etwas und womöglich ausschliesslich nur in Virtualbox? Oder doch ein Zusammenhang von installiertem ExtFS mit VMs, unabhängig des Virtualisierungsprodukts? Das müsste ich strukturiert mal testen.
0
Wellenbrett14.02.2314:10
xcomma
...
Selbst wenn man eine Ext4 Platte mittels ExtFS for Mac problemlos auf dem Mac betreiben kann - so ist es brandgefährlich (nach meinem aktuellen "Test"-Stand), sollte man jemals meinen diese an eine VM zu hängen - die die ganze Platte in Mitleidenschaft ziehen kann.
Also ist das problematische Setup dann das folgende: am Mac als Hostsystem wird eine VM mit Linux-Gast betrieben. Dann wird eine externe Daten-HDD, die zuvor am Mac mit der Paragon-Software in ext4 formatiert wurde angeschlossen und unter der Linux-VM gemountet?
0
xcomma14.02.2314:33
Wellenbrett
[..] und unter der Linux-VM gemountet?
Fast. Meine (unqualifizierte) Vermutung geht in die Richtung, dass es zur Phase des eigentlichen Mountens (.. was für ein Wort ) innerhalb der Linux-VM erst gar nicht kommt. Sondern die Virtualisierungslösung scheint nicht in der Lage a) die USB-Platte - selbst wenn sie am Anfang in Ordnung ist - ordentlich zu erkennen ("komische Labels"), und b) diese dann auch "ordentlich in die VM hineinzureichen". Stattdessen wird bei dem Versuch (den man bei VMware nicht abbrechen kann, aber immerhin eine vorgelagerte Meldung bekommt; und bei Virtualbox eine nachgelagerte Fehlermeldung bekommt) eine solche Platte einzuhängen, diese nachhaltig beschädigt in ihrer Struktur, dass selbst Mac "Host"-Neustarts sie nicht mehr in Disk Utility bereitstellen kann.

Der Versuch die Platte also durch eine Virtualisierungslösung in die VM zu bekommen geht schief und beschädigt sie, die Platte wird aber im vorhinein bereits nicht korrekt erkannt (nicht korrekt durch die VM Produkte, aber sie ist ordnungsgemäss erkannt auf dem Host System.. vor dem Versuch diese durch die VM Produkte "benutzen" zu lassen natürlich) - und diese war mit ExtFS formatiert und der Treiber war (obwohl nicht immer, hatte den Treiber auch mal deinstalliert und später mal wieder installiert usw.) zumindest beim ersten Lauf installiert.

Ich müsste eigentlich die Platte durch ein "natives Linux" mal einrichten und ganz ohne ExtFS mal in diese VMs bringe - das wäre der Standardfall und sollte "normalerweise" klappen (sonst hätten die Virtualisierungslösungen dieses Problem schon viel früher sicherlich gehabt / erkannt / gelöst).

Daher ein "Beigeschmack", ob nicht auch ExtFS als Treiber im System hier mit eine Rolle spielt.
0
xcomma14.02.2314:53
xcomma
Daher ein "Beigeschmack", ob nicht auch ExtFS als Treiber im System hier mit eine Rolle spielt.
Bzw. da ich es einmal doch geschafft hatte (ordnungsgemässes Platten-Label, problemloses Hineinreichen, Zugriff von Linux auf die Platte) mit "VMware + Ubuntu" - tendiere ich (obwohl derzeit eine strukturierte Testdatengrundlage fehlt, die isolierte Betrachtungen und Rückschlüsse ermöglichen könnte) dazu die problem-auslösende Situation erstmal auf die Kombination "Virtualbox + ExtFS" zu reduzieren.
Einmal die Platte unter dieser Kombination "behandelt" - schienen dann Probleme danach eher Folgeprobleme und daher in Zusammenhang damit zu sein. Die Details bekomme ich aber nicht mehr auseinandergedröselt.
0
Wellenbrett14.02.2314:54
Ok, jetzt habe ich verstanden, worum es geht. Zumindest VMWare Fusion bringt ja beim Anschliessen einer externen Festplatte bzw. generell beim Anschliessen von Peripherie ein Dialogfenster, ob das Peripherie-Gerät an den Host oder den Gast gehen soll. (VirtualBox habe ich schon ewig nicht mehr verwendet.) Vielleicht hat sich der Paragon-Treiber zu diesem Zeitpunkt die Festplatte aber schon "gekrallt" und ignoriert dann, dass die Virtualisierungssoftware die Festplatte evt. an das Gastsystem übergibt. Dann greifen zwei Systeme gleichzeitig darauf zu: das würde die Defekte erklären. Vielleicht teilt die Virtualisierungssoftware aber auch dem Paragon-Treiber nicht korrekt mit, daß ihm die Festplatte noch nicht oder nicht mehr "gehört". Bei der letzten Variante könnte der Wechsel der Virtualisierungssoftware helfen.
(Nachtrag: hatte ich vor Deinem letzten Beitrag von 14:53 Uhr geschrieben)
0
xcomma14.02.2315:09
Wellenbrett
der Paragon-Treiber zu diesem Zeitpunkt die Festplatte aber schon "gekrallt" und ignoriert dann
[..] Dann greifen zwei Systeme gleichzeitig darauf zu
Klingt gut, also als vermutete Ursache.
Dazu passt eigentlich auch irgendwie die Richtung der Fehlermeldung - zumindest bei Virtualbox:
VERR_SHARING_VIOLATION
Wellenbrett
Wechsel der Virtualisierungssoftware helfen.
Ich weiss leider nicht mehr, ob ich den ExtFS Treiber deinstalliert hatte und die Platte zunächst noch ordnungsgemäss war - als es mit "VMware + Ubuntu" einmal geklappt hatte.

Wenn man sicher wüsste, dass man mit "installiertem ExtFS" Treiber innerhalb von MacOS auf ext-Platten problemlos zugreifen kann und man Abstand von VMs halten soll, oder aber ExtFS deinstalliert sein muss, sollte man ext-Platten an VMs mal andocken wollen, wäre das zumindest - wenn auch unschön - aber mal ein Workaround an dem man sich strikt halten muss, wenn man seine Daten nicht schrotten will.

Ob das nun seitens VM Produkten, oder seitens ausschliesslich Virtualbox oder doch ausschliesslich auf einen Implementations-Fehler bei ExtFS zurückzuführen ist, ist komplett jenseits von dem, was ich feststellen geschweige denn technisch verstehen könnte.
0
Wellenbrett14.02.2315:23
Hm, vielleicht macht folgende Überlegung, die Entscheidung für den geeigneten Test einfacher: die Auswahl an Virtualisierungssoftware ist größer als die Auswahl an ext4-Treibern für macOS. Die Installation und Deinstallation des Paragons-Treiber ist ja keine großer Aufwand. Ich würde also VirtualBox austauschen und dann mit einer mit Paragon-Software neu formatierten externen ext4-HDD und VMWare Fusion testen. (Ich weiß, Du hattest diese Kombination vorher schon, aber wenn ich das richtig verstanden habe nicht unter ausreichend kontrollierten Bedingungen, d.h. das ext4-Filesystem auf der externen Festplatte könnte bereits korrumpiert gewesen sein)
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.