iso_url path doesn't work for windows network paths

[ztsmith]

Tried a few variations:
file://share/iso/en_windows_server_2012_r2_vl_with_update_x64_dvd_6052766.iso
file:///share/iso/en_windows_server_2012_r2_vl_with_update_x64_dvd_6052766.iso
\share\iso\en_windows_server_2012_r2_vl_with_update_x64_dvd_6052766.iso

Each variation results in an error when I try to build: "The system cannot find the path specified."

The first variation is the one I expected to work. The 2nd I believe is technically invalid, and I wasn't really expecting the UNC path to be supported.
Using packer v0.8.

[icnocop]

These worked for me:
"iso_url": "\\\\\\server\\share\\en_windows_10_enterprise_x64_dvd_6851151.iso"
"iso_url": "file:/\\\\\\server\\share\\en_windows_10_enterprise_x64_dvd_6851151.iso"

Windows 7 x64 SP1
Packer v0.7.5
"type": "vmware-iso"

[arizvisa]

I submitted a PR (#2906) that got things working more predictably when running on windows, and specifying a unc path. I just checked the following types:

file:///absolute/path
file://c:/absolute/path
file://\host\share\file
file://./relative/path
file://also/relative/path

Any other file:// uri schemes that you can think of?

[icnocop]

There are some more examples on wikipedia.

[arizvisa]

From looking through the wikipedia reference: one thing which is weird is none of these uri schemes that developers have implemented over the years try to differentiate between a \UNC\path and a /absolute/path/ as per posix. (I suppose one could use a unc:// scheme or something but that's going down some untreaded territory.)

I can implement file:///c:/absolute/path since wikipedia gives that as another example, I can also implement '|', but that's a valid (if not uncommon) character on most filesystems. Any other ones that you think people might care about?

[icnocop]

No, thank you.

I'm sure we can add more if/when needed. :)

[arizvisa]

New in go 1.6, url.Parse now considers the '' character illegal when specified in the hostname. Unfortunately due packer's usage of DownloadableURL in common/config.go, file paths are pre-formatted as a uri. So unless it's decided to explicitly treat file:////host/share/path as an smb-share (which is also a perfectly fine path that points to /host/share/path on posix), there really isn't a good way to support smb shares via the same file:// uri with '\' that people have been using.

Another option is to implement explicit support for the "smb" scheme which means one might as well implement "ftp" (#478) or any of the other protocols such as "smb". However, since smb:// isn't a known scheme it might not be a great idea just to start introducing this as the format for user's to specify their paths.

Really, the issue (maybe not an issue) is that packer is intentionally using the uri to store the path combined with meta-information about the path. So, If one wants to support #478 for "ftp" as well as "smb" or any other scheme, common/config.go and common/download.go should probably be consolidated.

So, in config.go any instances of url.Parse would end up being removed until it's been "normalized" and any instance of \\host\share\path would be pre-converted to smb://host/share/path. The next change would be that within download.go the url.Parse scheme could finally be used to determine whether an smb-client or ftp-client should be chosen. This would require actually adding stuff to the placeholder that mitchellh had left in download.go:80

[arizvisa]

I wrote PR #2906 that actually fixes this by splitting up smb into smb://host/share/path/to/file, adds support for ftp://host/path/file, and allows one to do file://c:/windows/path, file://./relative/path, file:///absolute/path, and file://relative/path.

[smudgerdan]

I have just upgraded from 0.10.2 to 0.12.3, I am on a Windows host.

my iso_url is "////hostname/shared_folder/windows10.iso"

I am now getting errors that it cannot download the iso, what should the url look like now?

[arizvisa]

@smugerdan: what version of go are you using, >=1.6?
Versions of Go greater than 1.6 require a properly formatted uri for url.Parse to work.

If using file://\\hostname/share doesn't work, or \\hostname/share doesn't work, you might need to manually transfer the .iso to each machine you build from or serve the .iso via a differing protocol like http or nfs.

If your situation allows for you to patch packer, you can manually apply PR #2906. This allows you to specify your smb path via smb://hostname/shared_folder/windows10.iso

[smudgerdan]

@arizvisa sorry for the delay in replying, I have had a chance to test in 1.0.0 and it has been fixed.

For what it is worth I have got the following format to work from a windows share:

"iso_url": "////server.domain.com/share/image.iso"

[mwhooker]

seems this has been fixed, so closing.

[ghost]

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.