7

It has been a while since last using Fritzing, and I was trying to open one of the files I saved almost 2 years ago.

The iMac was purchased early 2018, and everything copied from my MacBook

I have updated my iMac to the latest Mojave release, and got strange errors.

enter image description here

I looked at /Applications/Fritzing.app to see what I could change and found it was owned by my daughter (who has a login on my computer)

I used chown to change this, but a few other apps were also owned by her.

I seem to have a collection of root, ian (me) and bec (even one owned by my wife). Neither of these would have installed any apps on my computer, so I don't know why.

My question is what is the correct ownership for files in /Applications

nohillside
  • 100,768
Milliways
  • 7,972
  • I've rolled back you edit because the added details about Fritzing.app don't directly relate to the main question you've asked (and got answered). You can always ask a separate question for this (or reach out to any support organisation this app has first). – nohillside May 24 '19 at 15:51

2 Answers2

10

The correct owner of an application bundle within /Applications for preinstalled Apple apps is: root

The correct owner of an application bundle within /Applications for packaged installers user installed apps is: root

The correct owner of an application bundle within /Applications installed by the App Store is: root

The correct owner of an application bundle within /Applications for drag and drop user installed apps is: $USER 1

1 Where $USER is typically the short name of the person who installed the app. Otherwise, use the short name of the USER who is to own the file.

Here are the results of the ls -leO@d command run from Terminal on the Fritzing application bundle:

$ ls -leO@d /Applications/Fritzing.app 
drwxr-xr-x@ 3 me  admin  - 102 Jun  6  2016 /Applications/Fritzing.app
    com.apple.quarantine     57 
$

Same command run on the directory mentioned in the error message shown in the OP:

$ ls -leO@d /Applications/Fritzing.app/Contents/MacOS/fritzing-parts 
drwxr-xr-x@ 15 me  admin  - 510 Jun  6  2016 /Applications/Fritzing.app/Contents/MacOS/fritzing-parts
    com.apple.quarantine     57 
$

To change owner of a user installed app, e.g. for Fritzing, use the following command in Terminal:

sudo chown -R $USER /Applications/Fritzing.app

Note you can leave $USER as is written if you are the logged in USER and you are taking ownership. Otherwise, use the short name of the USER who is to own the file.

Also consider checking the permissions and adjust as needed. As in this case for Fritzing:

sudo chmod -R 0755 /Applications/Fritzing.app

As I have Fritzing installed and working, and its permission are as previously shown, I believe the error message is somewhat erroneous and is being caused by you not being the owner. Changing ownership as previously shown should resolve your issue.

user3439894
  • 58,676
  • What about those installed from Mac app store? – haridsv Jun 04 '21 at 04:27
  • @haridsv, RE: "What about those installed from Mac app store?" -- I've update the answer to address your comment. --The correct owner of an application bundle within /Applications installed by the App Store is: root – user3439894 Jun 04 '21 at 12:57
  • "The correct owner of an application bundle within /Applications for packaged installers user installed apps is: root" Is that true even if the installer was run without root privileges (ie, it didn't ask for a password during the install)? That's a bit... worrying. – Wowfunhappy Jun 04 '21 at 13:12
  • wow Thank you man! If you want you can use $(stat -f %Su) instead of $USER since user only works if you don't have admin rights. – BabyBoy Jun 04 '21 at 13:22
  • @Wowfunhappy, RE: "Is that true even if the installer was run without root privileges (ie, it didn't ask for a password during the install)? That's a bit... worrying." -- I have never had a package installer that didn't ask for permission and asking for permissions is the de facto standard and the answer reflects that standard. If you could provide a link to a package installer that does not ask for permission I'll be glad to check it out. I'd assume one that doesn't ask for permission will be owned by $USER. – user3439894 Jun 04 '21 at 13:26
  • @DarwinOSX Not sure I understand this. In which situations does $(stat ...) and $USER give different results and how are these relevant for the answer? – nohillside Jun 04 '21 at 14:36
  • 1
    Hi, @nohillside , if the user is logged in as root and the user tries to use the directory as his username and $USER, this directory will become root. However, if the user is not yet logged in as root and then enters sudo with $USER, the directory becomes the user name. While $(stat -f %Su) always has the user name. Just try it out yourself. Enter echo $USER in the terminal window with root and once in a new terminal window what is not yet root but becomes sudo echo $USER – BabyBoy Jun 04 '21 at 14:52
  • @DarwinOSX ah, interesting, thx. – nohillside Jun 04 '21 at 15:07
  • @Darwin OS X RE: "if the user is logged in as root" -- A side from the fact that the root account is disabled by default, and the average user doesn't have a need to login as root, running as root is discouraged as it opens the system up to potential unchecked malicious activity. That said, my use of $USER was conditional and I think you failed to see that, maybe because of your lack of understanding of the English language. I have added a superscript character and bolded the relevant text. – user3439894 Jun 04 '21 at 15:17
  • @Darwin OS X In other words, $USER is being used more as placeholder for what the users short name actually is supposed to be, not what e.g. echo $USER produces. – user3439894 Jun 04 '21 at 15:17
  • @user3439894 However, there are some who work with the Terminal and it would be nonsense if you are logged in as root to constantly create a new window instead of simply entering the command and the result remains the same. Apart from that, starting with macOS El Captain, most applications can not do anything dangerous anyway when they use sudo due to the System Integrity Protection. Just don't make it that complicated ?! – BabyBoy Jun 04 '21 at 15:22
  • @user3439894 Interestingly enough stat -f %Su returns the login user even after running sudo -s to launch a root shell (because apparently stdin still belongs to the login user) so I see some value here even if the root user is disabled. – nohillside Jun 04 '21 at 15:26
  • @nohillside I am well aware of stat -f %Su, however, I chose to write the answer as I did and I do not see an issue with how it's written. If one follows what it says, there shouldn't be an issue. – user3439894 Jun 04 '21 at 15:37
  • @user3439894 Besides, does it actually make a difference if you just use ls -l@d instead of ls -leO@d ? – BabyBoy Jun 04 '21 at 15:44
  • @Darwin OS X RE: "does it actually make a difference if you just use ls -l@d instead of ls -leO@d" -- I'd suggest you read the manual page for ls as the -e and -O options produce different output. I typically always use ls -leO@ as I want to see the information associated with the options given and just added d to the end in this use case as an application bundle is a directory. Typing ls -leO@ was just muscle memory if you will, and is of no harm with its usage herein! – user3439894 Jun 04 '21 at 16:11
4

Apps that are installed by the system, either out of the box or by an installer that asks for an admin password, will be owned by root. Everything installed by a user (i.e. drag and drop) will be owned by whoever installed them, which is where you seem to be running into issues if you require write permissions for updating and a different user installed that app. All of these possibilities are valid ownership.

You can safely change the ownership to yourself if you need to, or else you can use group permissions so that, for example, all users with admin privileges could update the app.

The below code changes the group (all files/folders in the .app package recursively) to the "admin" group, which all your users with admin privileges will be a member of, then adds write privileges for the group. You may need to use "sudo" at the beginning of each line if you don't already have suitable privileges.

> chgrp -R admin /Applications/Fritzing.app
> chmod -R g+w /Applications/Fritzing.app
Shannon
  • 281
  • I may edit this despite the +1 since root doesn’t really own much out of the box on macOS (or didn’t last time I checked). The correctness here is that a group of people should be able to modify third party apps and everyone should be able to read / run them without being “the” owner of the App bundle. – bmike May 23 '19 at 12:25
  • On my system there are 117 apps owned by root in /Applications, many of which are not the default ones that come out of the box. So I guess it depends on how the installation process functions on a per-app basis. – Shannon May 23 '19 at 12:29