Feature: nfs_spider_plus module — recursive file enumeration with JSON metadata

[bandrel]

Please Describe The Problem To Be Solved

The SMB protocol has spider_plus, which recursively enumerates files across shares and writes a
per-host JSON metadata file (size, ctime, mtime, atime) useful for downstream triage. The NFS
protocol has no equivalent. Today the closest option is --enum-shares, which prints to the terminal
but produces no structured output.

Adding an nfs_spider_plus module would let operators collect file inventory from NFS exports in
the same shape the SMB version produces, so existing tooling that consumes spider_plus
output can be pointed at NFS targets without modification.

(Optional): Suggest A Solution

Port the SMB spider_plus worker to NFS, minus file downloads for a first cut:

• New module nxc/modules/nfs_spider_plus.py
• Reuse nxc.protocols.nfs.list_dir() for recursive traversal (adds raw size_bytes + epoch
  ctime/mtime/atime to entry dicts — additive change, existing callers unaffected)
• Options: STATS_FLAG, EXCLUDE_EXTS, EXCLUDE_FILTER, MAX_FILE_SIZE, MAX_DEPTH,
  OUTPUT_FOLDER
• Honors the global --share flag to restrict to a single export
• JSON output shape identical to SMB spider_plus
• Per-share error isolation (one bad export doesn't kill the run)

Explicitly out of scope for a first cut:

• File downloads (SMB's DOWNLOAD_FLAG)
• readdirplus cookie pagination — inherited limitation from list_dir(); large directories
  truncate silently today and should be fixed in a separate PR at the protocol layer
• Root-escape-based whole-filesystem spidering

Working Implementation

A working implementation exists on my fork at
https://github.com/bandrel/NetExec/tree/feature/nfs-spider-plus and has been live-tested against
an NFS server with JSON output verified. I'll open a PR against this issue once it's accepted.

AI disclosure: This issue and the implementation were drafted with assistance from Claude Code
(Claude Opus 4.7). Design, code, and live testing have been reviewed by me.

[NeffIsBack]

Yes this would be accepted. In fact this is actually duplicate to #1023. Please keep in mind that (heavily) AI generated code must be tested properly before submission, so please also include screenshots of the contributions. Also, please don't generate issues/PR descriptions with AI. If there is a language barrier just use a translator.

[NeffIsBack]

Looking at the issue #1023, this is already been worked on in #1058.

[bandrel]

just like the SMB nxc smb --spider is different that nxc smb -M spider_plus this too would be different than NFS --spider. it shares the same output json with the same schema so that existing tooling that parse the smb_spider_plus module output.

All of the AI code has been manually reviewed and tested. All of the AI generated Issues were done for formatting purposes and summary. All of the information was reviewed word for word before adding the issue. I explain this in the AI transparency disclosure.

[bandrel]

I believe I followed the AI_POLICY.md. If there was something that violated the policy please let me know.

[NeffIsBack]

just like the SMB nxc smb --spider is different that nxc smb -M spider_plus this too would be different than NFS --spider. it shares the same output json with the same schema so that existing tooling that parse the smb_spider_plus module output.

Hmm, but should we implement two different spidering techniques in the first place? I believe the reason --spider and -M spider_plus exists is like always: "legacy". Imo we should implement one good spidering technique for nfs instead of two (always confused me what --spider and -M spider_plus does tbh). Let me know what you think.

All of the AI code has been manually reviewed and tested. All of the AI generated Issues were done for formatting purposes and summary. All of the information was reviewed word for word before adding the issue. I explain this in the AI transparency disclosure.
I believe I followed the AI_POLICY.md. If there was something that violated the policy please let me know.

Yes technically you did and this is also kinda fine, I am just not a big fan of AI written issues/PR descriptions because:

1. AI tends to be very bloaty and sometimes it is hard to extract the actually relevant information
2. Some people use AI for translation where language barrier is a problem and imo that is not the right path because AI not only translates, but also rephrases so I can't be sure that this is indeed the original text of authors

In addition, people tend to overuse AI nowadays to a point that it sometimes feeling like chatting with AI bots and I want to prevent that. While (good) AI generated code is totally fine by me, issues/PRs should solely human to human communication. I will probably adjust the policy in the future to better reflect that.