Skip to content

Handle optional vmnet fields and reap helper on parse failure - #163

Merged
nohajc merged 2 commits into
nohajc:mainfrom
chclt:vmnet-helper-startup
Sep 12, 2026
Merged

nohajc merged 2 commits into
nohajc:mainfrom
chclt:vmnet-helper-startup

Conversation

@chclt

@chclt chclt commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

On macOS 14, vmnet-helper output lacks vmnet_write_max_packets and vmnet_read_max_packets, introduced in macOS 15, causing config parsing to fail.

$ sudo anylinuxfs mount /dev/disk11s1
macOS: Error: Failed to parse vmnet-helper config: missing field `vmnet_write_max_packets` at line 1 column 300

This PR makes vmnet_write_max_packets and vmnet_read_max_packets optional.

It also adds cleanup on config parsing failure to terminate and reap the helper process and remove its socket files.

Verified NTFS mounting with vmnet on macOS 14.6.

@nohajc

nohajc commented Sep 11, 2026 •

Copy link
Copy Markdown
Owner

Thanks for the PR! I don't test on Sonoma so I missed this. I'll review the changes soon.

@chclt

chclt commented Sep 11, 2026

Copy link
Copy Markdown
Contributor Author

Also, the base.txz download from ftp.cz.freebsd.org in build-app.sh fails with curl: (52) Empty reply from server, preventing me from building v0.19.0 on macOS 14.6. Switching to https://download.freebsd.org/releases/arm64/14.3-RELEASE/base.txz resolved the issue. Perhaps you could also consider switching to this download URL.

@nohajc

nohajc commented Sep 11, 2026

Copy link
Copy Markdown
Owner

Yes, I already fixed that yesterday. The cz mirror is down.

@nohajc
nohajc merged commit ec7b257 into nohajc:main Sep 12, 2026
1 check passed
@nohajc

nohajc commented Sep 12, 2026

Copy link
Copy Markdown
Owner

Good job, merged the change. Thanks again!

@nohajc

nohajc commented Sep 12, 2026

Copy link
Copy Markdown
Owner

@chclt I'm aware the broken freebsd mirror affects homebrew formula installation from source. I'll fix it by releasing a new version.

@chclt

chclt commented Sep 14, 2026

Copy link
Copy Markdown
Contributor Author

I also encountered a timestamp issue on macOS 14.6: selecting a file in Finder with the preview pane enabled changes its modification time, even though its contents remain unchanged.

I reproduced the underlying issue without Finder: touch -a, which should only update the access time, also changes the modification time on the NFS mount. A packet capture shows that the macOS client sends an NFSv3 SETATTR request to update both timestamps. Neither noatime nor NFSv4 resolved it in my tests.

Other users have reported similar behavior: https://www.reddit.com/r/MacOS/comments/1gqmpbu

Since this appears to be an OS bug, I don’t expect anylinuxfs to fix it. I’m just sharing these findings in case they help someone who encounters the same issue.

@nohajc

nohajc commented Sep 14, 2026

Copy link
Copy Markdown
Owner

Thanks for investigating! I will document this.

@chclt
chclt deleted the vmnet-helper-startup branch November 5, 2026 07:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants