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

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.

+.02¢

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

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.

@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.

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

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.

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.