无法在服务器上创建目录。许可问题?

时间:2013-05-26 06:44:50

标签: java io

我正在使用lucene来存储一些数据的索引。以下代码检查/ home / username中目录是否存在,如果找不到,则从头开始构建索引,创建目录等。

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;
}

当我从eclipse中的虚拟tomcat实例部署时,这一切都在开发中很有效,但在生产服务器上失败了。

为什么我能够以开发模式写入目录,但是当应用程序部署在服务器上时却没有?我没有权限创建目录吗?我正在使用Ubuntu Server 12.10和Tomcat7。

如何在服务器上创建正确的文件夹和文件?

我应该允许我的应用程序在服务器上写入特定文件夹吗?它始终与我的开发箱上的home / user文件夹一起使用,但是在服务器上可能有所不同,因为用户在应用程序运行时实际上没有登录?

更新 我检查了当前设置为700的文件夹的权限。这可能是问题吗?在生产服务器上将此文件夹设置为666或777是否安全?即使未登录/ home / username的用户名,此文件夹是否可写?我知道700意味着所有者拥有完全访问权限,但这包括tomcat应用程序吗?

更新:我尝试将/ home / username的权限更改为755,同样的问题仍然存在。

stacktrace显示尝试创建文件夹时生成的错误。

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)

2 个答案:

答案 0 :(得分:1)

循环几乎肯定是由一些异常触发的。我在getIndexReader中看到一个调用buildCompleteIndex的catch语句,后者调用add,并且从堆栈跟踪中很容易推断add关闭循环。要了解问题的根源,您应该了解根本原因。

我不可能知道。首先尝试:用printStackTrace()System.exit()替换catch块中的所有代码,看看它是否会产生更多关于触发其他所有内容的Exception的有用信息。

答案 1 :(得分:0)

根据我在原始问题中发布的问题的回答,在Ubuntu的标准打包版本的tomcat上,tomcat以不同的用户名运行。要找到它,您可以从命令行使用此命令:

ps aux | grep catalina

在我的情况下,它告诉我tomcat使用的用户名是tomcat7。

要编辑默认的tomcat用户名,请在以下位置编辑配置文件:

/etc/default/tomcat7

第一行应列出默认的tomcat用户名,然后是组ID,在我的情况下是相同的。

要将文件夹的所有权更改为tomcat以便它可以写入目录,请使用chmod命令。

sudo chown -R username:group directory

-R表示所有子文件夹和文件也具有新的所有权。如果你不想要,请忽略这一点。