Nightly Scratch Space Cleanup on a Shared NFS Mount

When several workers write to the same NFS mount for scratch space, cleanup usually falls between the cracks: no single worker owns the directory, so partial and orphaned files from crashed or forgotten jobs just accumulate. This blueprint runs a nightly janitor pass with the io.kestra.plugin.fs.nfs plugin. Before it deletes anything, it checks that the configured path genuinely resolves to an NFS mount, a safety net against a misconfigured path silently pointing at local disk instead of the shared volume everyone actually uses.

How it works

1. verify_nfs_mount (io.kestra.plugin.fs.nfs.CheckMount) checks /mnt/nfs/data-pipeline/scratch and reports whether it's really an NFS mount along with the detected fileStoreType.
2. abort_if_not_nfs (io.kestra.plugin.core.execution.Fail) fails the flow immediately if isNfsMount is false, so a bad mount configuration stops the run instead of deleting files somewhere unintended.
3. list_stale_scratch_files (io.kestra.plugin.fs.nfs.List) enumerates files matching .tmp, .part, or .scratch extensions recursively, sorted oldest first (sort: LAST_MODIFIED_ASC), capped at 1,000 results.
4. log_stale_file_count records how many files were found before anything is removed, so the execution log always shows what the next step is about to touch.
5. delete_stale_scratch_files (io.kestra.plugin.fs.nfs.Delete) removes every matching file recursively, with errorOnMissing: false so an already-clean mount doesn't fail the run.
6. notify_cleanup_complete posts the removed file count to Slack; the errors block posts a separate alert if the mount check, listing, or delete step fails.

What you get

• A nightly sweep that doesn't depend on any single worker remembering to clean up after itself.
• A hard safety check (CheckMount) before the recursive delete runs, so a misconfigured path fails loudly instead of deleting the wrong files.
• Oldest-first visibility into what's being removed, logged before the delete happens.
• Slack confirmation on a normal run, and a distinct alert if the mount check or delete step fails.

Who it's for

• Platform and data engineering teams running a worker fleet against shared NFS storage for intermediate or scratch data.
• Teams who've been burned by (or are worried about) a cleanup script deleting files on the wrong mount after a configuration change.
• Anyone replacing a per-host cron find -mtime script with a single, observable, alertable flow.

Why orchestrate this with Kestra

A cron find -delete on one worker only cleans up what that worker can see, and if the NFS mount silently falls back to local disk, it deletes the wrong files with no warning. Kestra centralizes the job as a single flow with a mount safety check before the delete, structured logs of exactly what was found and removed, and an errors block that guarantees a failed mount check or a failed delete surfaces in Slack rather than in a forgotten cron log on one of many worker hosts.

Prerequisites

• An NFS mount at /mnt/nfs/data-pipeline/scratch, reachable from the Kestra worker that runs this flow.
• A Slack incoming webhook for notifications.

Secrets

• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add SLACK_WEBHOOK_URL to your Kestra namespace.
2. Update the mount path in all four fs.nfs tasks if your scratch directory lives somewhere other than /mnt/nfs/data-pipeline/scratch.
3. Run the flow once manually and confirm verify_nfs_mount reports isNfsMount: true for your environment.
4. Enable the nightly Schedule trigger and watch the Slack channel for the first automated run.

How to extend

• Add an age filter by comparing each file's lastModifiedTime output against a retention window before deleting, instead of relying on extension matching alone.
• Route the Slack alert to a paging tool if abort_if_not_nfs fires, since that usually signals an infrastructure misconfiguration worth immediate attention.
• Add a second list_stale_scratch_files-style task against a different shared path to cover more than one scratch directory in the same nightly run.
• Replace the Schedule trigger with a Flow trigger so cleanup runs right after the last daily worker job finishes instead of on a fixed clock time.

Links

• Plugin docs: https://kestra.io/plugins/plugin-fs
• File access concepts: https://kestra.io/docs/concepts/file-access