This happened while I was consolidating the s3 buckets for test.dataverse.ucla.edu.
The collection for geospatial gets a 500 and I can't seem to find a way to fix it.
https://test.dataverse.ucla.edu/dataverse/geospatial
Sort of remaking the collection, is there any way to fix a broken connection link.
The alias exists:
dvndb=# SELECT alias FROM dataverse WHERE alias = 'geospatial';
alias
geospatial
(1 row)
ELECT d.id, d.alias, o.dtype, o.owner_id
dvndb-# FROM dataverse d, dvobject o
dvndb-# WHERE d.id = o.id AND d.alias = 'geospatial';
id | alias | dtype | owner_id
------+------------+-----------+----------
4949 | geospatial | Dataverse | 1
(1 row)
If this wasn't the test system I guess one fix would be to recreate the dataset.
It seems that it is still physically there. I can view with the api:
**
curl "https://test.dataverse.ucla.edu/api/dataverses/geospatial"
{"status":"OK","data":{"id":4949,"alias":"geospatial","name":"Geospatial","affiliation":"University of California, Los Angeles","dataverseContacts":[{"displayOrder":0,"contactEmail":"datascience@ucla.edu"}],"permissionRoot":false,"dataverseType":"LABORATORY","ownerId":1,"creationDate":"2019-02-25T19:45:16Z","theme":{"id":1,"linkColor":"428BCA","textColor":"888888","backgroundColor":"FFFFFF"},"storageDriverLabel":"test-dataverse-oregon"}}(base)
**
@jamie jamison thanks for also cross-posting to https://groups.google.com/g/dataverse-community/c/4AdxU1w1M1w/m/YMQtL-qFAQAJ
I'm glad that https://test.dataverse.ucla.edu/api/dataverses/geospatial returns JSON cleanly.
@jamie jamison can you please go to https://test.dataverse.ucla.edu/dataverse/geospatial and grab the stacktrace from server.log? You can either paste it here or email it to support@dataverse.org
I'm attaching a test file - it's too long to past here
server-log.txt
~
~
Interesting. java.io.IOException: ERROR: S3AccessIO - You must create and configure a bucket before creating datasets
at edu.harvard.iq.dataverse.dataaccess.S3AccessIO.<init>(S3AccessIO.java:114) which for you is https://github.com/IQSS/dataverse/blob/v5.14/src/main/java/edu/harvard/iq/dataverse/dataaccess/S3AccessIO.java#L114
But the bucket is already there. I merged the old lariac (geospatial) bucket into the all-purpose test bucket, s3 test.dataverse.orgegon.
I must have missed a step. Everything with the merge worked on production
gotcha
well, one of these is true:
if (bucketName == null || !s3.doesBucketExistV2(bucketName))
Or can it be changed in postgres? I've gotten lots of practice with the database. One of you guys pointed me to a site that has all the tables.
sorry for the bad typing, I'm doing this in a meeting
ha, no worries
SchemaSpy. I'm glad you enjoy it! For your version: https://guides.dataverse.org/en/5.14/schemaspy/index.html
helps with troubleshooting
Other collections are fine?
yes, only the geospatial. I made an empty geospatial2 to try and see what's different
In postgres can you please compare storagedriver under this table? https://guides.dataverse.org/en/5.14/schemaspy/tables/dataverse.html
ok, may have to wait till meeting is done
dvndb=# SELECT id, alias, name, storagedriver
FROM dataverse
WHERE alias IN ('geospatial', 'geospatial2');
id | alias | name | storagedriver
------+-------------+-----------------+---------------
4949 | geospatial | Geospatial | s3
5669 | geospatial2 | Geospatial Test | s3
(2 rows)
still not working, I'm trying to find all the jvm options that mention s3
<system-property name="dataverse.db.port" value="5432"></system-property>
<system-property name="dataverse.files.storage-drivers" value="s3"></system-property>
<system-property name="dataverse.files.dataverse-test-oregon.type" value="s3"></system-property>
<system-property name="dataverse.files.dataverse-test-oregon.bucket" value="dataverse-test-oregon"></system-property>
<system-property name="dataverse.files.dataverse-test-oregon.region" value="us-west-2"></system-property>
<system-property name="dataverse.files.dataverse-test-oregon.download-redirect" value="true"></system-property>
<jvm-options>-Ddataverse.files.s3.url-expiration-minutes=120</jvm-options>
<jvm-options>-Ddataverse.files.s3.bucket-name=dataverse-test-oregon</jvm-options>
<jvm-options>-Ddataverse.files.storage-driver-id=s3</jvm-options>
<jvm-options>-Ddataverse.files.s3.type=s3</jvm-options>
<jvm-options>-Ddataverse.files.s3.region=us-west-2</jvm-options>
<jvm-options>-Ddataverse.files.s3.label=dataverse-test-oregon</jvm-options>
Fortunately it's the test system
4 messages were moved here from #troubleshooting > dvndb=# SELECT id, alias, name, storagedriver FROM dataverse by Philip Durbin ๐.
The stacktrace is similar, thanks.
This probably isn't worth taking too much of your time. Though I would like to know how I broke it , if that was the case and if so how to fix.
Sure. You said everything is ok in production, right?
Yes, production is ok, other than being behind in 5.14
phew
Time to rebuild the test server based on the latest in production. :sweat_smile:
I'd rather do that. Tim is working on an ansible script to install dataverse and update the database
Just as an experiment, I'm copying over metadata from collection geospatial (the broken one) to geospatial2.
Last updated: May 30 2026 at 09:11 UTC