Under our current 10.11 non admin build for junior school students, whenever a student attempts to print they get the following error:
You don't have permission to use the application "PrinterProxy"
The PrinterProxy file that is trying to open is located in the following location:
/Users has been restricted from running any Applications on these machines.
I am guessing this is a El capitan/10.11 issue because I have not seen this is any of our older builds.
Has anyone else had this issue ?
We are currently running into the same issue. The printers work fine on Mavericks and Yosemite, but once the system is upgraded to El Capitan the error pops up. At this point we are even allowing execution of applications from ~/Library/
I have contacted support and they are looking into a solution hopefully.
For the time being we have two major printers we need students to use so I have the temp fix in place.
I had a look at that post before I contacted support, however I can confirm that we do not have parental controls enabled on the user's account.
I got the following response back from the guys at support:
The QA team is going to be looking into; this workaround that is in place is the best available solution for the time being.
@ooshnoo The student has access to the System Preferences Pane and can add printers with no problems. However when they try and open the print queue I get the error " You don't have permission to use the application "PrinterProxy"
These machines are for our Junior School students so they do not have admin rights and using profiles we have set a restriction to Disallow Folders at /Users. This has always worked for out 10.10 clients and I am only seeing this error under 10.11 clients.
Although my work around has this working for our two main printers in the Library, I will not be able to manage this for the students personal home printers.
@rcastorani The last email I received from JAMF support was:
"You'll be able to track the progress on this issue with a issue number that we'll receive when they begin to investigate; we can send that your way once it's available, and the release notes will contain updates about whether or not it's been resolved,"
I have not received anything back from them, however the more people that report the problem might help with a solution.
We are seeing the same error when students print, but the printer still prints their job. Some students don't bother to check the printer because of the error so for us it is more of an annoyance.
We are currently testing 10.11.3 with a restricted student account ready for roll out during the summer holidays and we too are getting this permissions error.
There is no way we can enable students access to all apps so a fix by JAMF or Apple would be more than welcome!
I got a chance to mess with this a little more last week and got it working.
We have a configuration profile with application restriction configured similar to those at the beginning of this discussion. Based on my experiments I think that if you add paths to the Allow Folders list it restricts applications to only run from those folders. In other words, by creating a whitelist everything else is blacklisted. I changed our configuration thusly:
I don't think I need the disallow folders, but I'm going to leave it because it works. With this configuration applications won't run from USB drives, ~/Scripts/, folders that users create in their own home folder, etc. By allowing ~/Library/ we no longer get the printerproxy error or any of the other errors that would come up from time to time. That's the only folder in the list non-admin users can write to, but since ~/Library/ is hidden in finder most of my users won't even know it exists.
That will not work for us, I even need to run a script to check for any read/write areas in the OS because the students will find any read/write areas within the build to copy games to.
We do not allow anything to run from /Users and at this stage this is not something we can change.
@pnbahry Gotta love their ingenuity though! Off-topic, but are they checking via a script or just brute force? I have a ton of hidden places that they don't know they can write to simply to remove the incessant nagging permission popups.
@dentlerb Thanks for taking the time to write that out. We're having the same issues and since we have the same config profile system in place I'm going to take your advice and give those folders a shot.
@rcastorani Let us know how that works for you. All I'm going by is my experience from making those changes so your mileage may vary. Any information that can help us sort this out is valuable.
@pnbahry I think you must have some clever students. I am going to check on some of my more clever students and see if they have figured it out.
Same problem here! Haven't found a solution yet. Adding directories above hasn't helped here. Note I am still using MCX here.
Only way I can get it to work is allow / or /Users or /Users/usersusernamehere
Putting ~/Library or any other folder doesn't seem to work.
Previously I had Disallow:
And various apps in /Applications and /Utilities
And only allow was:
Now I have it like this:
Various apps in /Applications and /Utilities
So users could run apps from root of their home but nothing under it. Odd behavior!
Not here I have always used the following setup, 10.8.5 clients are currently running fine with this setup. I was skipping straight up to 10.11.4 and ran into this problem:
Previously I had Disallow Blacklisted:
And various apps in /Applications and /Utilities
And only allow whitelisted was:
I did try to whitelist ~/Library/Printers and ~/Library and made no difference for me. Verified the settings where in /Library/Managed Preferences/ as well. I'm still using MCX instead of Profiles, but wouldn't think that would be it.
I have run into this same issue and as described by @pnbahry on 1/11/16, JAMF Support has recommended that anyone with this use/case scenario go ahead and create the symbolic link.
Non-admin users were able to print but continued to have issues with the prompt; "You do not have permission to run PrinterProxy..."
Non-admin users are now able to print without a prompt.
JAMF has also opened a RADAR ticket with Apple as, according to JAMF Support, "it was also replicated with Profile Manager with our internal testing". JAMF Support has shared their RADAR ticket number, 26297653, for anyone to leverage and create a ticket as well -- maybe we can get some momentum with Apple providing a fix.
Just saw this myself, put in an enterprise ticket with apple referencing the RADAR above. Thanks for posting the info @gcash - Did you try doing a symbolic link for the whole ~/Library/Printers folder? We support so many printer models it'll get ugly to do them all one by one.
Edit - nevermind reread your post and understand what you were doing now. Will try that as workaround.
Yes. In my investigation of this issue (we restrict execution from ~/) I found the same. The issue being if you whitelist under a blacklisted folder, results are random. This has been an issue since OSX..... well, since OSX.
I'm not holding my breath. Symlinks to a whitelisted non-writable folder seems a more viable solution than waiting on Apple Developers to break their way out of the wet paper bag they're trapped in.
@CasperSally Thank you for your post. I am now able to print with non admin users. However, the printer proxy application for the printer (IE the printer queue app) is not launching. This means a user would not be able to delete jobs or resume a queue that had been paused. Any ideas? Is write access required?
Also, I found I had to manually create the /Library/Printers/Installed_Printers directory. The symlink file had no valid path to point to.
We implemented the solution suggested by @gcash and created a script similar to @CasperSally to create the symlinks for our 4 printers. However, we are now encountering circumstances where the system will write a new printer app inside ~/Library/Printers/ even though the proper symlink is present. It will generally add " - 1" after the printer name, since it recognizes that the symlink is there. This happened quite a while after we implemented the fix (that is, it seemed to be working initially). We have not been able to determine the circumstances under which the workaround is itself circumvented, since the users tend not to report such errors on occurrence. As stated by others, opening up a security hole as a workaround is not acceptable in our circumstance. So just reporting that the workaround may not be permanent in some situations, or that there are some assumed details (POSIX permissions, for example) that need to be handled for successful deployment.
I have been able to get this to work for all of my student computers by allowing access to ~/Library/ because the students have local home directories. However my teachers have their home directories on a local server. I have tried various mappings to allow access, i.e., Volumes/Users/~/Library/ or servername/Users/~/Library/ No Go. Any thoughts?