Error uploading pdf image

Skip to first unread message

jesus san miguel

Oct 30, 2020, 2:25:45 PM10/30/20
to AtoM Users
Hi all,

I have an error in two different servers running AtoM 2.5.3-172 when I upload a PDF image through the GUI.
The error ends being NULL digital_object.path value:

This is from nginx.log:

2020/10/30 18:02:48 [error] 928#928: *577 FastCGI sent in stderr: "PHP message: Unable to execute INSERT statement. [wrapped: SQLSTATE[HY000]: General error: 1364 Field 'name' doesn't have a default value]" while reading response header from upstream, client:, server: _, request: "POST /index.php/testing/object/addDigitalObject HTTP/1.1", upstream: "fastcgi://unix:/run/php7.2-fpm.atom.sock:", host: "", referrer: ""

And this is the database insert log:

2020-10-30T18:02:48.621153Z     4 Query INSERT INTO object (`CLASS_NAME`,`CREATED_AT`,`UPDATED_AT`) VALUES ('QubitDigitalObject','2020-10-30 11:02:48','2020-10-30 11:02:48')
2020-10-30T18:02:48.621513Z     4 Query INSERT INTO digital_object (`ID`,`OBJECT_ID`,`PATH`,`PARENT_ID`) VALUES (223394,223393,'',223392)
2020-10-30T18:02:48.622005Z     4 Query ROLLBACK

If I upload the digital object through the cli, it works as expected:

root@ubuntu18:/usr/share/nginx/atom# php symfony digitalobject:load --path="/root/" --index /root/niatiros.csv
>> digital-object Load digital objects from /root/niatiros.csv...
(Oct 30, 09:41:48 AM) Loading 'niatiros.pdf' (1 of 1 remaining)
>> digital-object Successfully Loaded 1 digital objects.


José Raddaoui

Nov 2, 2020, 10:56:23 AM11/2/20
to AtoM Users
Hi Jesús,

This is probably caused by having STRICT_TRANS_TABLES enabled in MySQL's sql_mode. We recently changed this section in the documentation (here for 2.5) to reflect the need of removing it and we have this ticket to support it in future versions, where I've added a note to this post.

Thanks for letting us know about this issue.

Best regards,

José Raddaoui

Nov 2, 2020, 11:48:41 AM11/2/20
to AtoM Users
Hi again Jesús,

Thinking it through, in a GUI upload the path shouldn't be null and, additionally, we addressed that issue in And, reading the error again, it looks like it's actually complaining about the 'name' column instead of the path. Not sure what could be causing an empty name in GUI uploads, maybe it's related to encoding, web server permissions, or the file path in the CSV.


jesus san miguel

Nov 2, 2020, 12:45:59 PM11/2/20
Hi Radda,

Let me exclude a bunch of maybes: If it is a JPG instead of a PDF, the
upload works smooth as silk, so, lets discard encoding, web server
permissions and the CSV file path, since this is a GUI upload. I tried
tweaking policies in imagemagik conf file, but so far I'm concerned
about the SQL insert failing. Why would path variable be empty when I
upload a PDF and have a value if I upload a JPG? Aren't they uploaded
in the same folder structure inside ./uploads/r/...?
> --
> You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> To view this discussion on the web visit

jesus san miguel

Nov 3, 2020, 5:36:49 AM11/3/20
Perhaps this might be of use to diagnose the error...

On Mon, Nov 2, 2020 at 5:48 PM José Raddaoui <> wrote:
General error_1364 Field 'name' doesn't have a default value.pdf

José Raddaoui

Nov 4, 2020, 12:09:57 PM11/4/20
to AtoM Users

Hi Jesús,

It looks like the issue happens with the digital object name, not the path and, seeing those logs, maybe it's the normal behavior in the PDF compound children (see setting docs). So it could be STRICT_TRANS_TABLE enabled in the sql_mode what is actually making it appear as an error instead of a warning. I'll give it a try locally and let you know how it goes.


jesus san miguel

Nov 6, 2020, 5:59:28 AM11/6/20
Yes, you were right on the spot! Removing STRICT_TRANS_TABLE in
/etc/mysql/conf.d/mysql.cnf did finally the trick.

Don't forget enable read on /etc/ImageMagick-6/policy.xml

<policy domain="coder" rights="read" pattern="PDF" />

> To view this discussion on the web visit

José Raddaoui

Nov 6, 2020, 12:28:20 PM11/6/20
to AtoM Users
Good news Jesús, thanks for reporting back!

Danilo Muñoz

Dec 11, 2023, 8:13:11 AM12/11/23
to AtoM Users
Hi everyone, have a good day.
i have the same problem, i change my mysql.conf and policy.xml but the site dont found the thumbnails

my site

the process
php symfony csv:import /home/administrator/AFA_RS-afa.csv
php symfony search:populate
php symfony cc
service nginx restart
service php7.4-fpm restart

the results:
pdf ok 
preview lost
jpg created

the strange thing? does not show any error
I hope you can help me


pd: I also tried to regenerate, but it didn't help either. 
sudo -u www-data php symfony digitalobject:regen-derivatives

Dan Gillean

Dec 11, 2023, 9:41:16 AM12/11/23
Hi Danilo, 

Apologies in advance for the repetition, but I will walk through the normal steps we recommend to resolve this issue below in order, just to double-check that you have completed all the suggested steps in the correct sequence. Based on the commands that you shared in your post, I am assuming you have a 2.7 installation - if not, be sure to check the correct version of the user manual for your current AtoM version, as some instructions (like how to restart PHP-FPM) may be different.  

If I am understanding correctly, you are saying you have already made the recommended change in the Ghostscript policy.xml file described in this thread?
And you have double-checked the SQL modes applied, per these instructions? 
In AtoM 2.7, the only SQLmodes that should be set are: ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION. If they are not, then the link above should tell you how to change them. 

If yes - did you remember to restart MySQL after making SQL mode changes?
  • sudo systemctl restart mysql

Let's also make sure that the filesystem permissions are set properly as AtoM expects: 
If you have checked and confirmed that both of the files above are updated correctly and that the permissions are properly set, then now you could try regenerating derivatives. We can run it more quickly by limiting it to just text files (i.e. PDFs), like so: 
After that and BEFORE testing would be the time to clear the application cache and restart PHP-FPM - it's possible if you test before doing this that you are still seeing an older cached version of the page: 
Remember as well that your web browser also has its own cache, so you might want to clear this before re-testing, or test in a private / incognito browser window, where the cache is typically disabled by default. 

If that still doesn't work, then now would be a good time for us to gather additional information. 
  • What is the full version number shown in Admin > Settings?
  • Have you upgraded recently? If yes, did you follow Option 1 (download the tarball from our website) or Option 2 (install from our GitHub code repository)?
  •  Does your site have any local customizations or code changes in place, including a custom theme plugin?
  • Is this affecting ALL PDFs, or just some of them? 
  • Do you have any PREMIS rights applied to the affected descriptions?
  • Anything else we should know about your installation?

Hopefully with more information, we can provide further suggestions. 


Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
he / him

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Danilo Muñoz

Dec 15, 2023, 10:39:52 AM12/15/23
to AtoM Users
Thank you very much for your great help Dan. In the end, I rebuilt the server and installed the GIT version, corrected the policy and everything worked perfectly.
Reply all
Reply to author
0 new messages