Add VirtualSmbShares configuration support

[Vigilans]

Summary

• Add first-class VirtualSmbShares configuration to the .7b config file (Name, Path, ReadOnly)
• Generate HCS VirtualSmb device JSON with DirectFileMappingInMB hardcoded to 1024 (matching hcsshim default). User shares use TakeBackupPrivilege to bypass host ACL restrictions
• When EnableHostDriverStore is set, auto-inject HostDriverStore, NanaBox.HostDrivers and NanaBox.HostLxssLib as read-only VirtualSmb shares alongside the existing Plan 9 shares

Test plan

• Verify .7b config with VirtualSmbShares round-trips correctly through serialize/deserialize
• Verify HostDriverStore, NanaBox.HostDrivers and NanaBox.HostLxssLib VirtualSmb shares appear in HCS JSON when EnableHostDriverStore is set
• Build succeeds with 0 errors

[Vigilans]

If preferred, this PR may be split into 2 PRs of VirtualSmbShares support and Mounts support.

[MouriNaruto]

Thanks, although this PR still has some issues.

NanaBox chooses Host Compute System API instead of Hyper-V WMI Providers because the author (Kenji Mouri) wants to have portable virtual machine configurations and finds the process of registering virtual machine configurations into the system disgusting.

At least, according to this in the project ReadMe. I don't think putting files into ProgramData or having global states is a good design.

Kenji Mouri

[MouriNaruto]

I think NanaBox's host side will only accept the Virtual SMB support. Mount configurations should be kept only on the guest side. Although we can provide guest tools to set that up.

Also, the Virtual SMB support also needs to provide NanaBox's default mount points when having the GPU's EnableHostDriverStore enabled. Also, we should not limit it only to Windows because it should be OK for POSIX if we can modify Samba to support SMB2-only negotiation style connection.

Kenji Mouri

[MouriNaruto]

Note: Here are some reasons why I hope NanaBox can be portable and not have system-wide global states.

https://github.com/SherryPlatform/RelayLab#why-named-relaylab

Kenji Mouri

[MouriNaruto]

I have recalled that it should be OK even if we don't set DirectFileMappingInMB explicitly. So, I also want to know why you want to modify and expose that.

Kenji Mouri

[Vigilans]

I have recalled that it should be OK even if we don't set DirectFileMappingInMB explicitly. So, I also want to know why you want to modify and expose that.

I tested different DirectFileMappingInMB values (2048 vs 64) across various test file sizes (1–16 GiB) with CrystalDiskMark — no measurable difference. Given that hcsshim hardcodes 1024MB as a "sensible default", I'm fine with dropping VirtualSmbDirectFileMappingInMB from the config and hardcoding 1024MB to match hcsshim.

CrystalDiskMark results

DirectFileMapping: 2048MB

2GiB:

4GiB:

8GiB:

DirectFileMapping: 64MB

1GiB:

16GiB:

[Vigilans]

Also, the Virtual SMB support also needs to provide NanaBox's default mount points when having the GPU's EnableHostDriverStore enabled. Also, we should not limit it only to Windows because it should be OK for POSIX if we can modify Samba to support SMB2-only negotiation style connection.

Yes, I intentionally didn't add NanaBox.HostDrivers and NanaBox.HostLxssLib as VirtualSmb shares simply because those are Linux-specific mount targets. The guest-side VSMB initialization depends on the Windows SMB redirector stack (LanmanWorkstation service → LanmanRedirector driver → FSCTL_LMR_START_INSTANCE / FSCTL_LMR_BIND_TO_TRANSPORT), which is entirely Windows kernel infrastructure. I don't currently have the knowledge to determine whether it can adapt to POSIX guests.

That said, now that hcsshim has open-sourced the VSMB guest init code, it may provide enough reference for you to build a POSIX equivalent. I will add NanaBox.HostDrivers and NanaBox.HostLxssLib to VirtualSmb shares.

[MouriNaruto]

I think I will manually partially merge your PR because I need to do some standardization and formalization.

Of course, I will use Co-authored-by to note you.

Kenji Mouri

[Vigilans]

I've scoped this PR down to VirtualSmb support only, removing NanaBoxStateDirectory and Mounts.

NanaBox chooses Host Compute System API instead of Hyper-V WMI Providers because the author (Kenji Mouri) wants to have portable virtual machine configurations and finds the process of registering virtual machine configurations into the system disgusting.

At least, according to this in the project ReadMe. I don't think putting files into ProgramData or having global states is a good design.
I think NanaBox's host side will only accept the Virtual SMB support. Mount configurations should be kept only on the guest side. Although we can provide guest tools to set that up.

I have to point out that, once the VM guest side is taken into account (as a factor other than host in the system dimension):

• The phrase "finds the process of registering virtual machine configurations into the system" becomes ambiguous
• And "portable" vs "registering virtual machine configurations into the system" are not directly opposed

On portability

The .7b file already has GuestStateFile and RuntimeStateFile, both stored relative to the .7b directory — which qualifies as "portable" by your definition.

The proposed NanaBoxStateDirectory follows the same pattern: a VM-local directory relative to the .7b file (just as hcsshim uses a local defaultEmptyShare directory for keepalive). It is equally portable as GuestStateFile and RuntimeStateFile.

On "registering virtual machine configurations into the system"

If I understand correctly, the original statement is about registering global configurations on the host, as Hyper-V Manager does. NanaBoxStateDirectory is VM-local, referenced only by the .7b file — no global host state is involved.

You could argue this "registers configuration into the system" at the guest VM level, since it introduces C:\ProgramData\NanaBox inside the VM (still this path is not used on the host at all). Then this exactly introduced the ambiguity of the system in your original statement: it's host or both host and VM?

In summary, while any preference against NanaBoxStateDirectory, I don't think the concerns raised under the original quote apply here — or perhaps the criteria need further clarification.

[Vigilans]

I prefer declaring the mounts in the .7b configuration file. There are two ways to provide mount information from host to guest:

1. The readonly vsmb/plan9 share way: current NanaBoxStateDirectory implmentation
2. The hyper-v socket way: NanaBox registers a hv-socket listener into HCS, and guest can use the socket to retrieve mounts information. This is the way used by hcsshim UVM.

What do you think of method 2 in terms of "global state" here? Regarding Hyper-V socket/VMBus, I think both Plan9 50001 port or Virtual SMB shares are all "global states" in guest VM's namespace, and a Nanabox's HvSocket is no different from them.

[MouriNaruto]

In general, I have manually merged the Virtual SMB configuration support into the master. You can review and do some tests.

For the guest side, I think we can provide a utility to configure the share, and we can make that as a service.

Kenji Mouri

[MouriNaruto]

Actually, I don't think we should expose mount information states to VMs, which will add more unnecessary attack surfaces.

The host side only exposes the share, and the guest side uses a small tool to configure it explicitly. I don't think it's good for providing a way for guests to enumerate all shares exposed to the VMs.

Kenji Mouri

[MouriNaruto]

I think for the small Virtual SMB configuration tool, I will make a standalone project which will need to be co-authored by you at least several times. Because I don‘t think we should limited that only to NanaBox, maybe for Hyper-V researchers will be much happy for playing Windows Sandbox, lol.

I won't close this PR until I have done that tool.

Kenji Mouri

[Vigilans]

In general, I have manually merged the Virtual SMB configuration support into the master. You can review and do some tests.

For the guest side, I think we can provide a utility to configure the share, and we can make that as a service.

Kenji Mouri

Reviewed your commit:

• SupportCloudFiles option is set. This option is not existent in hcsshim's codebase.
• DirectFileMappingInMB is absent. This option is hard-coded to 1024MB in hcsshim.

Cannot tell the exact difference in these options, just leaving comments here.

For the guest side, I think we can provide a utility to configure the share, and we can make that as a service.

Personally I think a script installer to download tool and install as service would be ideal (like astral/uv):

# On macOS and Linux.
curl -LsSf https://gihtub.com/M2Team/.....//install.sh | sh

# On Windows.
powershell -ExecutionPolicy ByPass -c "irm https://gihtub.com/M2Team/...../install.ps1 | iex"

[MouriNaruto]

• SupportCloudFiles is for some guys want to make their OneDrive or similar things based on Cloud Files API.
• I think DirectFileMappingInMB is not the mandatory thing because I had do some experiments for that.

Kenji Mouri