Dataverse: cannot upload file in container because of permissions issues

[thaorell]

This has been an issue for a while but I never brought it up. I am running Dataverse 4.9.1 on Fedora. After a container starts successfully, a user can create a new dataset but cannot upload any file.

Server.log spits out these errors:
[2018-07-10T17:05:23.051+0000] [glassfish 4.1] [SEVERE] [] [edu.harvard.iq.dataverse.util.FileUtil] [tid: _ThreadID=31 _ThreadName=http-listener-1(2)] [timeMillis: 1531242323051] [levelValue: 1000] [[
Failed to create filesTempDirectory: /usr/local/glassfish4/glassfish/domains/domain1/files/temp]]

[2018-07-10T17:05:23.051+0000] [glassfish 4.1] [WARNING] [] [edu.harvard.iq.dataverse.EditDatafilesPage] [tid: _ThreadID=31 _ThreadName=http-listener-1(2)] [timeMillis: 1531242323051] [levelValue: 900] [[
Failed to process and/or save the file komodo-ide-11.desktop; Temp directory is not configured.]]

[2018-07-10T17:05:28.364+0000] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.engine.command.impl.CreateDatasetCommand] [tid: _ThreadID=33 _ThreadName=http-listener-1(4)] [timeMillis: 1531242328364] [levelValue: 800] [[
Failed to create StorageIO. StorageIdentifier set to default. Not fatal.(/usr/local/glassfish4/glassfish/domains/domain1/files/10.5072)]]

[pdurbin]

@thaorell thanks for making pull request #4850. I just approved your one line change (I'm not sure why that "VOLUME" line is in there anyway) but standup is in about an hour and I'll invite others to take a look if they want to.

[pameyer]

The VOLUME line exports that directory to persistent storage; the failure is probably because of a uid/gid mismatch between the filesystem and the glassfish user.

[thaorell]

@pameyer that's exactly what happened.

[pameyer]

@thaorell this might be a naive question, but will removing the VOLUME instruction mean that restarting the glassfish container will lose any user uploaded files?

I'd assume that the StatefulSet directives might cover this, but didn't see a filesystem path there

[danmcp]

@pameyer This is a good question. The answer is that we haven't done any of the work necessary to keep state long term. The remaining work is to add persistent volume claims to the template to specify which containers need persistent storage (which I think is all of them). We haven't done so yet because it typically means knowing something about the environment you are deploying into. This might be a good topic for discussion in the future.

[pameyer]

@danmcp @thaorell deferring until working on keeping state long term sounds good to me.