Disk Image Stays Mounted on User Accounts

[stutz]

Hello,

Trying to figure out why this is happening. User goes into Self Service and downloads Adobe Flash Player. The file is in .dmg format. The mounted disk image for Adobe Flash doesn't appear on the users desktop but if you sign out and sign in as another user its mounted on their desktop. If you sign out and log back in as the user who originally installed it from Self Service the disk image is still mounted. To eject, it requires administrative rights. How do I fix this? I thought mounted .dmg images eject after logging out.

Is it the way Adobe Flash Player .dmg was re-packaged?

[stutz]

Anyone else getting this? I thought disk images unmount when you log out.

[hphan]

We have this issue. We deploy a Configuration Profile - Restrictions. Check the Ejects at Logout under Media tab and it seems to work out. Make sure you set other settings correctly in this Configuration Profile.

[mmcallister]

We are also seeing this with Adobe Flash Player.

[stutz]

I tried the force unmount on logout restriction profile and it didn't seem to work. The disk image will go away if the computer is restarted but if you install the DMG file(s) and logout and log in as a different user it stays mounted on the desktop. It requires an admin account to eject it.

I noticed when the DMG finishes the installation it just umounts the disk image and doesn't eject it. You can verify this in Disk Utility. Running a simple "umount" command at then end of the policy doesn't seem to eject the disk image.

[glaske]

We have this issue as well. Shows nothing mounted in the user after the policy is finished, but once we logout and log back in, then we have a ton of DMG's that were previously installed. Anyone found a way to solve this? We are on JAMF 10.6 and the OS that we have confirmed this on is running 10.13.6.

[bradtchapman]

...clean up after yourself so the disks can’t possibly mount?

(even if it is a bug in macOS, or a Jamf thing that requires a PI, why not add a script that unmounts the DMGs, sets them to chmod 000, and/or deletes them entirely?)

[pfrancois]

I'm seeing this same issue on all user logins where Jamf is configuring the user account. Any suggestions on how to get Jamf to eject the DMGs after it mounts when filling user directories?

[glaske]

I have a support ticket in with this and it's definitely an issue. This is what was recommended as a current workaround as there is no solution currently:

1) Use a non APFS formatted DMG. 2) Include a '/usr/bin/hdiutil detach /Volumes/Volume_Name_Of_DMG' command in the Execute Command field of the Policy to force the detachment.

Unfortunately, I have tried both things and we are still experiencing this issue. Feel free to give it a try though. I also have a few DMG's that need to stay that way, but other than that, I moved to all PKG's. We experience this issue on every login, so it's pretty blatant that it's a problem. Make sure you report these issues to your buddy!

[pfrancois]

Thanks @glaske , the commands seem to help...for now.

[Randydid]

I had this while trying to update CC 2017 last year. I just created a policy running at login that called this simple script to "Run After" as a DMG with FET and FUT and that worked in a pinch.

#!/bin/bash
/usr/sbin/diskutil unmount /Volumes/AdobeSerialization

[Cornoir]

I encountered this exact issue recently and was able to com up with a fix which might help you.

Mount using the hdiutil

hdiutil mount /private/tmp/DISKNAME.dmg

Find device name of Volume DISKNAME.DMG

PART=$(df '/Volumes/Disk Name' | grep "/dev/" | awk '{print $1}')

Unmount DISKNAME drive

hdiutil detach $PART