DeployStudio Imaging - /Library permission & group changed

[ant89]

Anyone use deploystudio for imaging? If so, do you notice the /Library permissions and group changed from from root:wheel to root:admin and mode 755 to 775? Anyone know of a quick fix for this?

I noticed this since the new sophos endpoint app wont install unless /Library is set to root:wheel 755

My image is just the stock OS 10.12.6 created with autodmg. Nothing additional added since we use DEP. I did do a restore via recovery w/o deploystudio and the group and permissions were set correctly.

Any help is appreciated. i didnt see anything on the Deploystudio forums. Thanks!

[JoshRouthier]

I've been following the Sophos Cloud saga closely this past week, and I can confirm I noticed this with some of my older computers that were imaged using DeployStudio (we've since moved away from it). What caught my eye about this was I was seeing some of my computers not auto-updating to the 9.7.4 version, and when I got into troubleshooting it, I found exactly what you described. Once I disabled SIP, updated the /Library permissions, enabled SIP, Sophos was able to update/install to the 9.7.4 version.

[ant89]

So it appears that deploystudio changes the permissions on /Library
I added these two lines as a separate script

chmod 755 /Library
chown root:wheel /Library

but im getting

chown: /Library: Read-only file system

Anyone know if/how these changes can be run without disabling SIP during the imaging process?

[ant89]

got this figured out. the script to run is

chmod 755 /Volumes/Macintosh HD/Library
chown root:wheel /Volumes/Macintosh HD/Library

Run it NOT postponed

[ooshnoo]

@ant89

Not working for me still. install still fails. Can you possibly post screenshot of your DS workflow?

[ant89]

@ooshnoo here is my workflow and script

[ooshnoo]

@ant89 Thanks. That's exactly what I have, and it's not changing the permissions.

[ant89]

Weird. I was stuck on this too. but some help from the macadmins slack told me use the full path instead.

chmod 755 /Volumes/Macintosh HD/Library
chown root:wheel /Volumes/Macintosh HD/Library

Im not sure what your issue might be. Disabling SIP may fix it, but thats what i was trying to avoid in the first place.

what do the logs say??

[ooshnoo]

Exactly.. I can't disable SIP. I copied verbatim the commands you use, and once imaged, it still comes up as root:admin

[ooshnoo]

@ant89

Ok, getting somewhere. It's either the "Hostname" or the "Configure" form in the DS workflow that's doing it, as if I exclude them from the workflow, permissions are left as they should.

[ant89]

@ooshnoo so if you dont add the hostname or configure in your workflow, the permissions dont get changed to root:admin? did you still have to add the script?

I have never used hostname or configure in my workflow.

[ooshnoo]

@ant89

turns out if I add ANYTHING to workflow aside from applying the image and changing the permissions via script, the install fails. Even running a script (postponed) immediately following changing the permissions causes the permissions to be changed to root:admin

I'm dead in the water. I guess that's what I get for relying on open source. Deploy Studio has finally failed me.

[smcmjeff]

Add me to the list. I continue to use DeployStudio to image older computers. On newer models we use DEP and PreStage Enrollments. One of our technicians noticed that the Sophos Cloud install package I put in Self Service was not installing on these computers. I eventually found this thread and checked the permissions. I fixed the permissions manually and I was able to run the latest Sophos Cloud Installer.

I created the script and tested it by netbooting a computer that had the incorrect permissions. I ran the workflow (consisting of just the script), and when the computer rebooted, the permissions were fixed. However, when I added it to my workflow, I initially placed the script directly after the "Restore" and before 4 different "Package" installs. After the workflow completed, I checked the permissions and they were still wrong. I took a chance, and moved the script to the end of the workflow (see image). I didn't think it would work, but it did. Tested on two different computers and it seems to be working.

I think DeployStudio is great. I was going to continue to use it to lay down AutoDMG's of clean OS's on older DEP and non-DEP computers to be able to get them back into production faster. Unfortunately, it has been a while since the last update. I am probably going to start to look at the imaging component of JAMF Pro.

[ant89]

Glad it worked for you @smcmjeff -- QQ off topic -- i see you have Clean 10.13.3 build as one of your workflows. In your workflow, did you have to add the FirmwareUpdate.pkg in order to get high sierra to install? (for machines thats never been on high sierra)

[mm2270]

I hadn't even noticed this issue until I came across this thread some days ago. Turns out our DS workflow for 10.12.6 was doing the same thing, changing group and permissions on the /Library/ folder.
I was able to get it fixed using the process you outlined @ant89 - thanks! What I found out though is the script to change the owner/group and perms back to default needs to be the last item in your workflow. (Edit: @smcmjeff outlined the same finding above) I had it originally running right before another script to restart the Mac, and it kept reverting back to root:admin 775. I was able to see the permissions change on the Library directory for a split second and then revert back to the wrong setting. Annoying!
Once I had it running last it fixed the issue.

I have no clue why DeployStudio would be doing this, but I'm glad you posted about it and figured out a fix. I hadn't seen any issues with the wrong permissions on Library. but, better safe than sorry. Last thing I'd want is to have a bunch of Macs imaged this way and then have to fix it later, since SIP makes that a bit problematic to say the least.

[ooshnoo]

@mm2270 Thanks for the info. I confirmed that running permission change last in the workflow does solve that issue...however since we install Sophos via command line, we're still stuck as it fails if we try to install it using deploy studio and NOT postpone the install until after reboot.

We're just going to move on to using Jamf Imaging and throw deploy studio to the wayside.

[warrenmcall]

DeployStudio is life changing. Image of the base OS in ~5 minutes.

Has anyone gotten it to work with 10.13? I haven't spent much time trying to figure it out, but the netboot never works for me.

[mm2270]

@ooshnoo I'm sorry you need to do that. I've always found DeployStudio to be more flexible than Jamf Imaging, at least once it matured. Jamf seems to have hinted in a very roundabout way that Jamf Imaging may not have a long life ahead of it, so I don't know where that leaves things.
Of course, "imaging" is just about dead anyway with High Sierra. I'm guessing whatever the next OS is that Apple releases is going to put the final nails in the old style imaging coffin anyway.

Just as an aside, any reason you need to install Sophos via command line and not with a pkg? Can the script you use just be rolled into a pkg install? I guess I'm not understanding why the fix wasn't something you could implement. I had rolled the chmod and chown commands into a final script that runs as part of my last workflow item before the Mac reboots. It's not even it's own script. I just dropped the necessary lines into the script that runs at the end and it resolved the issue for me.

[carlo_anselmi]

Could it be because of line 41 within "ds_finalize_install.sh" even before "ds_finalize.sh" runs at the end?
/Your_DS_Main_Folder/Scripts/Common/ds_finalize_install.sh

if [ ! -e "${VOLUME_PATH}/Library/LaunchDaemons" ]
then
  mkdir -p "${VOLUME_PATH}"/Library/LaunchDaemons
  chmod 775 "${VOLUME_PATH}"/Library
  chown root:admin "${VOLUME_PATH}"/Library
  chmod 755 "${VOLUME_PATH}"/Library/LaunchDaemons
  chown root:wheel "${VOLUME_PATH}"/Library/LaunchDaemons
fi

Ciao
Carlo

[ooshnoo]

@carlo.anselmi Where exactly are you finding that "ds_finalize_install.sh" script.

[carlo_anselmi]

@ooshnoo I found it within Deploy Studio's "/Scripts/Common" folder

[ooshnoo]

DeployStudio has released a beta version that fixes the permissions issue, thus allowing Sophos to install

http://www.deploystudio.com/Downloads/DeployStudioServer_v1.7.9.dmg

[lkrasno]

Though we were able to resolve and script a workaround for DS resetting /Library to 775 (its now fixed in DS 1.7.9) for new installs, we are still recovering from the fallout.
We found about 150+ clients in our environment not upgrading to 9.7.4 with latest definition of 5.48
Fortunately, we have found that MacOS upgrades, reset the permissions to 755. (and we have held out on 10.13 so far for general staff)
I would encourage ya’ll to get some reporting in place, the 775 permissions not only affect installs but appear to halt Virus-Def and applications updates to 9.7.4
I haven’t found an easy way to report out of Sophos Cloud and am doing so instead via JAMF.
For anyone interested, this is my EA for the /Library perms:

!/bin/sh

LibraryPermissions=stat -f %Mp%Lp /Library
echo "<result>$LibraryPermissions</result>" (edited)

[byrnese]

Does anyone have a script that is deployable through Jamf? We recently purchased Sophos and are unable to deploy it on a number of systems because we've been deploying with DeployStudio and our /Library folders are messed up. When I try to pushed Library_perm.sh script shown in @ant89 workflow through Jamf, or when running manually, it receive operation not permitted on the chown step:

[STEP 1 of 4]
Executing Policy DPFix
[STEP 2 of 4]
Running script DeployStudioPermissionFix...
Script exit code: 0
Script result: chown: /Volumes/Macintosh HD/Library: Operation not permitted
[STEP 3 of 4]
[STEP 4 of 4]

I am using that script because our Sophos script is failing due to /Library permission errors:

Executing Policy Sophos Push
Mounting JAMFDS1
Verifying package integrity...
Installing Sophos-1.2.0-Scripted-20180823.dmg...
Closing package...
Running script SophosInstaller...
Script exit code: 1
Script result: Permissions on /Library might not be right.
Owner and group on /Library might not be right.
2018-08-23 15:44:22.028 Sophos Installer[70929:1154213] Starting Sophos Bootstrap Installer.
2018-08-23 15:48:40.498 Sophos Installer[70929:1154213] Installation failed. See install.log for detailed information.
The Endpoint installer failed. See /var/log/install.log and /Library/Logs/SophosDiagnostics.gz
Error running script: return code was 1.
Checking for patches...
No patch policies were found.
Unmounting file server...