Mac OS Sierra mBot Upload Fail on Managed Account


I have the mBot and MakeBlock V 3.4.11. My son uses a Managed account on the Mac and I have a system Admin account on the same computer. Everything works fine within the Admin account. Connecting via the USB cable.

However, within my son’s account he can do the programming, and connecting via the USB cable, the upload fails. It launches the Adruino splash screen and gets most of the way through and then it fails.

Since it works within the Admin account and not in the managed account, I’m thinking it’s a permissions thing. How do I set up permissions to allow my son to launch MakeBlock from an icon and be able to upload / program successfully? I’d rather not give him Admin permissions to the entire computer. Can this be done to just the program? Other ideas?

Thank you for your help

MacBook Pro Retina
MacOS Sierra v 10.12.6
MakeBlock v3.4.11


Hi mwjosey,

Normally, there is no permission requirements of mBlock on Mac computer. You may restart the computer or reinstall the mBlock 3.4.11 have a try.
Besides, please also check if there is any special settings prevent the managed account from running all the function of the software.


Restarting and re-installing is not the solution. As stated the software/process works perfectly fine while in the Admin Account, but not within the Managed Account. It appeared to only be the upload to Adruino process which was hindered. Everything else appeared to work fine.

Here is what I did to solve the issue. 1 - I noticed that the upload process seams to call another program to run. This program did not reside within the main Applications folder on the Mac. 2 - I figured there was some sort of permissions thing hindering the second app from running, even though I had given specific permission to the MBlock app to run in the managed account.

I found this site:

These allowed me how to look through the MBlock application contents/files. Using the “get Info” menu (right click on a file name, select get info from the pop up menu), I discovered the managed account had specific read/write permission for the executable. In that folder structure I found the MBlock executable (contents/MacOS/mBlock) by looking for a black icon with tiny word “exec” in it.

I also dug around some more and found the application which is launched during file upload process /Contents/Resources/Arduino/ This is another packaged application, so right clicking and selecting show contents allowed me to browse it as well. All files within this application were included in the Admin Account and Everyone group, but not the Managed account.

I used the process described in the second site and gave every file and folder specific read/write access to the managed account. I did this in the package and the contents folders.

Everything now works in both accounts. I’ll post back if further issues come up.

Bottom line is that this should have worked on it’s own without me having to take multiple evenings to figure it out. Other applications can do this just fine. I’m curious if this was a thought within the development process. And I hope I don’t have jump through these hoops again when the next version of mBlock comes out.

@tec_support Would it have worked to include as a program in the Applications main folder rather then burying it? I’m curious if this would force the “enter admin user/password to allow it to run” pop up window when it gets called from mBlock in a Managed Account. I’m curious if with it buried like it is, the MacOS thinks it already asked the question. At the least it would allow for users to assign it permission via the parental controls section of the System Preferences application.

I’m sure I’m not the only one that doesn’t want to give full Admin privileges to a 10 year old.


Thanks for your information.

The Arduino module mBlock use will write in the App package every time it compiles. We might set the folder writable, or wait for the new version of mBlock - by then mBlock will get rid of the Arduino IDE and stay clear from those privilege problems.