Rpi-imager: Error: error creating firstrun.sh on fat partition when running on MacOS

[CaskAle]

When using the imager at v. 1.6.1 on a Mac Big Sur OS (V 11.2.3) we are seeing this error consistently.
Error creating firstrun.sh on FAT partition
I have seen reports of the same issue on Windows possibly fixed by a 1.7 beta. Is there such a beta for the Mac as well?
The microSD cards are 16gb and are using an Anker USB-C SD card adapter.

[maxnet]

1.7 beta was renamed to 1.6.1, as there were only small changes.
So you are already running that.

Not sure what is the problem here.
Imager does is able to create the file successfully on my Mac Mini (with an unknown brand USB-C reader that looks like this)

After it fails, you do are able to access the "boot" location in "Finder" and open say config.txt, add a random line of text there and "menu file" -> "save" the file?
It does not complain the device is read-only there or anything out of the ordinary?

[woolseyj]

I am seeing similar issues too. The firstrun.sh file did not exist on my first flash attempt, but it did show up on the second attempt, using v1.6.1 of the imager. However, I am still unable to ssh into the Raspberry Pi. I am using a Samsung Evo+ 32GB microSD memory card with the CanaKit USB MicroSD Card Reader.

[maxnet]

The firstrun.sh file did not exist on my first flash attempt, but it did show up on the second attempt, using v1.6.1 of the imager.

And you did get the same "error creating firstrun.sh on the FAT partition" error as the issue starter on your first attempt?

(Do note firstrun.sh gets removed by the Pi on first boot)

[woolseyj]

I never actually saw an error on either attempt. I did try to boot first before looking at the file system on the first attempt, so that may be why the file did not exist. While researching the issue, I came across some mentions where people had problems connecting to 5 GHz WiFi access points in general. On a third attempt, I changed the WiFi SSID from the 5 GHz access point to the 2.4 GHz version and everything seemed to work properly. So my issue may actually be related to 5 versus 2.4 WiFi access instead of the Raspberry Pi Imager itself.

[lurch]

So my issue may actually be related to 5 versus 2.4 WiFi access instead of the Raspberry Pi Imager itself.

Yes, that sounds likely. I can't see any reason why RPi Imager itself wouldn't work on the first two attempts, but then magically work on the 3rd attempt :wink: (especially if you never saw any error messages in Raspberry Pi Imager)

[CaskAle]

Sorry for the late reply. It turns out that this was indeed a restriction on writing to USB device. I had overlooked this as the problem due to the fact that the OS itself wrote out fine. It was only the copy of the firstrun file that was failing. Apparently the checking for USB write must be done at a higher level and the low level OS write was ok. At any rate once this restriction was removed, all is well. I am fine with closing this issue, however, since it seems to have generated other interest, I leave it to others.

[maxnet]

Sorry for the late reply. It turns out that this was indeed a restriction on writing to USB device.

Is that a setting in Mac OS X itself, or something introduced by third-party security software typically only used in larger companies to restrict what users can and cannot do?
Just wondering, in case other users will report similar problems.

[CaskAle]

It was the latter. Company wide restriction on USB writing. Exemptions allowed for special cases. Once we got an exemption, all was good.

[lurch]

Company wide restriction on USB writing.

Kinda ironic that the "security software" doesn't block low-level writing, as I guess that could theoretically be used to bypass the higher-level access restrictions :wink:

[maxnet]

Thanks for the info.
Since issue is solved, I'll close this one.

[18iteration]

Version 1.6.0 and can confirm the write process fails (Advanced / hidden options). Write process of Img works flawlessly though. This is not a big issue but should definitely be fixed as it just introduces confusion and extra work.

[maxnet]

Version 1.6.0 and can confirm the write process fails (Advanced / hidden options).

Concerns a company computer with security software as well?
If not, it is not the same issue.

[18iteration]

Version 1.6.0 and can confirm the write process fails (Advanced / hidden options).

Concerns a company computer with security software as well? If not, it is not the same issue.

My bad, it's night time and I missed some things/OP context.
Personal Windows 10 computer (with Bitdefender).

[maxnet]

Version 1.6.0
Personal Windows 10 computer (with Bitdefender).

Suggest you upgrade to 1.6.2 first, and open a new issue listing the exact error message if that fails as well.

[knipknap]

I ran into this same issue with imager 1.6.2 on a Ubuntu machine that has no particular security software installed, so I don't think it's related to that.
It did happen on a run where I set options (Ctrl+Shift+X) to set a hostname, enable SSH and Wifi.

On the second attempt, I also set the options for configuring a timezone and keyboard, and skipping the first run wizard, but the error persists.

When I don't configure any options, the imager runs fine.

There is no error output on the command line.

[maxnet]

I ran into this same issue with imager 1.6.2 on a Ubuntu machine that has no particular security software installed, so I don't think it's related to that.

This particular issue is about MacOS with corporate security software installed.
May want to open a separate one for Ubuntu.

If you installed Imager on Ubuntu through snap (Ubuntu software center) the right place would be here: https://github.com/popey/imager-snap/issues/16
Note that we did not create that snap package, it is provided by a third-party, and since it runs in a sandbox environment it behaves different to our version.

If you did download the .deb package from the Raspberry Pi website instead, try if it works better if you disable auto-mount in Ubuntu.
If it does work better if you change the auto-mount setting, it is likely already fixed in the next Imager version (there is a fix for dealing with auto-mount race conditions in the source code here on github, but that did not make it in a published release yet).

[crankyoldbugger]

I ran into this same problem when using the Snap version (1.6.2) of the rpi-imager. I tried to run it maybe six times, with a variety of errors, including the "firstrun.sh" issue.
I uninstalled the Snap version, and downloaded the .deb (again, 1.6.2) straight from www.raspberrypi.com/software, and it ran like a charm first time out.
Thanks to all who contributed here!

[erichlf]

I am having this issue on 1.6.2 installed on Ubuntu 20.04. I have isolated the issue to having custom settings. I tried to set wifi and ssh and if I do either or both of those things I get the firstrun.sh error.

[maxnet]

I am having this issue on 1.6.2 installed on Ubuntu 20.04.

How did you install Imager?
.deb or snap?

[erichlf]

which rpi-imager 
/snap/bin/rpi-imager

[maxnet]

/snap/bin/rpi-imager

Please report here: https://github.com/popey/imager-snap/issues/16
Alternatively, uninstall the snap, and get our package instead: https://www.raspberrypi.com/software/

[saramonteiro]

I am running that on Ubuntu 18.04.
rpi-imager 1.6 release works.

[maxnet]

I am running that on Ubuntu 18.04.

Assuming you are using the snap (as our .deb needs at least Ubuntu 20.04), please report here: https://github.com/popey/imager-snap/issues/16