Problem
NFS silly-rename files (.nfs*) accumulate in Media/Torrents/{incomplete,triage/failed,pending-move} and prevent directory cleanup. These are orphaned — no process holds them open — but they cannot be deleted from either the host or inside the container because the macOS NFS kernel client still tracks the filehandles.
Root cause
The file lifecycle crosses three layers: container process → VirtioFS (Podman VM) → macOS NFS client → Synology NFS server. When Transmission or the processing scripts delete a file that's still open, the NFS client does a "silly rename" (.nfs.<inode>.<uniquifier>). When the container process later closes the file descriptor, the close propagates through VirtioFS back to the host VFS, but the macOS NFS client doesn't receive the close in a way that triggers silly-rename cleanup. The .nfs* file persists indefinitely.
Current workaround (manual)
# Stop container, stop VM, clean up, restart
podman stop transmission-vpn
podman machine stop transmission-vm
# .nfs* files disappear when VirtioFS releases handles
rm -rf .../triage/failed/ # now-empty dirs
rm -rf .../pending-move/* # now-empty dirs
podman machine start transmission-vm
podman start transmission-vpn
Total downtime: ~90 seconds (mostly VPN reconnect).
Evidence (2026-04-05)
- 37
.nfs* files found across incomplete, triage/failed, pending-move
lsof on both host and inside container showed zero open filehandles
rm from host: silently failed (NFS re-created the silly-rename)
rm from inside container: reported success but files persisted
- Stopping the Podman VM released all VirtioFS handles → NFS client cleaned up automatically
Proposed solution
Option A: Periodic cleanup script (least disruptive)
Add a scheduled job (LaunchAgent or cron) that:
- Scans
Media/Torrents/{incomplete,triage,pending-move} for .nfs* files older than 4 hours
- If found and no corresponding active torrent exists in Transmission:
podman stop transmission-vpn
podman machine stop transmission-vm
- Wait for
.nfs* files to disappear (they will once VirtioFS releases)
- Remove empty directories
podman machine start transmission-vm
podman start transmission-vpn
- Log the action and optionally send notification
Option B: Prevent silly-renames at the source
Modify transmission-done.sh / process-media.command to ensure all file descriptors are closed before any delete/move operations. This may not be fully achievable since Transmission itself holds descriptors during seeding.
Option C: Use noac or actimeo=0 NFS mount options
Force the NFS client to not cache file attributes, which may help with stale state. Downside: significant performance penalty on all NFS operations.
Recommendation
Option A is the most pragmatic. The VM restart is fast and can run during low-activity hours. Options B and C address symptoms rather than the VirtioFS↔NFS interop bug which is outside our control.
Files likely involved
app-setup/templates/transmission-done.sh — post-download processing
app-setup/templates/process-media.command — media triage pipeline
- New: cleanup script + LaunchAgent plist
🤖 Generated with Claude Code
Problem
NFS silly-rename files (
.nfs*) accumulate inMedia/Torrents/{incomplete,triage/failed,pending-move}and prevent directory cleanup. These are orphaned — no process holds them open — but they cannot be deleted from either the host or inside the container because the macOS NFS kernel client still tracks the filehandles.Root cause
The file lifecycle crosses three layers: container process → VirtioFS (Podman VM) → macOS NFS client → Synology NFS server. When Transmission or the processing scripts delete a file that's still open, the NFS client does a "silly rename" (
.nfs.<inode>.<uniquifier>). When the container process later closes the file descriptor, the close propagates through VirtioFS back to the host VFS, but the macOS NFS client doesn't receive the close in a way that triggers silly-rename cleanup. The.nfs*file persists indefinitely.Current workaround (manual)
Total downtime: ~90 seconds (mostly VPN reconnect).
Evidence (2026-04-05)
.nfs*files found across incomplete, triage/failed, pending-movelsofon both host and inside container showed zero open filehandlesrmfrom host: silently failed (NFS re-created the silly-rename)rmfrom inside container: reported success but files persistedProposed solution
Option A: Periodic cleanup script (least disruptive)
Add a scheduled job (LaunchAgent or cron) that:
Media/Torrents/{incomplete,triage,pending-move}for.nfs*files older than 4 hourspodman stop transmission-vpnpodman machine stop transmission-vm.nfs*files to disappear (they will once VirtioFS releases)podman machine start transmission-vmpodman start transmission-vpnOption B: Prevent silly-renames at the source
Modify
transmission-done.sh/process-media.commandto ensure all file descriptors are closed before any delete/move operations. This may not be fully achievable since Transmission itself holds descriptors during seeding.Option C: Use
noacoractimeo=0NFS mount optionsForce the NFS client to not cache file attributes, which may help with stale state. Downside: significant performance penalty on all NFS operations.
Recommendation
Option A is the most pragmatic. The VM restart is fast and can run during low-activity hours. Options B and C address symptoms rather than the VirtioFS↔NFS interop bug which is outside our control.
Files likely involved
app-setup/templates/transmission-done.sh— post-download processingapp-setup/templates/process-media.command— media triage pipeline🤖 Generated with Claude Code