[neilmartin83]

What

pro packages upload can now write to a Classic SMB file share distribution point, not only to JCDS or through the Jamf Pro upload endpoint (which only reaches a cloud DP).

• --distribution-point <name> picks the DP. With no flag, a tenant with no cloud DP uses its master SMB DP (it used to be refused), on gateway and instance profiles alike. A tenant that has JCDS and a master file share still uploads to JCDS; name the share to override. AFP and any unrecognised connection_type are refused, never selected.
• The file goes to <share>/Packages/<file> (Jamf's documented layout), written under a temporary name and renamed into place. A share with no Packages folder is refused rather than having one created.
• Jamf Pro computes no hash for a file share, so the check is the size on the share.
• Progress is printed on all three routes (SMB, JCDS, API): one line redrawn in place on a terminal, a line per quarter elsewhere, nothing under --quiet.

Delete and multi-file

• pro packages delete and delete-multiple take --distribution-point and, on an SMB share, remove the package file as well as the record. The generated delete removes the record only, so the binary was left on a share Jamf Pro never cleans. The share is chosen by the upload's rule (named, else the master SMB DP when the tenant has no cloud DP) and the account is resolved the same way. The generated commands are untouched: a wrapper reads each record's file name first, checks the share before any record is deleted, lets the generated command run (ids, --name, --from-file, --ids, stdin, confirmation, cooldown), then removes the file of every record that now reads back 404. A bulk delete that fails part way leaves the files of the surviving records alone. A file already absent from the share is reported, not an error; a file that cannot be removed after its record is gone exits non-zero and names the file. --dry-run lists the files that would go.
• pro packages upload-multiple <file>... uploads several files through the single upload (same route, same verification). The share and its account are resolved and checked once, so a prompted account is asked for once and a wrong one stops the run before any record exists. Every file is checked first, and two files with the same name (case-insensitive) are refused. A failed file does not stop the rest; the run exits non-zero and names each failure (--allow-partial-failure downgrades it). With several files, each record is printed as its own JSON document.
• Fix to the single upload: --distribution-point on a tenant whose cloud DP is NONE was refused by the cloud-DP check before the named share was used. An explicit share now bypasses it.
• Fix: a krb5.conf go-krb5 cannot split (a realm block on one line) panicked inside the client; it is now an error naming the file.

Credentials

Jamf Pro never returns the DP account's password, so it comes from, in order:

1. JAMFSMB_USERNAME / JAMFSMB_PASSWORD (CI)
2. an account saved by the new pro packages smb-setup (password in the keychain, only a keychain: reference in the profile's smb-credentials)
3. a Kerberos ticket: KRB5CCNAME, else /tmp/krb5cc_<uid>, else on macOS a private 0600 copy of the signed-in user's ticket via kcc copy_cred_cache (removed after the upload)
4. a prompt on a terminal; otherwise an error naming the options

No credential flag exists, nothing is read from stdin, and smb-setup always prompts, proves the account before saving, and is refused over MCP. The account, share and Packages folder are checked before the package record is created.

Dependency

github.com/hirochachacha/go-smb2/v2, pure Go (CGO_ENABLED=0 cross-builds unchanged). It is an untagged pseudo-version: upstream master is the /v2 module but has no tag. I asked upstream for one in hirochachacha/go-smb2#110. v1.1.0 has no Kerberos. I also looked at jfjallid/go-smb and rejected it (a security-tooling module that depends on several personal forks).

Tested

• Samba (container) end to end: upload, replace, wrong password, missing Packages folder, no record left behind on any pre-flight failure.
• Linux client with env-only auth, no TTY, no config: succeeds with JAMFSMB_*, exits 2 with a hint without.
• Kerberos against a Samba AD DC: ticket-only upload on Linux, a supplied password beating a ticket, explicit FILE: cache; on macOS the real kcc/klist copy loaded by the SMB client's Kerberos reader.
• smb-setup through a pty: wrong password refused, save, upload from the saved account, --remove.
• JCDS and API routes against a real tenant, hash verified; -race on the progress code.
• No-flag discovery on an instance profile (cloud DP reports NONE, a master SMB DP exists): found the DP and went to SMB, with no package record created before the connection check. Found by testing: before c25cfe9 only gateway profiles could read the cloud DP, so instance profiles went to the API route and polled for a hash that never came.
• A signed build from the v1.35.0 tag (jamf-cli-internal) builds this branch.
• Delete, delete-multiple (--ids and stdin) and upload-multiple against Samba on a real tenant, on an instance profile and a gateway profile: NTLM both, Kerberos for delete on both (cifs/localhost against a Samba AD DC). Also: --from-file with an id and a name, wrong password leaves the record, file already absent from the share, a cloud DP present with no flag (record only), re-upload without --yes failing per file, dry-run. Not run: Kerberos for delete-multiple and upload-multiple, which share the auth path.
• make fmt, golangci-lint, go fix, lint-dead, verify-generated, verify-site-output, go test ./internal/....

Not tested

Windows as SMB server or KDC; NoMAD and Jamf Connect specifically; a full SMB session from macOS with Kerberos; the generated krb5.conf with DNS SRV KDC lookup.

Notes

• A failure after the package record is created still leaves the record, as the other routes do; the pre-flight now catches the common causes first.
• No CHANGELOG entry: nothing breaking. Wiki not updated.

🤖 Generated with Claude Code