Stata on Linux - serious update failure

[Gordon Hughes]

I am trying to deal with an issue with Stata on Linux where the standard Stata Corp advice has caused a major problem. I am trying to update Stata18 to the latest version. The update procedure failed because it is unable to rewrite the Java directories. The error message is: "Could not move jar file to .old/". Clearly a problem with permissions.

The FAQ advice offered by Stata Corp is to delete the .old and Java directories in the utilities folder, and then force a reinstallation of Java. I have followed that advice but I am still getting the original message and I find that the update process has recreated the .old subdirectory. Hence, this is a Catch-22 situation but now I have no Java installed.

My guess is that the update procedure creates the .old folder with the wrong permissions before it tries to move the Java directory even though the Java directory doesn't exist. Can anyone suggest the sudo chmod ... command that would be needed to ensure that the reinstallation of Java works?

[Gordon Hughes]

In a sense, the whole thing goes from bad to worse. On experimentation, it turns out that it is necessary to delete the jar directory as well as the java and .old directories in order to get Java reinstalled. But then ... the update procedure fails because it cannot write documentation files to the docs directory. I have tried changing the permissions on that directory but still the procedure says that it is read only.

Part of the reason that this is such a mess is the order in which -update all- works. Documentation updates are not critical but updating ado files is critical. However, the documentation update precedes the ado file update and it is no longer possible to use the command update ado. Hence, failing to update documentation files means that ado files cannot be updated.

As I said in my first post, it is clear that something is wrong with the way in which permissions are set when Stata is installed on LInux. Tthat problem is then exacerbated by the logic by which update all works.

[James Hassell (StataCorp)]

Gordon Hughes, yes this does sound like a permission issue. You might verify that the umask for the user account updating Stata is reasonable. If that does not help out, then please reach out to [email protected] and they will be happy to assist you.

[Gordon Hughes]

Just to tidy up for any future readers: this was an issue with permissions on various Stata sub-directories. I solved it in a pretty drastic way by giving all users permission to read, write & execute files in the Stata ado, docs & utilities directories and their sub-directories. I should emphasise that I wouldn't recommend this as a general rule but this installation was in a VM that I can control pretty tightly. The Stata Corp advice was to change the user's permissions whenever I wanted to upgrade the program, which I thought was too much of a pain. The alternative is to run Stata as the root user when carrying out updates which can be done by setting up the option of using Stata via the command line interface.