You need to chmod the tmp directory to 777
Thank you but the dir is already setted to 777.
And the problem is only seen on pdf exports.
Excel, Word, and others works well.
Sound like your wkhtmlopdf is not the latest on your deployement platform
I don’t remember how to update it, but the link to get it is: wkhtmlopdf
Binaries on my linux directly comes from the scriptcase dev environnement _lib.
Do you suggest that the scripcase package works on windows but don’t work on linux if the wkhtmltopdf has not been updated ?
That’s the way I fix the same problem a few month ago
Thank you for your help, I first try the new v9.6.01 patch, and then if it doesn’t solved anything, I’ll start update the wkhtmltopdf linux package.
I already have a bug in 9.6.1
https://forum.scriptcase.net/t/rows-counter-doesnt-work-in-french-in-v9-6-001/27251
I just rollback to 9.6.0
Hi, @Laurent_Menard
We had several improvements regarding the PDF export in the new version: 9.6.001
Please, update your environment and verify if this issue was solved.
The problem is still there after the last 9.6.001 update.
So, I’m about to test the linux upgrade of wkhtmltopdf package.
About the french message rows counter.
I don’t have the problem with this last release :
The wkhtmltopdf problem is solved for me (I updated the package manually to 0.12.6.R1)
Thank you @jlboutin60 for your help.
The problem is due to the fact that i’m in https mode and the wkhtmltopdf embeded with scriptcase doesn’t work in ssl mode.
I download the 0.12.6.R1 binaries here :https://github.com/wkhtmltopdf/packaging/releases/0.12.6-1
Here are the commands that solved my situation. (I’m in ubuntu amd linux) :
wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-rc/wkhtmltox_0.12.6-0.20200605.30.rc.faa06fa.bionic_amd64.deb
apt install xfonts-75dpi
dpkg -i ./wkhtmltox_0.12.6-0.20200605.30.rc.faa06fa.bionic_amd64.deb
which wkhtmltopdf
cd /var/www/dechets/_lib/prod/third/wkhtmltopdf/linux-amd64
cp /usr/local/bin/wkhtmltopdf .
mv wkhtmltopdf-amd64 wkhtmltopdf-amd64.orig
mv wkhtmltopdf wkhtmltopdf-amd64
chmod 777 wkhtmltopdf-amd64
Now, i’m happy
3 Likes
Thank You!! Thank You!! Thank You!!
I have been working on this issue for a couple of years now. More than once I contacted support for help and got nowhere. I hope that this does not get written over with every update.
Thank you for posting this. I’m running Linux Centos 7.9 and used the following commands to install the latest release of wkhtmltopdf but the PDF export was still broken. Still get a 404 page even though the pdf is “being created” it’s not in the tmp directory. The HTML, CSS and LOG files are all there.
wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox-0.12.6-1.centos7.x86_64.rpm
sudo yum install ./wkhtmltox-0.12.6-1.centos7.x86_64.rpm
cd /home/MYSITE/public_html/APPS/_lib/prod/third/wkhtmltopdf/linux-amd64
cp /usr/local/bin/wkhtmltopdf /home/MYSITE/public_html/APPS/_lib/prod/third/wkhtmltopdf/linux-amd64
mv wkhtmltopdf-amd64 wkthmltopdf-amd64.orig
mv wkhtmltopdf wkhtmltopdf-amd64
chmod 777 wkhtmltopdf-amd64
And the file owner is set to root:root but that doesn’t matter, either. Still does not export a PDF.
CORRECTION: The PDF will be created if I take the contents of the log file and run it in terminal. But not through the GUI of the Export button on a grid.
1 Like
Hello, i’m not a Centos expert, but in order to focus on the source of your problem, can you tell me the content of your /etc/selinux/config ?
Is SELINUX=enforcing, permissive or disabled ?
Could you make a test with the disabled value, reboot and see if it’s better ?
Thank you - I tried that and still the export will not work through the GUI, only CLI. I’m talking with my server host now to see if they can help.
And they could not help or see why this function will not work except through the CLI. I’m putting SEL back to permissive which is where it was set before.
Very strange.
Are you in http or https case ?
Could you post the content of the log file generated in the tmp directory.
Could you confirm that the tmp dir is in the 777 configuration like this under web_site/_lib :
In order to close the apache bad configuration case, could you confirm that, if you exec manually the command in the log file, the file is generated in the tmp dir and in a second time ould you confirm that the 404 errror disapears.
If the 404 is still there, the problem is located in the apache conf file. (The url is not correctly link to the good directory or apache user_id or user_group is not allowed to acces or read the tmp diretory).
There is a Scriptcase article about this that I was pointed to by the support team:
Thank you. I’ve tried this solution before, many times. I usually can get it to work on the command line but not through the Export button of the grid. This time, I could not get “Export to PDF” to work through the app but AFTER I did it through the command line, and then went back to the app, it WOULD WORK. Only after first doing it through the command line FIRST would it work in the app. Very strange. An OWNER issue, perhaps?
At last!!
Thanks a lot…
I’ve been looking at this issue ever since I changed to a new hosting company for my VPS in September 2020. At that point, every SC project I deployed (about 20 of them) had a broken PDF export function. I’ve hired server admins to help to no avail. Nothing I did would make wkhtmltopdf work.
Finally, I pieced together what was going on after a server admin explained something to me about permissions, the PHP-FPM service (which I use on all my SC deployments) and some functions like exec, shell, system and passthrough.
On my server, exec is disabled in PHP-FPM by default. Once I enabled it for the domain which hosted the SC deployed project, and changed the appropriate wkhtmltopdf.exec file permission to 0744 (adding execute to the user group) PDF export worked once again.
I don’t know if any of you who are running your own VPS on Centos 7.9 with PHP-FPM know this or have had this issue like I have, but if so, I hope this helps. I’m not a server admin; I know enough to manage the sites I host and that’s about it. This never occurred to me but I did think this issue, which has been a problem for almost 3 years, had something to do with permissions (partially correct). I had no idea that exec was disabled by default. Obviously, I should have known this.