Change:
When registering a new driver the client is sending the filepath of the socket as the / header instead of . In practice almost all / servers outright reject this as invalid. Given that the client was updated years ago I'm unclear why this problem still persists to this day :( kubelet logs look like this: csi server logs look like this: Registration to move along happily. simple instructions here: Most drivers are written in and the server simply ignores this non-compliant header, otherwise the issue would be far more prevalent. <detailsEvery version up until current AFAIK. </details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
I ran into this error in my use-case and debugged what's going on. I think the problem goes away with a recent enough and when the socket path is correctly prefixed in the client connection: I though I could start working on fixing this in kubelet.
That would be awesome! Then I can finally do away with all the crazy workarounds.
The nomad issue link you gave tried the approach I was talking about without luck it seems. I need take a closer look what's wrong...
btw, this look a duplicate of and
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale currently planning to use but I have some cleanup pending with first
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale The fix PR is pending approval

Discussion:
defer cancel() c, err := grpc.DialContext(ctx, unixSocketPath, <ins> grpc.WithAuthority("localhost"), </ins> grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithBlock(), grpc.WithContextDialer(func(ctx context.Context, addr string) (net.Conn, error) {

return grpc.Dial( string(addr), <ins> grpc.WithAuthority("localhost"), </ins> grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithContextDialer(func(ctx context.Context, target string) (net.Conn, error) { return (&net.Dialer{}).DialContext(ctx, network, target)