I’m thinking the same as restricted.networks.access option but for volumes, potentially with RW/RO option as well as an option for users of restricted projects to share a volume with other projects.
Of course, I could disable features.storage.volumes and share volumes with Default… It’s all or nothing though… Default, Project A and Project B (and all other projects ever needing to share a volume) will live in a common space…
I know restricted.storage-pools.access exists, to alleviate the above, but it doesn’t work well on IncusOS where pools are not exactly the easiest to define and manage. Plus, it’s very coarse… Two projects can share the same pool but for data to be visible in both, restrictions on volumes must be removed so that they can share volumes. If restrictions on volumes are removed, any other volume contained in other pools (like local) will be made accessible too. Which is constraining in other ways.
I know buckets are a thing but not everything supports it, it’s very slow when handling a gazillion small files or doing a lot of random access, and it’s exposing files to the network, which can be restricted to a single potentially isolated IP, but it’s all or nothing again nontheless.
NFS sounds like a compelling solution… It’s better than S3 performance-wise but it’s faff to setup (requires a VM to start with and actual network work).
Ceph & co I know are the actual solution to this but it’s even more of a faff to setup.
I’d love to “just” be able to say "make local/project_a/my_data available RW (or RO) to project_b, at least on non-clustered systems but for a cluster, you want some sort of network capacity.