[zrzka] This issue has attached support thread https://jel.ly.fish/#/support-thread~fd2d6412-7ae4-4e8b-a356-a551bc8b3f5c

IIRC this is because the "mapped drive letter" is only visible to user-level processes, and isn't visible to admin-level processes.
The Etcher file-selector GUI runs at a user-level (and so the mapped drive is visible), but Etcher needs to switch to an admin-level process to have enough permissions to write raw disk images (and so the mapped drive "disappears"). The drive letter switching from Z:\ to C:\ looks very strange though! 😕

Slightly-related discussion in #1436

@lurch that makes sense, but this error appears immediately after the image selection. I mean, target device not selected yet, didn't click on the Flash button, just launched Etcher and selected an image. AFAIK elevated privileges are required when I click on the Flash button.

Maybe there's something going wrong with https://github.com/balena-io/etcher/blob/master/lib/gui/app/os/windows-network-drives.js#L87 🤷‍♂️

@zrzka can you please try this command and paste the output here?

C:\Windows\System32\Wbem\wmic path Win32_LogicalDisk Where DriveType="4" get DeviceId,ProviderName

@zvin here's the output ...

C:\Users\Robert Vojta>C:\Windows\System32\Wbem\wmic path Win32_LogicalDisk Where DriveType="4" get DeviceId,ProviderName
DeviceID  ProviderName
Z:


C:\Users\Robert Vojta>

... let me know if there's anything else I can do.

@zrzka interesting, the second column should have the share address: something like \\<ip address>\folder.

What is the output of
C:\Windows\System32\Wbem\wmic path Win32_LogicalDisk Where DriveType="4"

@zvin

C:\Users\Robert Vojta>C:\Windows\System32\Wbem\wmic path Win32_LogicalDisk Where DriveType="4"
Access  Availability  BlockSize  Caption  Compressed  ConfigManagerErrorCode  ConfigManagerUserConfig  CreationClassName  Description         DeviceID  DriveType  ErrorCleared  ErrorDescription  ErrorMethodology  FileSystem  FreeSpace    InstallDate  LastErrorCode  MaximumComponentLength  MediaType  Name  NumberOfBlocks  PNPDeviceID  PowerManagementCapabilities  PowerManagementSupported  ProviderName  Purpose  QuotasDisabled  QuotasIncomplete  QuotasRebuilding  Size          Status  StatusInfo  SupportsDiskQuotas  SupportsFileBasedCompression  SystemCreationClassName  SystemName       VolumeDirty  VolumeName      VolumeSerialNumber
0                                Z:       FALSE                                                        Win32_LogicalDisk  Network Connection  Z:        4                                                            HGFS        51547848704                              255                     0          Z:                                                                                                                                                                   250685575168                      FALSE               FALSE                         Win32_ComputerSystem     DESKTOP-QPANH16               Shared Folders  00000064


C:\Users\Robert Vojta>

@zvin there's no share address, because it's VMware Fusion feature. One has to install VMware Tools (aka drivers for Windows) to make it working. Then the Fusion shares folders via these drivers. Not a typical network drive. Thus it will be always missing.

I tried other programs and I can easily read / write files from / to these locations.

I have a fix, but I can't push to GH right now. I'll ping you as soon as I have a version to test.

@zrzka can you please test with https://github.com/balena-io/etcher/releases/tag/untagged-e2d9117a316adbb6a5d7

@zvin do I need any special permissions or ... because I've got 404 when clicking on the link.

@zrzka correct url: https://github.com/balena-io/etcher/releases/tag/untagged-5e09bbb3c3f6318103be

@zvin I can select my image, so, the issue seems to be fixed. But another issue appears when I hit the Flash button:

{  
   "stack":"Error: ENOENT: no such file or directory, open 'Z:\\SharedWithVM\\subfolder\\balena-cloud-rpi3b-test-raspberrypi3-2.38.0+rev1-dev-v9.15.7.img.zip'",
   "message":"ENOENT: no such file or directory, open 'Z:\\SharedWithVM\\subfolder\\balena-cloud-rpi3b-test-raspberrypi3-2.38.0+rev1-dev-v9.15.7.img.zip'",
   "name":"Error",
   "code":"ENOENT",
   "syscall":"open",
   "errno":-4058,
   "image":"balena-cloud-rpi3b-test-raspberrypi3-2.38.0+rev1-dev-v9.15.7.img.zip"
}

I was kind of expecting this.
Windows network drives are mounted by user so the administrator does not see Z: if it was "mounted" by another user.
That's why this logic of replacing drive letters with the real address exists.
There is nothing we can do in the short term about this.
The correct fix would be to read the image from the user process and stream it to the writer process through some ipc.

@zvin is the ProviderName being empty (and so being unable to get the underlying network share) an "unusual situation"? Maybe it'd be worth displaying an error message specifically about that, rather than falling through to the ENOENT error? 🤷‍♂️

@lurch we don't know if the read will fail in the writer process at this point.

@zvin that was expected. Anyway, thanks for investing time to into this. I consider this as an edge case. I mean, why should I use balenaEtcher on Windows, running in VMware Fusion on a macOS when I can use balenaEtcher for macOS directly.

Re warning / better error message - we know it, no? Something like ...

let network_drives = get_network_drives();
let image_drive = get_drive_from_image_path(image_path);
if let Some(image_network_drive) = network_drives.get(image_drive) {
    if image_network_drive.get_provider_name().is_empty() {
        // show warning, this is gonna fail, because admin can't see mounted
        // network drives and we can't remap it to the \\$IP\... drive
        return; // aka do not continue
    } else {
        // here we can continue, because it's a network drive, we can try to read it
        // in the elevated process via \\$IP\...
    }
} else {
    // here we can continue as well, because it's not a network drive
}

... I may be wrong, just thinking aloud about this.

Re warning / better error message - we know it, no? Something like ...

That's exactly what I was suggesting 😉

You can't be sure the writer process won't be able to read your image from here.

Hitting issues like this with sshfs mounted folder, just like in #1436

Sorry to bump a 1.5 year old issue, but I'm also hitting this problem. My workaround has been to map the image using the \\share\image.iso rather than X:\image.iso.

However, suggesting people use Etcher for writing image files to SD cards for use in RPis, and some of our users don't read the warning on our instructions page about this behaviour.

If it's possible, an error message indicating the inability to see a mapped network drive would be a tremendous help troubleshooting write issues, as this is the most common issue I'm seeing with our users.

[zwhitchcox] This issue has attached support thread https://jel.ly.fish/a5c6201a-392f-4096-8d85-b0b7cbcc4807

However, suggesting people use Etcher for writing image files to SD cards for use in RPis, and some of our users don't read the warning on our instructions page about this behaviour.

Sorry, but where is this instruction page where this is mentioned? Link? I see no link to any instructions on https://www.balena.io/etcher/, but maybe I'm missing something.
As you say: A lot of users (me included) just read some Raspberry Pi guide and never really see any instructions or warnings.

If it's possible, an error message indicating the inability to see a mapped network drive would be a tremendous help troubleshooting write issues, as this is the most common issue I'm seeing with our users.

This would be a very nice addition until the 'real problem' has a solution.
The current message just talks about "the drive" and given how most users just recently plugged in their SD-card, and their network share is very stable, this gives the vibe that there is something wrong with the SD-card part of the equation. (Which is probably working fine).
If it at least gave the Drive-letter (C: D: F: Z: whatever) of the drive it couldn't access that would be helpful. Also, a mention like "Are you trying to read your image from a Windows network share, then we are sorry: That is not possible at the moment".

And if this is really one of the most common errors people stumble on, then it is quite strange not even changing the error message has been fixed in the 3 years since it's been reported.

I believe that we have the same issue with 1.7.9

Flashing sdcard.img.xz from a mapped network drive on Win10/Win11 causes "Attention Looks like Etcher lost access to the drive. Did it get unplugged"
Changing to the UNC path works as expected.
E.g.
Z:\b\sdcard.img.xz will fail
\a\b\sdcard.img.xz works

Same here on Windows10 ver 1.18.4

Just ran in to this same behavior on Windows 11 with version 1.18.4 with the error pointing at the USB drive being the problem when really it was the image being on a network drive. I was able to successfully load the same image over SMB from my Mac, then after discovering one of the other bug reports that led here I was able to also load the same image to the same USB drive after copying the image to a local disk.

If this can't be easily fixed I strongly agree that at least fixing the error to tell the actual problem rather than sending users on a wild goose chase with their media would be very useful.

I was able to add the file. WORKAROUND/

Please try and let me know if that works out for you.

Copy the file to your desktop and select the file straight from the desktop. Simple as that.

I was able to add the file. WORKAROUND/

Please try and let me know if that works out for you.

Copy the file to your desktop and select the file straight from the desktop. Simple as that.

Really? this is not a valid workaround. there is a reason we have the .iso/.whatever on a network drive. it makes 0 sense to need to transfer (for example) a 6GB windows server iso to my desktop just to flash it. it should be able to read from the network share.

example iso directory on NAS: