Move Files With Admin Rights

I try to save some program Assets into this path (macOS):
“/Library/Application Support/MyApp” = SpecialFolder.SharedApplicationData.Child(“MyApp”)

I see a lot of other developers successfully placing stuff into that path but I can’t even create the folder path let alone Move/Copy files into it.
I always get “permission denied” response and I don’t know if or how can I prompt the user to enter his admin password to allow such action.

I know SpecialFolder.ApplicationData.Child(“MyApp”) works without admin rights but I think that in case a different user log on to this machine it will not be available to him, I need a place that my app will have access to under any user account on this machine.

A small (failed) syntax example:

Var f As FolderItem = SpecialFolder.UserHome.Child("Downloads").Child("DownloadedAssets") Var t As FolderItem = GetFolderItem("/Library/Application Support/MyApp/Assets", FolderItem.PathTypeShell) If f <> Nil and f.Exists Then t.CreateFolder f.MoveTo(t) End If

I would love it even better if I wouldn’t have to use extra plug-ins for such action but at this point any working solution will be Greatly appreciated :slight_smile:

In Xojo, it’s easier to access SpecialFolder.SharedDocuments because on Mac that ends up resolving to /Users/Shared which you need don’t special privileges to write in.

Thanks Tim, this can be a fair workaround in case nothing else pans out.
Is it really that hard to get admin permission to SharedApplicationData ?

Yes. You will need plugins or to dig around in macOSlib to find authentication routine. With MBS you can get an elevated shell and then sudo cp; I’m not sure what macOSlib holds.

Additionally, users should be wary of handing out elevated permissions. If you can do something without needing authentication, use the safer, non-authenticated route.

I see @Tim Parnell in that case I’ll settle with Users Shared as “the lesser evil”
Not sure why Mac elevated user permissions wasn’t addressed in any of the Xojo’s classes/methods but it is what it is.

Thanks again for your insight!

Just as a reminder, files and folders you put in /users/shared won’t automatically lose their owner permissions. If you want these files/folders to be writeable by anyone, the simplest way is to allow write (and, if you really must, execute) right after you create the item (so that the created item still has write permissions under the current user to change those permissions).
If you otherwise wait to write to an existing item when in another user’s account, you may face the same permissions issue.

Obvious, but worth mentioning.

Thank you for your input @Arnaud Nicolet
It did took me a while to figure that out while testing but I already set it, if you would add your reminder yesterday you would of saved me an hour of head scratching :slight_smile:

Yes… My problem is I usually spend only one day per week reading this forum (other days for other forums), and this is the day for this week. So I’m often late in responding, although I answer anyway, in case someone else encounters the same question (or the original poster has also delayed dealing with the thing I write about :slight_smile: ).
Better late than never, they said…

You’re welcome.

Another way, is to use Apple Script to execute the shell commands with authentication.

Seems perverse to call into Apple Script to execute shell/console/terminal commands at the admin level, but hey, it’s not deprecated (yet).

The officially supported way is to use XPC, which is a just a bag of unclear and frustrating pain.

If all other methods wouldn’t prevail, that was my next (and probably final) stop :wink:

If you don’t need to do something as root then AuthorizationMBS from the MBS plugin works fine. Going the AppleScript route is simple.

Thanks @Beatrix Willius