Packer: vsphere-iso - UNC paths in iso_url don't work anymore

[jpgrall]

Overview of the Issue

Recently updated to 1.5.2 to use the new integrated vsphere-iso builder. Upon running my workflows (which previously worked on version 1.4.5), I'm getting the following message when it's retrieving the iso. I cleared the packer_cache but the issue still occurs.

09:34:38 ==> vsphere-iso: Download failed download not supported for scheme 'smb'

Reproduction Steps

Run packer build -var "iso_url=smb://server.domain.com/W2k19StandardBase.iso"

Packer version

1.5.2

Simplified Packer Buildfile

https://gist.github.com/jpgrall/e745fd96b6f059a311fed51fa7343190

Operating system and Environment details

Microsoft Windows Server 2012 R2 Datacenter

Log Fragments and crash.log files

09:34:38 vsphere-iso: output will be in this color.
09:34:38
09:34:38 ==> vsphere-iso: Retrieving ISO
09:34:38 ==> vsphere-iso: Trying smb://server.domain.com/W2k19StandardBase.iso
09:34:38 ==> vsphere-iso: Trying smb://server.domain.com/W2k19StandardBase.iso?checksum=md5%checksumvaluehere
09:34:38 ==> vsphere-iso: Download failed download not supported for scheme 'smb'
09:34:38 ==> vsphere-iso: Trying [] /usr/lib/vmware/isoimages/windows.iso
09:34:38 ==> vsphere-iso: Trying %5B%5D%20/usr/lib/vmware/isoimages/windows.iso?checksum=md5%checksumvaluehere
09:34:38 ==> vsphere-iso: Download failed source path error: CreateFile C:/ws/[] /usr/lib/vmware/isoimages/windows.iso: The system cannot find the path specified.
09:34:38 ==> vsphere-iso: error downloading ISO: [download not supported for scheme 'smb' source path error: CreateFile C:/ws/[] /usr/lib/vmware/isoimages/windows.iso: The system cannot find the path specified.]
09:34:38 Build 'vsphere-iso' errored: error downloading ISO: [download not supported for scheme 'smb' source path error: CreateFile C:/ws/[] /usr/lib/vmware/isoimages/windows.iso: The system cannot find the path specified.]
09:34:38
09:34:38 ==> Some builds didn't complete successfully and had errors:
09:34:38 --> vsphere-iso: error downloading ISO: [download not supported for scheme 'smb' source path error: CreateFile C:/ws/[] /usr/lib/vmware/isoimages/windows.iso: The system cannot find the path specified.]
09:34:38
09:34:38 ==> Builds finished but no artifacts were created.

[jpgrall]

Seems similar to #7783. Testing various formats of the iso_url to confirm.

[jpgrall]

Getting "Download failed invalid source string:" when using //server.domain.com/W2k19StandardBase.iso format rather than smb://server.domain.com/W2k19StandardBase.iso.

[andzn]

Probably caused by #7627 ? @azr

[GMZwinge]

Seems to have existed before #7627. See for example #8552. UNC path seems to have stopped working after 1.3.5, although the debug and/or error messages have slightly changed depending on versions. Could go-getter not work with UNC path?

[SwampDragons]

Yes, I suspect this is a result of the go-getter change. We'll probably need to make a PR against go-getter to make this work, though I haven't had a chance to sit down and work through this yet.

[andzn]

I took a quick look on the code, and debugged it a little bit and there's a lot of weird stuff going on there when it comes to UNC paths, mostly because they are not really URLs. I was able to hack up a working solution, but it was a little bit hard for me to find out a clean one, given the complexity of the current logic that covers many corner-cases.

From what I saw this is what's happening:
This line transforms every UNC path of the form \\server\share into a smb URL (smb://server/share). The go-getter however, doesn't support smb URLs. This is why before #7627, there used to be defined an smb getter which was only an alias to the file getter. Once that was removed, using a UNC path returns 'Download failed download not supported for scheme 'smb''.
Since smb is not supported, I decided to give file URIs a chance: file://server/share. However, it seems that go-getter doesn't cover the case where a file URI refers to a network share. But besides that, the logic in the download step from packer also modifies the passed file URL in such a way that it doesn't really look like a file url when it gets passed to go-getter anymore.

[SwampDragons]

This is potentially the same underlying issue as #8552

[andzn]

@sylviamoss I'm not sure where your comment has disappeared, but I've tested https://circleci.com/gh/hashicorp/packer/41554#artifacts/containers/0 and it worked perfectly for me.

[sylviamoss]

Good to know! I deleted the comment because one pipeline failed in my PR but nothing that would change the solution for you. I will send the binaries again if necessary! I was able to reproduce it locally anyways :D
Thanks for testing!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.