The folder permission must be 755. The file wkhtmltopdf .exe 744. You may have more than one wkhtmltopdf.exe file depending the OS. Verify this inside the wkhtmltopdf folder.
Some hostings blocks all files if you put 777 permissions.
Configure your production invironment PDF Server IP
As I told you some hostings blocked the execution of this files. You must ask them.
Bye.
The server admin at the site which WILL export even with https said:
The internal URLs that called the wkhtmltopdf executable didn’t work through HTTPS. So I configured Apache to allow HTTP requests that originate from the same system.
The other issue I found was a mismatch between the version of OpenSSL utilized by wkhtmltotpdf and the version that was installed on the server.
If wkhtmltopdf writes files within the html root, then that folder would need to be owned by the Apache process, and the “httpd_unified” SELinux boolean would need to be enabled. I just checked, and the /system/_lib/prod/third/wkhtmltopdf/linux-amd64 folder is owned by apache, and the “httpd_unified” SELinux boolean is enabled.
I checked ownership of the wkhtmtopdf folder and contents, and it’s the account user, not the Apache process. Does that jive with your experience?
Thank you again. I’ll try changing the permissions as you suggest. Yes, some hosts will not like permissions set at 777 for a file. AFAIK, this is not an issue with my host. But I can check that out, too.
When you say “Configure your production environments PDF Server IP” - what do you put in yours? The root URL to the website or to the deployment of your project? Or the path in the server files? Or something else? When I first saw that field I put the actual IP address - you’d think that’s what should be put there - but that doesn’t work, does it!
My experience is a bit different. I run my own servers and my customers log onto them. I also do not use Apache for security reasons, I use Nginx. All of my folders are owned and grouped within www-data which is the web servers account. I chmod wkhtmltopdf and /tmp as 777. I have configured the server to allow a non-secure connection but that did not get the job done. The only thing that works is a path from the root of the server to the actual html file that is generated.
If Scriptcase would just make a minor adjustment in the command file that they run to pass the grid to wkhtmltopdf the problem would be totally solved and would work on any server. For some reason fixing past bugs is not something that they seem to do. I have been in communication with them many times and they just let things time out on the support site.
Thanks a lot. I agree with you - support is lousy if you can even get it. I paid once and vowed never again. I won’t bug you anymore. I appreciate your input.
Please bug me if you find an answer to this problem. I will do the same back to you.
You can put the IP of your domain or www.yoursite.com
I have over 30 Scriptcase apps in different hostings. In some it doesn’t work because security issues, in others works fine and others I must send a message to the support to enable the wkhtmltopdf.exe in that site. Sorry for my English.
Most definitely! Thanks again!
Your English is way better than my [insert your language here]! I tried the permissions settings you suggested and still no joy. Also, putting the IP (as in IP address) didn’t help, but perhaps that’s because there are other issues. But I’m still working on it and security is what I’m checking out next. You’ve been a big help.
I remember that sometimes I upload the file again alone and then put the 744 permission again.
Hi guys…I have the same problem a year ago…with 9.4 and 9.5 versions…and I have tried all what you have commented…but seams that Scriptcase doesn’t matter about this issue…
Any new idea for solving this head ache…?
Regards
Sergio C.
Still no solution to this. I’ve tried everything above. Finally, with some help from SC support (through the bugs@scriptcase.net) I’ve found that there is a missing library on my server, which runs Centos 7 64 bit Linux.
Running the command in the terminal which appears in the log file after attempting an export yields the following error:
error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory
Now I’m trying to figure out how to get that installed on the server. I’m not a server admin so if anybody can point me to the instructions, that would be very helpful.
I had the same problem and started with the Journey
Note: These files get overwritten ever time you do a full Deployment to the server, so keep copies.
Someone else finally got this solved. Here is a link to that discussion -
@Paul_Van_Geel
Have you followed the steps in the previous post and made sure that the security settings are correct?
Yes. I had tried to chmod 777 on the directory for the wkhtmltopdf, but it did not work. The solution in the referenced discussion did. The only problem is that when you update the deployment the file gets overwritten, and you need to reinstall the proper files again. That stated I created a script to do the work for me each time I update the deployments of my programming.
Here is the script that I wrote. Modified it a bit for others to use. This was written for Ubuntu Linux and should work for any Debian varieties. I also have root access since I run the server.
cd /var/www/html/<your directory>/_lib/prod/third/wkhtmltopdf/linux-amd64
sudo cp /usr/local/bin/wkhtmltopdf wkhtmltopdf-amd64
sudo chmod -R 777 /var/www/html/<your directory>/_lib/prod/third/wkhtmltopdf
Of course the <your directory> will need to be modified. Chmod this to 755 and chown it to root:root. I named the file “htmltopdf” Then when you run it use the command -
sudo ./htmltopdf
This will get the wkhtmlpdf file into the correct area to solve the problem with pdfs from grids. These instructions do assume that you have already installed the newer version of wkhtmlpdf from the git repository. If not see the discussion that was already referenced here.