私はこの種のことを何年もやってきたので、おそらくあなたが私が経験したのと同じ痛みを避けるのに役立つでしょう。
クラウドストレージは、一部のユースケースには理想的ですが、追加の作業なしでプライバシー/セキュリティについて大ざっぱであり、大量のデータを含むユースケースには必ずしも適していません。（私は透過的なファイルごとの暗号化でセキュリティ/プライバシーの問題を回避し、さまざまなユースケースのために、以下で概説したソリューションと並行してこれを使用します。）
次に、実行可能性の高い順にローカルストレージソリューションを示します（本質的に主観的であり、特定のユースケースに依存します）。
- exFAT：一番下にあるのは、私自身の経験不足と、比較的新しいことだけです。あり、互換性の問題が異なるため、ブロックサイズのプラットフォーム間で。どうやら、1024バイト未満のブロックサイズでWindowsのドライブをフォーマットすると動作する可能性があります。
- NTFS：NTFS-3Gにはあらゆる種類の問題があり、Windows、Mac、Linuxを行き来しています。ファイルの破損、データの損失など。これは数年前のことで、今はもっと良いかもしれませんが、当時は堅調に「売れ」ていましたが、そうではありませんでした。
- FAT32：私の経験では、これはMac、Linux、およびWindowsを橋渡しできる唯一の真の「クロスプラットフォーム」ファイルシステムです。（そして、カメラ、およびテレビなど）ファイルごとに4GBのサイズ制限と2TiBの合計ボリュームサイズ制限があります。Fat32Formatterを使用すると、理論上は32GB FAT32の制限を克服できますが、システム間でどのように互換性があるのかわかりません。理論的には、FAT +は256GiBファイルを許可し、より大きなブロックサイズを使用します。
- ネイティブファイルシステムをCIFSを介してホストOSと共有する仮想マシン：これは、ほとんどのユースケースに最適なソリューションです。
何年も前にNTFS-3Gを使用してデータ破損にうんざりしたとき、Windows 2000を実行している小さなVMの使用を開始し、CIFS経由でホストOSとNTFSボリュームを「ネイティブに」共有しました。パフォーマンスは、直接接続されたストレージと比較することはできませんが、データの破損と、それが引き起こした不信と頭痛に別れを告げることになりました。Windows 2000でフォーマットされたNTFSは、VM内のWindows 2000とWindows Vista（当時）の切り替えなど、最新バージョンのWindowsと問題なく互換性を持って機能しました。
それでも、NTFSは、ミラー化された構成（特にRAID5構成）であっても、大量のデータを長期間にわたって確実に格納するのに十分なほど堅牢ではありませんでした。主にビットロットとチェックサムの不足が原因です。確かに、それは長い間、最高のものでしたが、それ以上ではありませんでした。
現在、私が使用している唯一の「クロスプラットフォーム」ファイルシステムはZFSであり、VMで実行されているLinuxによってCIFSを介して提示されます。（また、最近BTRFSを使用するようになりました。これは最近、ユースケースの安定性のしきい値を超えたようです。長い間、実験的にしか使用せず、しばしば私を失望させました。）
Mac OSではZFSを使用せず、LinuxではZFSのみを使用します。（私は、Oracleが台無しにするまで、最新のZFS機能の純度とサポートのために、OpenSolaris VMを使用してZFSをホストしていました。）
ZFS for Macをしばらく試してみましたが、あまりにも不安定で古くなっていました。たぶん今は大丈夫かもしれませんが、私のVMソリューションは完璧です。そして、先ほど言ったように、とにかくBTRFSを使用するようになりました。これは、私の要件（多くの点でZFSが常に提供してきた堅実な信頼性です）によりよくマッチしています。
Macをトリプルブートし、Linuxをネイティブに実行していないときは、VMで同じネイティブLinuxインストールを実行します。Linuxは、ゲストを追加してVMで実行することとネイティブで実行することを交互に行うことで完全に満足しています。ネイティブで実行していない場合、CIFSを介した「ネイティブ」ZFSまたはBTRFSボリュームアクセスのために、ほとんど常にLinux VMを実行しています。
大規模な「クロスプラットフォーム」の信頼できるストレージへの低速なCIFSアクセスに対応するために、ほとんどのワークフローをシームレスに調整しました。たとえば、大量の作業データへの高速アクセスが必要な場合、通常はその特定のホストOSに固有のアプリケーション内にあり、プラットフォーム間でアクセスできる必要はありません。そのため、OSがネイティブで使用可能な高速ローカルSSDストレージを使用し、低速の「クロスプラットフォーム」ストレージに定期的なコピーを作成します。具体的なユースケースに応じて、プロジェクトが完了したときにのみ作成します。
ヒント：VMルートを使用すると、ブリッジアダプターを介してVMファイルシステムを共有したくなるでしょう。その利点は、VMが同じサブネット上に独自のIPアドレスを持ち、そのサブネット上の他のコンピューターからでもストレージにアクセスできることです。ただし、ブリッジアダプターの欠点は1）特定の物理アダプターに関連付けられているため、たとえば有線から無線に切り替えると、VM内からインターネット接続が失われる可能性があることです（これは、 VMを生産性OSとして使用します。通常どおりです]。また、2）ブリッジアダプターは細心の注意を要する場合があります。時には「うまくいく」こともありますが、問題がある場合は、トラブルシューティングが非常に面倒です。より良い解決策は、2つのアダプターでVMを構成することです。A）NAT（VMからのインターネットアクセスの場合、物理アダプターが提供するものに関係なく動作します）、およびB）静的IPアドレス、DNSまたはゲートウェイなし、virtioアダプター、および無差別モードで構成されたホストのみ。ローカルマシンのみがVMのCIFS共有にアクセスできます。このソリューションをセットアップするのは簡単なことではありませんが、一度実行すれば基本的に魔法です。
幸運を！