I moved my JIRA home directory to an NSF mount. I put it in the same place as the original JIRA home directory. First I moved the old one to a backup. Then I mounted the shared NSF directory to the original JIRA home location, and copied the entire contents of the old home directory to the new shared NSF directory. So the contents are identical and in the same location.
When I started JIRA back up it complained that it couldn't access the home directory. This was because I had a permissions issue. After fixing the permissions issue JIRA said it couldn't get the lock. So I removed the lock '.jira-home.lock'.
Now it starts up, but I notice that I don't have a tab for 'boards'. I also see that my JIRA Core application has no license but the JIRA Software still has the valid license.
Can someone tell me what happened when I moved the home directory? Why is the agile functionality missing and why is my JIRA core no longer licensed?
First, don't put the home directory on NFS - it's far too slow and does horrid things with caches and file locks.
The problems you're having are partly to do with that, but the permissions issue has probably also done some damage to the database and confused things. That should be ok to fix - stop JIRA cleanly and in full, make sure all the directories are correctly owned by the JIRA user, then restart it (after moving the home directory off NFS) and it should be fine, although I suspect you'll need to re-apply your Core licence to make it work again.
Out of curiosity, why the move on to a non-supported file system? It's ok for the attachments and a couple of other things, but you need most of the home directory on a local disk (and the faster the better)
I realize that it would be slower, but it's a small installation (it's a team of 2 and would almost certainly not grow your larger than 10). How could the slow down possibly cause it to not work? What type of horrid things will happen to the caches and locks if the read and write speeds are somewhat slower.
The reason i thought to put it on an nfs mount is because then the important data is on a redundant RAID storage array.
I'm not going to pretend I understand the details of why Lucene does not work without significant specialist intervention on NFS (it can be done with JIRA Data Centre, but making Lucene-behind-JIRA work passably on shared storage was one of the three big things that Atlassian took a long time to develop for DC)
But on plain JIRA, the internal caches go out of line with the index, file handles start to accumulate and lock up, and the index gradually corrupts. You can rebuild the index from the database, but If you're especially unlucky, the damaged caches can go back to the database and damage it.
By all means, stick the attachments on NFS - there's no indexing or caching on them. The other directories, I'm a bit fuzzy on - I know you must not put the index on NFS, I know you can do what you want with attachments. The others are safe in the sense of "no data loss", but might not be fast
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs