I suppose I should of linked the fix, for applehv at least.

I noticed that -v $(pwd):/VOLUME/:z, you didn't designate the :z or :Z, which has to do with SELinux labels, and being able to 'share' that resource between the containers. Thinking: I wasn't sure how macOS would actually handle that xattr; as it diffs from VM frameworks

github.com/containers/p...

I'm also currently trying to unpack this muck as it relates to the resource of networking (tailscale implementation) across this same 3 layer relationship.

I don't have a good resource; it seems to be an issue or working with 'bleeding edge', and a lot of constantly moving parts, overcoming/adapting to new abstractions of usage, and previous limitations.

The context here is mapping a shared resource ie volumes/files & their permissions from MacOS <-> podman-machine <-> Container. You're traversing a 3 layer relationship, not just a two layer 'container user/group', and 'host user/group' relationship in this context.

2) Use one "podman-machine" but change the MacOS volume you mount to also be where you are doing, 'pwd'/'work' ie organization through your volume/file structure.
PRO: Simplicity to manage.

1a) How you describe: Create multiple podman-machine
1b) set podman-system-connection to the different 'podman-machine' name.
PROS: +compartmentalize your projects, additionally control this dev environment to match actual/prod project env (ie x86 container-host use cases)
NEG: +complexity to manage

I want to be clear that we're trying to address the limitations of this being within MacOS; You cannot dynamically mount arbitrary macOS directories after a podman-machine is created in this environment. How do you want to address this limitation?

technically speaking, docker has to do something very similar; create a default VM to run containers within, on MacOS and Windows. This paradigm was similar on say Proxmox, and you typically rolled out your own VM to run docker/podman containers, as proxmox (until recently) only supported LXC native

I’m not sure if you’re following. MacOS and Win need an environment to run containers locally. A single ‘podman-machine’ VM is created , and only one can be used at a time for this task. ie your ‘podman run’ commands are actually being executed on this VM, It’s suppose to act kind of invisible.

You might have to look into how you deployed podman-machine, for usage on MacOS. Examples found here: xphyr.net/post/podman_...

I'd would then like to then use Tailscale SSH to remote manage the podman-machine. I would then sidecar tailscale onto my containers for their individual usages and portability, instead of trying to manage them individually through tailscale serve.

I doubt I have the follower base to get any of these things answered; but here's to trying :D Thank You!

RTFM, I have read that there are restrictions on what can be used for podman-machine, but I'm struggling to find actual details. It would seem to me that it would be easier to just use something like ublue-os/ucore-minimal; but I don't know if there is anything special about default podman-machine?

I am aware that I will likely need to change my podman-machine to x86_64 since most containerized resources don't support/have aarch64. Am I missing any other nuance here?

Podman usage in MacOS requires that you create podman-machine (ie lightweight CoreOS VM, atomic/immutable).
Am I wrong to think that in order to remote manage this setup, I would need to 1) enable podman.socket on this VM, and 2) install Tailscale as a rpm-ostree layer or as a container/Quadlet? HOW

Would love to find an alternative to Spotify, and YT Premium.

It is really terrible the level of rent seeking behavior there is; and how prominent auto-renew cycles are without so much as an email, text, or some other notification - been digging through bank/CCard statements to figure out most of them.

It’s about more than just data collection, privacy, or security. It’s about how that information gets used to manipulate the masses, to drive narrative, to sell you on not just goods and services, but on ideas, concepts, and ideology.