Failed to publish a dataset with a DataCite test account

71 views
Skip to first unread message

edwin law

unread,
Jun 27, 2025, 7:43:39 AM6/27/25
to Dataverse Users Community
Hi everyone

We have created the following dataset.
Dataset.png

However, the following error message was received when attempting to publish a dataset.
Publish error msg.png

The server log shows the errors below.

server log_1.png
server log_2.png

Is it related to the DataCite DOI mis-configuration?
DataCite config.png

Many thanks!

Regards
Edwin


James Myers

unread,
Jun 27, 2025, 12:13:39 PM6/27/25
to dataverse...@googlegroups.com

Edwin,

You didn’t say what version of Dataverse you’re using but it appears to be fairly old. Knowing the specific version might help in diagnosing the issue. That said, I don’t immediately see a problem with the settings you show. (If you’re on a new enough Dataverse version, there are newer ways to configure PID providers you could try.)

 

FWIW: The fact that you see a DOI Not Reserved message means there was an earlier error when creating the dataset – the call to reserve the DOI with DataCIte at that point failed.

 

Things that might affect you:

- if you are using credentials or authority/shoulder from a real DataCite account with the test DataCite server, or vice versa

- if you created the Dataset before DataCite was configured correctly, or there was a temporary outage (recent Dataverse versions should handle this and just request a DOI at publication time if one wasn’t reserved earlier, but I’m not sure if earlier versions handled this case.)

 

Things you could try:

- Create a new dataset and debug any issue with reserving the DOI. If that works, presumably you can publish it as well (and the problem with the existing dataset may be my second idea above)

- Look in Fabrica and see if your DOI exists. If not you could try creating it manually there. Alternately, try creating a new dataset and verify that the DOI is visible in Fabrica (it won’t be public, but it should appear in Fabrica).

- Try using you credentials directly with the DataCite API. (Given that you’re getting a 404 response rather than a 403 forbidden suggests your credentials are OK, but making the call directly might show you more info and/or give you a simple case to show to DataCIte.)

 

Hope that helps,

-- Jim

 

From: dataverse...@googlegroups.com <dataverse...@googlegroups.com> On Behalf Of edwin law
Sent: Thursday, June 26, 2025 11:34 PM
To: Dataverse Users Community <dataverse...@googlegroups.com>
Subject: [Dataverse-Users] Failed to publish a dataset with a DataCite test account

 

Hi everyone

 

We have created the following dataset.

 

However, the following error message was received when attempting to publish a dataset.

 

The server log shows the errors below.

 

 

Is it related to the DataCite DOI mis-configuration?

 

Many thanks!

 

Regards

Edwin

 

 

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/925da8ea-06f7-459d-ac39-3d80603096bdn%40googlegroups.com.

MM - ADA

unread,
Jul 1, 2025, 9:17:36 PM7/1/25
to Dataverse Users Community
Hi Edwin - The Australian Data Archive mints DOIs with Datacite.

1. If your doi prefix of 10.83337 has been issued to you as a test doi prefix, and you can log into https://doi.test.datacite.org/ with it (and password), your configuration should not include a "shoulder" (ie. "FK2"). 
That setting should be deleted from your dataverse config parameters (as seen in the dataverse "Setting" table ) - I believe the dataverse documentation for your dataverse version details how to delete config parameters.

2. Once you have deleted the shoulder, you should see these config parameters in the Setting table (set them as necessary following the dataverse documentation):

:Protocol => doi
:DoiSeparator => /
:DoiProvider => DataCite
:Authority => <your datacite-issued test doi prefix> 

(there should be no :Shoulder entry)


3.These are the domain.xml config parameters for our test dataverse instance (v. 6.6 build 1829-192cdc4) using our test datacite parameters (your dataverse version may have different config parameters):

<system-property name="dataverse.pid.providers" value="datacite"></system-property>
<system-property name="dataverse.pid.default-provider" value="datacite"></system-property>
<system-property name="dataverse.pid.datacite.datacite.mds-api-url" value="https://mds.test.datacite.org"></system-property>
<system-property name="dataverse.pid.datacite.datacite.rest-api-url" value="https://api.test.datacite.org"></system-property>
<system-property name="dataverse.pid.datacite.datacite.username" value="<your datacite-issued username for fabrica test>"></system-property>
<system-property name="dataverse.pid.datacite.datacite.password" value="<your datacite-issued password for fabrica test>"></system-property>
<system-property name="dataverse.pid.datacite.type" value="datacite"></system-property>
<system-property name="dataverse.pid.datacite.label" value="datacite"></system-property>
<system-property name="dataverse.pid.datacite.authority" value="<your datacite-issued test doi prefix for fabrica test>"></system-property> 

There should be no reference to "FK2"...


Deleting the shoulder and configuring as above may not resolve your problems completely if any of the scenarios in Jim's response apply (so please follow his sage advice on how to diagnose if deleting the shoulder doesn't fix the problem).

I hope that helps.

Marina (Technical Manager at ada.edu.au)

edwin law

unread,
Jul 1, 2025, 9:34:41 PM7/1/25
to Dataverse Users Community
Hi Jim

Many thanks for your suggested solutions. Our current dataverse version is 6.0. 

You are right. We finally realized that the reason for failure in DOI registration is that the DataCite credentials were not properly configured. After modifying the username and password in the domain.xml (/usr/local/payara6/glassfish/domains/domain1/config/domain.xml) and restarting the GlassFish server, the DOI registration can be done successfully.

Cheers
Edwin
Screenshot 2025-07-02 093303.png
Screenshot 2025-07-02 093414.png
Screenshot 2025-07-02 093117.png

edwin law

unread,
Jul 1, 2025, 9:40:34 PM7/1/25
to Dataverse Users Community
Hi Marina

Many thanks for your detailed solution. Yes, the DOI registration works well now after removing the shoulder "FK2" and modifying the domain.xml file accordingly.

Cheers
Edwin

James Myers

unread,
Jul 2, 2025, 7:23:37 AM7/2/25
to dataverse...@googlegroups.com

Edwin,

 

Glad it’s working.

 

In case it helps you/others: w.r.t. having a shoulder, “FK2/” is definitely a legacy value, but you should be able to use it, or any one you want, as long as it’s allowed for your account. If your DataCite credentials allow you to mint any DOIs under your authority, you don’t need one at all like Marina says. However, I think there are places either where the shoulder(s) you can use is constrained by DataCite, or where an institution may use those credentials in more than one application where shoulders are assigned/used to avoid potential conflicts between apps/make it clearer which DOI comes from which app. (Dataverse does check with DataCite for collisions so it should not mint DOIs that are already in use regardless of whether another app uses the same authority/shoulder or not.)

 

Note that when changing shoulders, you need to account for any existing DOIs. With only one DOI provider (with a given authority/shoulder combo) configured, removing a shoulder should be OK – all DOIs minted with the shoulder can still be managed by the provider. However, if you add/change a shoulder, DOIs that don’t have the new shoulder won’t be manageable any more (can’t be updated/published in Dataverse). One could add a second provider (with no shoulder/the old shoulder, only assigned to the legacy datasets) to handle DOIs w/o the new shoulder, or add a list of allowed DOIs without the shoulder to your provider config (if there aren’t too many), etc. In general, it’s best to get your authority/shoulder strategy set before production to avoid all of this.

edwin law

unread,
Jul 7, 2025, 9:57:45 PM7/7/25
to Dataverse Users Community
Hi Jim

Thanks for your useful tips about the shoulder configuration.

Regards
Edwin
Reply all
Reply to author
Forward
0 new messages