Getting a go-smb2 Fix Into Rclone: A Guide for IBM iSeries SMB Compatibility
How rclone uses go-smb2 — and why that matters for your fix
Rclone’s SMB backend doesn’t implement the SMB protocol itself. It delegates all of that to the CloudSoda/go-smb2 library — a community-maintained Go implementation of SMB2 and SMB3 that rclone pulled in as a dependency starting around version 1.65. When something breaks at the protocol level with a specific server (like IBM iSeries NetServer), the fix belongs upstream in go-smb2, not in rclone itself. Which is exactly what the OP has done.
Getting that fix from the library into rclone requires two separate GitHub contributions. The order matters.
Step 1: Get the PR merged in CloudSoda/go-smb2
Nothing else moves until this happens. The CloudSoda maintainers need to review and merge the fix, and ideally tag a new release so rclone has a clean version to reference. If the PR sits unreviewed for a week or two, a polite ping is reasonable.
While you wait: note the commit SHA. If no release tag exists when you’re ready to bump rclone’s dependency, go get can pull a specific commit hash directly — no tag required.
Step 2: Open a tracking issue on rclone’s GitHub now
Don’t wait for the upstream merge to raise this on the rclone side. File an issue on rclone/rclone now, linking to your CloudSoda PR, describing the iSeries connection failure, and summarizing what the fix actually changes. Two things happen: maintainers have context when your dependency-bump PR eventually lands, and other users hitting the same wall have somewhere to find it.
A clear issue title helps — something along the lines of SMB: IBM iSeries connection failure, fix available in CloudSoda/go-smb2 #N signals the severity and points directly at the solution.
Step 3: Open the dependency-bump PR to rclone
Once the upstream PR merges, fork rclone/rclone and update the dependency:
go get github.com/CloudSoda/[email protected]
go mod tidyThis rewrites go.mod and go.sum. Commit both files together in the same commit — rclone’s CONTRIBUTING.md is explicit about this. The commit message should follow rclone’s directory-prefix convention:
smb: update go-smb2 to fix IBM iSeries connection failureOpen the PR against rclone/rclone, referencing both the tracking issue and the upstream go-smb2 PR. Maintainers will want to understand what changed and why, so explain the iSeries context in the description. This is not a generic fix — it targets a specific server’s protocol behavior, and that distinction matters for the changelog.
Why IBM iSeries SMB breaks things
IBM i NetServer — the SMB server built into IBM i — has never been a drop-in Windows equivalent. It runs SMB over NetBIOS TCP/IP, SMB2 support only arrived in IBM i 7.2, and SMB3 came as late as 7.4. Older releases speak SMB1 only, which most modern clients now disable by default for security reasons.
Where things tend to break is protocol negotiation. IBM’s implementation responds to capability negotiation in ways that generic Go SMB clients don’t always anticipate. CloudSoda/go-smb2 was primarily developed and tested against Windows and Samba servers, so iSeries edge cases are genuinely underserved.
What to include in the rclone PR
Keep it tight but complete:
- The IBM i release version(s) you tested against
- What the failure actually looked like — error message, negotiation timeout, whatever it produced
- A link to the go-smb2 PR that introduced the fix
- Confirmation that the failure is gone with the updated library version
Rclone’s contribution guide asks contributors to run make quicktest and ensure CI passes. Testing against a real iSeries box obviously won’t happen in their CI environment, so an explicit note that you’ve verified the fix against IBM i X.Y carries real weight in the review.
What if no one bumps the dependency proactively
Rclone periodically runs make update to refresh all dependencies, so the fix will land eventually even without a dedicated PR. That can take months, and it’ll be buried in a bulk update commit with no iSeries context. The dedicated PR is faster and makes sure the change is documented with the right explanation — not just a version number increment.
Sources