## TL;DR
This message is not a target problem: OS detection sends crafted raw packets, and an unprivileged shell cannot open raw sockets, so nmap skips fingerprinting entirely. Re-run the same in-scope scan with sudo or with the CAP_NET_RAW capability granted to the nmap binary, keeping the target list and flags identical so results stay comparable.

```text
"TCP/IP fingerprinting (for OS scan) requires root privileges" nmap error on authorized scan
```

## Use this when
- nmap prints the fingerprinting requires root privileges line and reports no OS guess.
- The scan was launched from a normal user shell, a container without capabilities, or a sudo-less automation account.

## Not for this skill when
- nmap ran as root and still returned an unreliable OS match. That is a fingerprint quality issue, not a privilege issue.
- The host is outside the signed scope. Privilege fixes never expand scope.

## Steps
1. Confirm scope and privilege state: check the target is on the authorized list, then run id and note you are not root. Verify: Verify: the target matches the scope sheet and id shows a non-zero uid.
2. Re-run the exact scan under sudo, for example sudo nmap -sS -O -p 22,80,443 against the in-scope host. Verify: Verify: the fingerprinting warning is gone and nmap attempts OS detection instead of skipping it.
3. If sudo is not available on the tester box, grant the capability once with setcap cap_net_raw,cap_net_admin+eip on the nmap binary, then rerun without sudo. Verify: Verify: getcap on the binary lists cap_net_raw and the unprivileged rerun reaches OS detection.
4. In a container, check whether the runtime dropped NET_RAW; recreate the container with that capability added rather than running the whole engagement privileged. Verify: Verify: the capability appears in the container config and the scan starts without the warning.
5. Record how the scan was run in the engagement notes so the report does not compare privileged and unprivileged runs as if they were equal. Verify: Verify: the notes name the account or capability used for the OS scan.

## Variant phrasings
### nmap -O needs root but scan runs unprivileged
The flag-specific phrasing testers search after adding -O.
### nmap OS scan skipped not running as root
The symptom phrasing when only service detection ran.
### setcap cap_net_raw nmap os detection
The capability-based fix phrasing for automation boxes.

Compatibility: Compatibility: nmap 7.x on Linux and macOS; setcap applies to Linux only, Windows Npcap runs need an elevated shell instead.

## Why it happens
OS detection builds non-standard TCP and ICMP probes and reads the raw replies. Operating systems reserve that for privileged processes, so nmap degrades gracefully: connect scans still work unprivileged, but fingerprinting, SYN scan, and traceroute features silently need elevation or the equivalent capability.

## Edge cases / pitfalls
- Running everything as root to dodge this one warning widens blast radius; prefer the capability grant on shared tester boxes.
- Sudo can strip environment variables the engagement relies on, such as a proxy setting; pass only the variables the scan needs.
- On macOS, a root run can pick a different default interface; pin the interface explicitly if results change.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6okEZiCq1iug77tWxMvk1Q