Unable to create directory on server. Resolution Problem?

Question

I use lucene to store the index of some data. The following code checks for the existence of a directory in / home / username and, if it is not found, builds the index from scratch, creating directories, etc.

public static final String INDEX_PATH = "/home/username/appname/lucene/index"; private void buildCompleteIndex(int organizationId) { synchronized(mutex) { File path = new File(INDEX_PATH + "/" + String.valueOf(organizationId)); if(!path.exists()) { try { Utils.deleteDirectory(path); } catch (IOException e) { throw new LuceneIndexException("Error rebuilding index directory.", e); } path.mkdirs(); } List<Contact> contactList = contactDAO.findAll(organizationId, true); if(contactList != null) { for(Contact contact : contactList) { add(contact); } } } } //Getters private IndexReader getIndexReader(boolean readOnly, int organizationId) { try { if(directory == null) { File path = getFile(organizationId); directory = FSDirectory.open(path); if(!IndexReader.indexExists(directory)) { buildCompleteIndex(organizationId); } } return IndexReader.open(directory, readOnly); } catch (CorruptIndexException e) { buildCompleteIndex(organizationId); } catch (IOException e) { buildCompleteIndex(organizationId); } return null; } 

All this works fine in development when I deploy a virtual tomcat instance inside eclipse, but it doesn’t work on a production server.

Why can I write to the directory in dev mode, but not when the application is deployed to the server? I do not have permission to create directories? I am using Ubuntu Server 12.10 and Tomcat7.

How can I get this creating the correct folders and files on the server?

Is there a specific folder that I have to allow my applications to write to the server? It always worked with the home / user folder in my dev block, but maybe this is different on the server because the user was not actually logged in when the application is running?

UPDATE: I checked permissions for the folder that is currently set to 700. Could this be a problem? Is it safe to install this folder on 666 or 777 on the production server? Is this folder writable even if the username / home / username is not registered? I know that 700 means the owner has full access, but does this include tomcat?

UPDATE: I tried changing the permissions on / home / username to 755, and the same problem persisted.

The stack displays an error that occurs when trying to create a folder.

 java.io.IOException: Cannot create directory: /home/ryandlf/thinkbooked.com/lucene/contacts/1 at org.apache.lucene.store.NativeFSLock.obtain(NativeFSLockFactory.java:171) at org.apache.lucene.store.Lock.obtain(Lock.java:72) at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1108) at com.thinkbooked.search.LuceneContactSearchEngine.getIndexWriter(LuceneContactSearchEngine.java:321) at com.thinkbooked.search.LuceneContactSearchEngine.add(LuceneContactSearchEngine.java:68) at com.thinkbooked.search.LuceneContactSearchEngine.buildCompleteIndex(LuceneContactSearchEngine.java:285) at com.thinkbooked.search.LuceneContactSearchEngine.getIndexReader(LuceneContactSearchEngine.java:303) at com.thinkbooked.search.LuceneContactSearchEngine.find(LuceneContactSearchEngine.java:150) at com.thinkbooked.search.LuceneContactSearchEngine.find(LuceneContactSearchEngine.java:145) at com.thinkbooked.handlers.ClientListSearchHandler.init(ClientListSearchHandler.java:49) at com.thinkbooked.event.EventListener.doPost(EventListener.java:59) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) 

Answer 1

According to the answer I received on the question published in the original question, in the standard version of Ucuntu tomcat, tomcat works under a different username. To find this, you can use this command from the command line:

 ps aux | grep catalina 

In my case, he told me that the username is tomcat using tomcat7.

To change the default tomcat username, edit the configuration file in:

 /etc/default/tomcat7 

The first line should contain the default tomcat username, and then the group identifier, which is the same in my case.

To change the ownership of a folder on tomcat so that it can write to the directory, use the chmod command.

 sudo chown -R username:group directory 

-R means that all subfolders and files will also have a new ownership. Omit this if you do not want it.

Answer 2

The cycle is almost certainly caused by some Exception. I see a catch statement in getIndexReader that calls buildCompleteIndex , and the latter calls add , and it is easy to conclude from the stack trace that add closes the loop. To understand the essence of the problem, you must understand the root cause.

Which I can’t know. First attempt: replace all the code in the catch blocks of printStackTrace() and possibly System.exit() to see if it gives more useful information about the first Exception that fires everything else.