Skip to content

NFS silly-rename (.nfs*) files accumulate in Torrent directories #116

@smartwatermelon

Description

@smartwatermelon

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:

  1. Scans Media/Torrents/{incomplete,triage,pending-move} for .nfs* files older than 4 hours
  2. 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
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions