I'm on a server where docker is disallowed for security reasons. Has anyone had success in using podman to quickstart dataverse instead?
I can see the "Hello from Payara - your server is now running!" page and sign in to the Administration Console but I don't see a document root with an index.html file or a place to sign in with the dataverseAdmin account.
Hmm, @Don Sizemore looked into this in #9731 but I'm not sure what the latest is.
yes, that was where I broke down. has it really been 3 years?
@Renee L. do you get the same error as in that issue? Error: unknown flag: --driver
I don't see that error.
gotcha
@Don Sizemore we have a somewhat related initiative over at #containers > Docker mode when spinning up EC2 instances
Do you think that within "docker mode" we should allow for either docker or podman?
Needed to make a bunch of changes to the compose.yml file (mostly commenting things out) but eventually "podman compose up" seemed to be working. I just don't see a way to log in as dataverseAdmin, publish the root collection, create a collection etc.
Yeah, if you're only see the Payara screen it means the Dataverse war file has not been deployed.
And I'm sure http://localhost:8080/api/info/version doesn't work either. When Dataverse is properly deployed, it will show the version.
@Renee L. anything interesting in the logs for the dataverse container?
http://localhost:8080/api/info/version says: {"status":"OK","data":{"version":"6.10.1","build":null}}
Oh! That's promising!
What if you refresh your browser? Sometimes the UI take a bit to come up.
Mostly the dataverse container log says:
[#|2026-06-22T13:49:49.422+0000|SEVERE|Payara 7.2026.2|org.glassfish.admingui|_ThreadID=9122;_ThreadName=admin-thread-pool::admin-listener(5);_TimeMillis=178
2136189422;_LevelValue=1000;|
Β RestResponse.getResponse() gives FAILURE. Β endpoint = 'https://localhost:4848/management/domain/_list-resources'; attrs = '{appname=dataverse, modulename=m
icroprofile-openapi-servlet}'|#]
over and over. And I've already waited over the weekend. so I don't think waiting longer will help.
I do greatly appreciate the quick response here.
OMG I just shift-refreshed and the page just changed.
That's great! What did you need to change in the compose file to get it to work? Do you want to make a pull request?!?
Here's the version of compose.yml for podman. And I'd be happy to make a pull request. Would that be for https://github.com/gdcc/container-test or a different repository?
docker/compose/demo/compose.yml is the file in the main repo to edit.
As of 6.10.1 it looked like this: https://github.com/IQSS/dataverse/blob/v6.10.1/docker/compose/demo/compose.yml
So, yes! Please make a pull request! :heart:
@Renee L. oh, and please use #9731 in the name of your branch. 9731-podman or whatever. (Or feel free to create a fresh issue for this, if you like!)
Certainly. I am still testing this build. Site email is not working yet for example.
@Renee L. hi! The Containerization working group has monthly meetings and I just added podman to our agenda for next week: https://docs.google.com/document/d/1hWKp9mk3KLx0c54HUCsJqHssV1ol66F-samectJ-6Ss/edit?usp=sharing
If you're able to make it, fantastic! We could even probably reschedule, if necessary!
I can be there (virtually). May I also invite my 2 colleagues who helped with this?
Absolutely! The more the merrier! :tada:
Here's the topic where we coordinate that meeting: #containers > meetings
I downloaded the podman dmg for Mac. Wish me luck!
Meanwhile over at #containers > Docker mode when spinning up EC2 instances @Ash Manda said he doesn't mind adding podman support.
I know you said you're using podman on a server, @Renee L.
Sure enough (I'm testing on develop, not your new PR #12513):
β Container smtp Β Β Β Β Β Β Β Β Β Β Error response from daemon: container create: unknown mount option "uid=1000": invalid mount option 0.0s
We definitely want these changes:
diff --git a/docker/compose/demo/compose.yml b/docker/compose/demo/compose.yml
index 779cf37a93..d4b24f7fb1 100644
--- a/docker/compose/demo/compose.yml
+++ b/docker/compose/demo/compose.yml
@@ -42,8 +42,8 @@ services:
- ./data/app/data:/dv
- ./data/app/secrets:/secrets
tmpfs:
- - /dumps:mode=770,size=2052M,uid=1000,gid=1000
- - /tmp:mode=770,size=2052M,uid=1000,gid=1000
+ - /dumps:mode=770,size=2052M
+ - /tmp:mode=770,size=2052M
mem_limit: 2147483648 # 2 GiB
mem_reservation: 1024m
privileged: false
@@ -169,7 +169,7 @@ services:
#volumes:
# - ./data/smtp/data:/mail
tmpfs:
- - /mail:mode=770,size=128M,uid=1000,gid=1000
+ - /mail:mode=770,size=128M
Getting rid of uid=1000,gid=1000, I mean, as discussed in the last container meeting.
@Oliver Bertuch in #12513 @Renee L. has commented out these lines from the "dataverse" container:
tmpfs:
- /dumps:mode=770,size=2052M
- /tmp:mode=770,size=2052M
However, I seem to recall you saying we should keep them in some form.
This is the error I'm getting with them in:
dataverse | [Entrypoint] running /opt/payara/scripts/init_2_configure.sh
dataverse | mktemp: failed to create file via template β/tmp/tmp.XXXXXXXXXXβ: Permission denied
Any ideas for me?
This is what Claude is telling me:
![]()
Oh good, it works.
That is, podman compose up works for me with this change (again, from develop):
diff --git a/docker/compose/demo/compose.yml b/docker/compose/demo/compose.yml
index 779cf37a93..8b41e40861 100644
--- a/docker/compose/demo/compose.yml
+++ b/docker/compose/demo/compose.yml
@@ -42,8 +42,8 @@ services:
- ./data/app/data:/dv
- ./data/app/secrets:/secrets
tmpfs:
- - /dumps:mode=770,size=2052M,uid=1000,gid=1000
- - /tmp:mode=770,size=2052M,uid=1000,gid=1000
+ - /dumps:mode=1777,size=2052M
+ - /tmp:mode=1777,size=2052M
mem_limit: 2147483648 # 2 GiB
mem_reservation: 1024m
privileged: false
@@ -169,7 +169,7 @@ services:
#volumes:
# - ./data/smtp/data:/mail
tmpfs:
- - /mail:mode=770,size=128M,uid=1000,gid=1000
+ - /mail:mode=1777,size=128M
I'm just not sure if I should be scared of that mode=1777. I'm always scared of chmod 777. :scream:
"1777 reminds me of 777 which I've always heard is poor security" -- me
"Fair instinct β 777/1777 on a real filesystem is usually a red flag because it lets any user read/write/delete anyone else's files. Here the risk profile is different:
So mode=1777 here is the same trust model as your OS's real /tmp, not an open-permissions container image or host mount. If you wanted tighter isolation you could restrict it to mode=1770 and have the container's entrypoint chown /tmp to the payara uid at startup β but that requires editing the image/entrypoint, not just the compose file. For this demo compose setup, 1777 is a reasonable, standard tradeoff.
β» SautΓ©ed for 9s" -- Claude
I'm seeing $ podman create -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image at https://docs.podman.io/en/stable/markdown/podman-create.1.html which makes me feel better.
Wow if it takes this much effort to make it work with podman, I'm not sure we'll be able to support it on Ansible. I was under the impression that just exchanging them will work because that's how I usually use it.
thank you for doing this
@Ash Manda well, is a pretty small diff, right?
@Renee L. I made a pull request into your pull request: https://github.com/rdlebeau/dataverse/pull/1
I hope it makes sense!
@Renee L. my thought process was to get the diff down to smallest possible diff first.
@Renee L. I added the "needs input" label. Please let me know what you think about my proposed changes. Thanks! :smile:
@Philip Durbin π I merged your pull request.
@Renee L. wonderful! Thanks! Next up, what additional changes do we need? :sweat_smile:
Again, I'm testing on a Mac so I might be seeing different behavior that what you're seeing on Linux. :grimacing:
#12513 is now in a state where I'm happy to merge it.
Would multiple small PRs be ok with you?
That's fine by me.
I've made the dataverse container tmpfs changes (mode=1777, removing uid=1000,gid=1000) and they work on our test server, but we have an SMTP server that uses the university mail relay service so I have commented out the entire smtp section of compose.yml.
I don't think that answers any of your questions but I wanted to give an update.
Merged!
Yeah, maybe we should have a separate topic here in Zulip about that SMTP server. It makes sense in dev but probably not for a demo.
It doesn't have much to do with Podman, I mean.
Hello, I have created an issue to extend this PR to dev environment here. The only change we need to make is to bind SMTP server on a port > 1024 on host to avoid using privileged port. It worked like a charm on my Linux workstation. Would there be any interest if I put up a PR?
@Mahendra Paipuri yes, please! And that's for your other PR! We talked about it yesterday during Triage Tuesday.
Cheers @Philip Durbin π !! I ll do it over this weekend!
@Mahendra Paipuri thanks for creating #12566! We just talked about it during Triage Tuesday and moved it to "ready for review" on our board. I also added it to the agenda for the next Containerization working group meeting. Would you like to join to talk about it?
Hello @Philip Durbin π Yes, I can join the meeting to talk!! Its on August 6th, right?
@Mahendra Paipuri yes, exactly! I'm glad you can make it! You can check #containers > meetings for any last minute changes but usually we meet when we say we will. :smile:
Sure, I ll do that! Cheers!!
You can update the solr schema using podman instead of docker with the command:
curl [website url]/api/admin/index/solr/schema | podman run -i --rm -v ./data/solr/data:/var/solr gdcc/configbaker:unstable update-fields.sh /var/solr/data/collection1/conf/schema.xml
where [website url] is your site's url, not 'http://localhost:8080'. This command is run outside of the containers.
good point
Our dataverse test server is running nginx rather than Apache and using podman.Β I want to install Shibboleth.Β But the official dataverse instructions seem to be intended for Apache without containers.Β Can anyone tell me what my next steps should be?
Last updated: Aug 18 2026 at 08:27 UTC