I freshly created documents PDFs. I then left the first one “as is” (it gets perms 604) while I chmoded the second one to 755 and the third one to 775.
I then ran getfacl on them (please check the attachment).
I also included the output of the same command on the folder where the all suite is installed and on the upload folder where the pdf files are located.
As you can see it seems group permission are set to — by the server’s ACL. which could be part of an explanation for why it doesn’t work or is it ?
I think the ACL explains why the file gets 604 permissions. But it doesn’t explain why the server doesn’t serve it. If your web server is running as omegatrawf/users, it should be allowed read/write access even with 604.
Can you now please go back and check the two questions on my post before the last one? htaccess is probably the culprit, though I’m not sure you can change it without talking to your hosting provider.
I’m really puzzled. When I read your post I thought, “stupid me, obviously SuiteCRM won’t let you directly pick up a file from the upload directory, you need to go through one of the php entrypoints”. But I just tried uploading a new PDF on my system (it got 422 permissions, by the way) and I could download t from the browser with direct URL (http://www.mysite.com/upload/d391f543-84c3-a58e-f352-5899ca25657e). So much for security.
This might be the time to contact your hosting provider. With all the information you have gathered, you can be very specific and just ask them why the web server gives a 403 on the file with id ending in d3666f, when it should have read access. I’m sure they will be able to track that down easily.
(as a side note, I think you might one day need to increase those two configurations php_value max_input_time 60 and php_value max_execution_time 60, these are sometimes insufficient when uploading big upgrade files and performing the upgrades).
If I take this route, (obviously changing the “mysite.com” with the real thing on my side), I get an error I had never seen before (it’s evne in French !) : “Erreur de récupération de l’enregistrement. Cet enregistrement est peut être supprimé ou vous n’avez pas le droit de le visualiser.”
That is the ‘ERROR_NO_RECORD’ string in my language…
I’m just wondering how many people have the same issue as me and how many just decide to not go any further with suitecrm because of these type of issues…
Anyway, I’m not sure how OVH can help if SuiteCRM has its own way of setting up permissions. I’ll contact them though.
It’s a file that was generated by the system when I tried to generate a document from a template. (I don’t get a link but a file is generated in ‘./upload’)
This is the file that gets permission 604…
Anyway. this file is a pdf and if I retrieve it via my sftp client, I can open it as a pdf. So far, this is the only workaround I found for my postal mail needs.
1- I download all the files generated by the system (let’s say if I chose 150 leads, I’ll get 150 files) 2-I add a .pdf extension and merge them all together using a command line tool and 3-I print the resulting pdf document and voilà !
Obviously, I had rather step 1 and 2 were replaced with the CRM’s normal behaviour and I’m sure we’ll find a way !
Creating a document and uploading it works fine. Clicking on it to download it works fine as well. Yet, I can’t check permissions an ACL as I don’t know where it is stored. Not in the upload folder… Any idea where it is stored so I can check permissions and ACL ?
I found mine in the upload folder. I just do a “ls -trl” there to list everything in reverse chronological order, the most recent document comes up last.
What might be causing confusion - as if we didn’t need any more confusion : - ) - is that documents have an id, and then a list of revisions. Each revision gets it’s own id, and these are the ones that point to files in upload folder.
I’m not sure this test is going to help, anyway. Maybe we’ll just have to let this rest for a few days until one of us has some brilliant idea.
This makes it clear that your problem is not just with campaigns and letter generation from templates, every document attachment seems to be failing.
Definitely take this up with your hosting, this is a quite tested area of the application, it really should work. Sometimes hosting companies tighten their security in ways that break applications, and they need to be told about it, so they can fine-tune their settings.
1- I have no problem with docs and attachments as long as they’re accessed via SuiteCrm (eg : doc attached to a lead or a contact / pdf templates…), but I cannot access them directly via my web browser. As I understand it, this is a normal intended behaviour defined in SuiteCRM’s .htaccess.
2- My problem seems to come from the fact wrong permissions are given by some ACL at my webhost thus preventing documents to be processed correctly byt SuiteCRM. These documents are those which should normally be generated by SuiteCRM from any given PDF templates and for which I should get a link to download or a prompt with the download content.
The way I see it is that the CRM needs some minimum permissions to be able to complete the process. Apparently it gets stuck at some step where he should be able to retrieve data from the upload folder to be able to generate a link. As the permissions are set at a wrong value by my webhost through their ACL, the process is stopped at that stage.
Yeah, something like that. But I still don’t see why the read permissions for user are not enough. Maybe they have your apache running as another user (probably in the same group, but that doesn’t help because no permissions are given to the group).
