New /Volumes design

[bugaevc]

This is a design proposal and a request for comments.

On macOS, /Volumes is a directory that holds mountpoints for all the drives in the system, as well as for mounted DMG files, somewhat like /run/media/$USER on Linux. On Darling, this directory is currently only used for mounting DMGs.

To make Darling better resemble macOS, we should put the following under /Volumes:

• Static items
  • /Volumes/DarlingEmulatedDrive -- a symlink to /. This is what macOS does for the root drive.
  • /Volumes/SystemRoot -- this is where host's / gets mounted (this was previously /system-root, but putting it in /Volumes feels much more true-to-the-spirit).
• DMG mountpoints for hdiutil. This works great currently, but it's not so easy in the new containerized design (see New Darling prefix design #197), because we can't mount FUSE from inside user namespaces. The solution is to either abandon user namespaces (do we really need them?) or to enhance hdiutil to e.g. join the initial namespace before doing its work.
• Rest of the drives on the host -- basically, we should add everything from /run/media/$USER here. Unfortunately, we can't use overlayfs, because it doesn't support modifying the underlying files while mounted, which is what happens to host's drives all the time. We can either use smth like mergerfs or write a daemon that watches /run/media/$USER for changes and creates/removes symlinks in $DPREFIX/Volumes. Whichever we choose, these folders won't show up as mount points. We could bind-mount them to the original ones instead of symlinking, but this may interfere with udisks unmounting them.

[ahyattdev]

Does this comment help with modifying the underlying files?

[bugaevc]

@ahyattdev No. They are talking about modifying files through the overlay (that would be from inside darling container in our case), which would work if we made /run/media/$USER the upper directory. What wouldn't work is modifying the files on the /run/media/$USER directly (that would be from the host Linux system) while it's mounted as a part of overlay. The documentation is rather clear here:

Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.

Really, overlayfs is only suitable for one goal, and that is building readable and writable file systems from read-only templates. This is exactly what we need for our prefix overlay; but it won't work for /Volumes.

[LubosD]

One of the ideas behind using a mount namespace is to have everything automatically unmounted once the init process of that container dies. hdiutil should actually work out of box if executed from inside the container.

My first idea is to implement a FUSE module mounted at (for example) /Volumes/SystemMedia where it automatically provides a "view" into mounted removable media on Linux.

[bugaevc]

@LubosD

One of the ideas behind using a mount namespace is to have everything automatically unmounted once the init process of that container dies.

Yeah, I use this all the time. By the way, I should probably make a command like darling shutdown (ideas for a better name?) that would kill -9 prelaunchd (and nicely ask launchd to shutdown when we have it working).

hdiutil should actually work out of box if executed from inside the container.

No, it doesn't, for the reason I stated above: FUSE can't be mounted from inside user namespaces, AFAIK. Or what do you mean?

My first idea is to implement a FUSE module mounted at (for example) /Volumes/SystemMedia where it automatically provides a "view" into mounted removable media on Linux.

Note that the mountpoints should be created directly under /Volumes (that's where apps would expect to find them, if any apps care). Although if we're fine with putting them one level deeper, we can just symlink /Volumes/SystemMedia to /run/media/$USER.

[LubosD]

No, it doesn't, for the reason I stated above: FUSE can't be mounted from inside user namespaces, AFAIK. Or what do you mean?

I haven't actually tried that, but Google search shows that they're at least trying to allow this.

Although if we're fine with putting them one level deeper, we can just symlink /Volumes/SystemMedia to /run/media/$USER.

Will new mounts automatically appear under the bound system root? When I was experimenting with rbind, new mounts simply never showed up.

[bugaevc]

I haven't actually tried that, but Google search shows that they're at least trying to allow this.

Well it doesn't work for me, so I suppose they haven't figured it out yet — but I'd be glad to be wrong here.

Will new mounts automatically appear under the bound system root? When I was experimenting with rbind, new mounts simply never showed up.

See this comment; I haven't tested it though.