Applications folder not owned by root, cannot change it

After a recent run of Migration Assistant from an old MacBook to a new one, my Applications folder is owned by my normal user account rather than by root. This prevents VirtualBox from functioning (see here, for example).

Attempting to fix the permissions with a simple sudo chown root /Applications gives the error chown: /Applications: Operation not permitted. This is pleasantly vague, and the Internet assures me that there may be many causes. (I had other sources I could cite, but I'm new to this site, and thus can only post up to 2 links.)

I do not wish to just start removing flags carelessly from /Applications, so I've done some investigating instead. Here's what's NOT the problem:

• File flags: Only the sunlnk flag is set, which prevents /Applications from being deleted. Seems entirely appropriate for /Applications, so I think there's no problem there. In particular, the suchg flag is NOT set.
• SIP: That feature doesn't govern the /Applications folder, as far as my reading indicates. So I don't think I need to do any of the "Recovery Mode" business to disable SIP.
• ACLs: The only one reported by ls -le is group:everyone deny delete which, again, seems entirely appropriate, and doesn't seem to have anything to do with chown.

So that's what's NOT the problem (I think). But I don't know what IS the problem.

Funnily enough this is a perfect example of one of the few situations where repairing disk permissions is actually called for.

Unfortunately the Repair Disk Permissions option has been removed from Disk Utility in El Capitan.

However you can still do it from the command line.

In Terminal run the following command to find out which permissions are incorrect.

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

And run the following command to repair the permissions.

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

More information here: http://osxdaily.com/2015/11/04/verify-repair-permissions-mac-os-x/

Turns out I was wrong to assume that SIP could not be at fault. When trying the operation with SIP disabled, it worked. I also needed to chmod /Applications to have permissions 755 (was 775) before VirtualBox would be happy, but that, too, was doable with SIP disabled. All working now.

Thanks to a discussion ranklord and I had in some comments above, and then in the chat for this question, for figuring this out.