New users are being created with System as owner of their home folders

[stiermanc]

We recently deployed a set of preferences for Adobe apps. We had it packaged as a .dmg and the policy was set to run at login with an ongoing frequency. Both FUT and FEU were checked. This was scoped to around 120 Macs.

Something has gone wrong and now any user, local or AD, account that is created has System as the owner of their home folder instead of the user itself. I compared permissions on User Template folder on a working and non working Mac and they appear to be the same.

I have not been able to write a script that allows me to copy the User Template folder from one machine to another. Every time I get permissions errors...

We disabled the policy, but that did not resolve the issue. Reimaging the machine works but I am hoping to find a fix that doesn't involve that.

I can't seem to find any information about how the OS generates the default permissions for a new user folder.

[rqomsiya]

I’d move away from using FUT/FEU. Script a package to write to each users plist library. It’ll save you the headache later down the road.

Just my .02c.

[donmontalvo]

+.02¢

@stiermanc hopefully you're not pushing *.plist files.

[stiermanc]

Yes, they are plist files in the .dmg being pushed. How else would you change the default settings in applications for every user that logs in? I used Composer to snapshot before and after the preferences were set on all our standard applications.

We have a specific set of preferences for the Creative Cloud applications that we want to be defaults for every user who logs in. That involves pushing a number of .plist files to User/Library/Preferences.

[donmontalvo]

@stiermanc wrote:

How else would you change the default settings in applications for every user that logs in?

Example...

#!/bin/sh

over500=$( dscl . list /Users UniqueID | awk '$2 > 500 { print $1 }' )

## Set User Template (FUT)

/usr/bin/defaults write /System/Library/User Template/English.lproj/Library/Preferences/com.company.product.plist <key> <value>
/usr/bin/defaults write /System/Library/User Template/English.lproj/Library/Preferences/com.company.product.plist <key> <value>
/usr/bin/defaults write /System/Library/User Template/English.lproj/Library/Preferences/com.company.product.plist <key> <value>
/usr/bin/defaults write /System/Library/User Template/English.lproj/Library/Preferences/com.company.product.plist <key> <value>
/bin/chmod -R 700 /System/Library/User Template/English.lproj/Library/Preferences/com.company.product.plist
/usr/sbin/chown root:wheel /System/Library/User Template/English.lproj/Library/Preferences/com.company.product.plist

## Set for existing users (FEU)

for u in $over500 ;
do
    /usr/bin/defaults write /Users/"$u"/Library/Preferences/com.company.product.plist <key> <value>
    /usr/bin/defaults write /Users/"$u"/Library/Preferences/com.company.product.plist <key> <value>
    /usr/bin/defaults write /Users/"$u"/Library/Preferences/com.company.product.plist <key> <value>
    /usr/bin/defaults write /Users/"$u"/Library/Preferences/com.company.product.plist <key> <value>
    /bin/chmod -R 700 /Users/"$u"/Library/Preferences/com.company.product.plist
    /usr/sbin/chown "$u" /Users/"$u"/Library/Preferences/com.company.product.plist
done

exit 0

Not a fan of the DMG format as used by Composer...however looking forward to the day drag-install DMGs can be uploaded to Jamf Pro, to deploy stuff provided by vendors in a DMG without having to re-package.

[Nix4Life]

@donmontalvo and @rqomsiya , have pointed you in the right direction. I'd also look at outset
to run the script(s) at login

[stiermanc]

I’ll give that script a shot and see if I can make it work.

Any thoughts on fixing the machines that are making system the default owner of any new home folder? I’d like to avoid reimaging a hundred machines.

[deployFrankPR]

We had a similar issue with FEU as you describe. It seems that any user with a space in their username (and therefore home holder) e.g John Smith instead of john smith got permissions incorrectly assigned to the local next user WITHOUT a space. In our case it was _Sophos. Users WITHOUT a space in their home folder didn't exhibit this issue. Because all our AD users have a space in their name this issue affected any AD user. In my opinion it's a bug in JAMF Pro and I have reported it as such. Its also a potentially huge security breach. Imagine if a local user with no spaces in their name is given permission to access an AD users local files? We had to wrote a script to re-apply the correct permissions after we pushed down the preference files. NOT ideal.