vikashsingh009 / jzebra

Automatically exported from code.google.com/p/jzebra
0 stars 0 forks source link

OSX Cannot run program "/usr/bin/lpr": error=1, Operation not permitted #168

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I am on OS X 10.8 running JRE 7u45. I am unable to print any documents using 
the recent 1.7.0 release of QZ Print, despite having added the certificate to 
the trusted list and accepting the Java warning dialog.

The applet loads correctly and functions perfectly until it is time to print, 
at which point Java raises a printx error (see attached log excerpt from the 
Java console). I can observe the same behavior when attempting to print from 
sample.html.

My guess would be that the new JNLP deployment method sandboxes the application 
and denies it from running external shell commands. Any ideas on how to proceed?

Regards.

Original issue reported on code.google.com by tres.fin...@gmail.com on 25 Oct 2013 at 5:18

GoogleCodeExporter commented 9 years ago

Original comment by tres.fin...@gmail.com on 25 Oct 2013 at 5:19

Attachments:

GoogleCodeExporter commented 9 years ago
It looks like Java strengthened the way Runtime.exec() is called.

http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jruntim
e

This should be a relatively easy fix.  Targeted for qz-print 1.7.1 since it 
affects all Macs using the alternatePrinting method.

-Tres

Original comment by tres.fin...@gmail.com on 25 Oct 2013 at 5:38

GoogleCodeExporter commented 9 years ago
Unfortunately, this doesn't seem to be as easy to fix as I had originally 
thought.  The bug submitter is not using alternate printing, this message is 
thrown when trying to print through CUPS.

I have a feeling it is an access restriction on the OS with certain printer 
configurations.  I'll try to find more information and post it here.

Original comment by tres.fin...@gmail.com on 26 Oct 2013 at 1:45

GoogleCodeExporter commented 9 years ago
Confirmed this happens with or without alternatePrinting, and also happens on 
jzebra 1.5.3. Appears to be specific to Safari 7 as Firefox printing OK. Unable 
to test on Chrome due to the no-64-bit version and Java 7.

Original comment by m...@shust.com on 5 Nov 2013 at 8:52

GoogleCodeExporter commented 9 years ago
@Mark,

Can you post any information relevant to this bug (version of OS, version of 
Safari?)

We plan to purchase a Mac soon and I'll use the information provided to 
reproduce this issue and develop a work-around.

-Tres

Original comment by tres.fin...@gmail.com on 5 Nov 2013 at 9:17

GoogleCodeExporter commented 9 years ago
Safari Version 7.0 (9537.71)
OS X Version 10.9 (Mavericks), Build 13A603

Original comment by m...@shust.com on 5 Nov 2013 at 9:54

GoogleCodeExporter commented 9 years ago
Oooh ok I figured this one out. Go to Safari > Preferences > Security > Manage 
Website Settings

Click Java in left hand panel, and select site to allow jZebra/Qzprint, and set 
it to Allow Always.

I believe this manual override is the only solution to Safari 7+ as it looks 
like Apple is also beefing down their Java security settings. Good news is that 
I can be back developing on Safari now :)

Original comment by m...@shust.com on 5 Nov 2013 at 10:06

GoogleCodeExporter commented 9 years ago
Mark,

Fantastic find.  Anyone else have success with this setting?

Is this getting raised as an exception?  I would like to change the message in 
sample.html by filtering for "/usr/bin/lpr".  Can anyone confirm this will work?

-Tres

Original comment by tres.fin...@gmail.com on 6 Nov 2013 at 5:49

GoogleCodeExporter commented 9 years ago
Unfortunately this setting did not work for me, I have set 'Allow Always" on 
localhost but even after restarting Safari, I still receive the LPR error.

Original comment by firewing...@gmail.com on 8 Nov 2013 at 3:40

GoogleCodeExporter commented 9 years ago
@firewing1.linuxuser,

Thanks for the valuable information.  Can you post the details of your setup?

OS Version: 
Java Version:
Safari Version:
Firefox Version:
(Chrome + Java won't work on 64-bit Macs, so it has been omitted)

-Tres

Original comment by tres.fin...@gmail.com on 8 Nov 2013 at 3:54

GoogleCodeExporter commented 9 years ago
Firewing, try "resetting safari" -- I remember that I did that to clear out 
anything that has been cached. Then try again. (Safari > Reset Safari > Check 
all > Reset)

Original comment by m...@shust.com on 8 Nov 2013 at 4:14

GoogleCodeExporter commented 9 years ago
I cannot reproduce this bug. I just tested qz-print-free 1.7.6 and 
qz-print-premium 1.7.6 without issues.

OS Version:  Mac OSX 10.8.3
Java Version:  Java 7 Update 45 x64
Safari Version:  6.0.3 (8536.28.10)
Firefox Version:  25.0

-Tres

Original comment by tres.fin...@gmail.com on 9 Nov 2013 at 3:55

Attachments:

GoogleCodeExporter commented 9 years ago
Hi Tres,

I believe I misread the initial bug filing, however this was an issue for me on 
Safari 7 (OS X Mavericks 10.9). That said, the solution I posted for that setup 
worked for me. 

Original comment by m...@shust.com on 9 Nov 2013 at 7:17

GoogleCodeExporter commented 9 years ago
I will upgrade to Mavericks and try again.

Original comment by tres.fin...@gmail.com on 9 Nov 2013 at 8:15

GoogleCodeExporter commented 9 years ago
OS Version: 10.8.5
Java Version: 7u45
Safari Version: 6.1
Firefox Version: 25.0

After resetting Safari, I no longer get the error - I'm using virtual printers 
so I can't tell if it actually worked, but I'm definitely no longer getting the 
error anymore. Thanks for the tip!

Original comment by firewing...@gmail.com on 11 Nov 2013 at 4:01

GoogleCodeExporter commented 9 years ago
I just tested this on an *upgrade* to Mavericks and it seemed to work just fine 
without any additional changes.

I'll try a *fresh install* of Mavericks shortly.

Original comment by tres.fin...@gmail.com on 11 Nov 2013 at 5:16

GoogleCodeExporter commented 9 years ago
Hi Tres, I think this one is already resolved with the "allow always" fix

Original comment by m...@shust.com on 11 Nov 2013 at 5:28

GoogleCodeExporter commented 9 years ago
@Mark,

Thanks.  I didn't need this setting, which is why I'd like a baseline for 
comparison.  The Upgrade may have enabled this for me, since Java was 
previously working prior to the upgrade.

-Tres

Original comment by tres.fin...@gmail.com on 11 Nov 2013 at 6:56

GoogleCodeExporter commented 9 years ago
After a perfectly working Mavericks installation, this issue cropped up for me 
today.

I selected "Allow Unsafe" mode and it had the same affect.

Apparently Apple doesn't Trust Oracle's version of Java by default.

This is inconvenient because it forces every single client to change Safari's 
default settings in order to print.

-Tres

Original comment by tres.fin...@gmail.com on 13 Nov 2013 at 5:53

Attachments:

GoogleCodeExporter commented 9 years ago
Very inconvenient. Unfortunately I don't think there is any workaround for this 
as this is on the browser/os level.

Original comment by m...@shust.com on 13 Nov 2013 at 6:02

GoogleCodeExporter commented 9 years ago
Issue 179 has been merged into this issue.

Original comment by tres.fin...@gmail.com on 13 Nov 2013 at 1:40

GoogleCodeExporter commented 9 years ago
Resolution:

1. Go to Safari > Preferences > Security > Manage Website Settings
2. Click Java in left hand panel, and select site to allow jZebra/Qzprint, and 
set it to Allow Always.

If that does not correct the issue, Safari > Reset Safari > Check All > Reset.

A note about this has been added to the project home page as well as the 
README.txt.

-Tres

Original comment by tres.fin...@gmail.com on 13 Nov 2013 at 1:44

GoogleCodeExporter commented 9 years ago
Hi,

We just upgraded today our Mac to the latest version.
And we ran into the issue

Java: latest version 7.u45
Safari: 7
OS X: 10.9
qz-print: (free) 1.7.7

I tried both having the CA added to the Java Cert Storage and without.

On Safari:
- Did the "Trust Always", restarted browser.
The "/usr/bin/lpr": error=1, Operation not permitted" came
- Reset browser and restart, didn't help

On Firefox (25): works with exceptions
- The same errors are shown in the java console "/usr/bin/lpr": error=1, 
Operation not permitted", but afterwards it prints anyway.

Our workaround is that we just use Firefox but not sure if the issue has been 
resolved.

Not sure if I did something wrong during setup.

Leo

Original comment by serv...@thebouqs.com on 14 Nov 2013 at 4:29

GoogleCodeExporter commented 9 years ago
Leo,

Do you have a "Unsecure" option?  Terrible name, but that was the option that I 
actually selected.

-Tres

Original comment by tres.fin...@gmail.com on 14 Nov 2013 at 4:53

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Tres,

We are having the exact same issue mentioned by others on the latest Safari 
(7.x), OSX (10.9.x) and latest Java (7u55). 

Cannot run program "/usr/bin/lpr": error=1, Operation not permitted

The same also occurs with our own print applet, so it seems it is related to 
the applet permissions with latest Safari and OSX. I am not clear form the 
thread above whether you have solved this issue. If so, can you list the steps 
needed to resolve the issue. It works fine on latest FF with the same version 
of OSX/Java.

Aloke

Original comment by aloken...@gmail.com on 25 Apr 2014 at 8:41

GoogleCodeExporter commented 9 years ago
> I am not clear form the thread above whether you have solved this issue.

This bug report is closed, so yes this specific bug has been resolved.

I noticed despite setting "Allow Always", the Safari update blocks the plugin 
again.  Just go through the process a second time.  This should be in Apple's 
bug reports as they are intentionally breaking Java with their web browser 
(illustrated by the fact that Firefox has no issues).

If you do want to open a new bug please do it here:
https://github.com/qzindustries/qz-print/issues/new

I've tested qz-print 1.8.0 on Safari 7.0.3 on OS X 10.9.2 and it works after 
toggling off and back on the plugin settings.

Java 7u55 introduces a new dialog (pictured below) but that is unrelated to 
this bug.

Original comment by tres.fin...@gmail.com on 25 Apr 2014 at 2:02

Attachments: