uploads subido sido pudo posible podido mover instalación fallo fallida directorio crear content archivo java io

java - subido - No se puede crear un directorio en el servidor. ¿Problema de permiso?



instalación fallida no ha sido posible crear el directorio wordpress (2)

Estoy usando lucene para almacenar un índice de algunos datos. El siguiente código verifica la existencia de un directorio en / home / username y si no se encuentra, crea el índice desde cero creando los directorios, 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; }

Todo esto funciona muy bien en el desarrollo cuando estoy implementando desde una instancia de tomcat virtual dentro de Eclipse, pero falla en el servidor de producción.

¿Por qué podría escribir en el directorio en modo dev, pero no cuando la aplicación se implementa en el servidor? ¿No tengo permiso para crear directorios? Estoy usando Ubuntu Server 12.10 y Tomcat7.

¿Cómo puedo obtener esto creando las carpetas y archivos adecuados en el servidor?

¿Existe una carpeta específica en la que se supone que debo permitir que mis aplicaciones escriban en el servidor? Siempre funcionó con la carpeta de inicio / usuario en mi cuadro de desarrollo, pero tal vez eso es diferente en el servidor porque el usuario no está realmente conectado cuando la aplicación se está ejecutando.

ACTUALIZACIÓN: revisé los permisos de la carpeta que están configurados actualmente en 700. ¿Podría ser ese el problema? ¿Es seguro configurar esta carpeta en 666 o 777 en un servidor de producción? ¿Esta carpeta puede escribirse incluso si el nombre de usuario de / home / username no está conectado? Sé que 700 significa que el propietario tiene acceso completo, pero ¿eso incluye la aplicación Tomcat?

ACTUALIZACIÓN: Intenté cambiar los permisos de / home / username a 755 y el mismo problema persistió.

El stacktrace muestra el error generado al intentar crear la carpeta.

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)


De acuerdo con una respuesta que recibí sobre la pregunta publicada en la pregunta original, en la versión empaquetada estándar de Ubuntu de tomcat, tomcat corre bajo un nombre de usuario diferente. Para encontrar esto, puede usar este comando desde la línea de comando:

ps aux | grep catalina

En mi caso, me dijo que el nombre de usuario que usaba tomcat es tomcat7.

Para editar el nombre de usuario predeterminado de tomcat, edite el archivo de configuración en:

/etc/default/tomcat7

La primera línea debe listar el nombre de usuario predeterminado de Tomcat y luego, la ID del grupo que en mi caso es la misma.

Para cambiar la propiedad de una carpeta a tomcat para que pueda escribir en el directorio, use el comando chmod.

sudo chown -R username:group directory

El -R significa que todas las subcarpetas y archivos también tendrán una nueva propiedad. Omita esto si no quiere eso.


El ciclo casi con certeza se desencadena por alguna Excepción. Veo un enunciado catch en getIndexReader que llama a buildCompleteIndex , y las últimas llamadas add y del seguimiento de la pila es fácil inferir que add cierra el ciclo. Para llegar a la raíz del problema, debe comprender la causa raíz.

Lo cual no puedo saber. El primer intento sería: reemplace todo el código en los bloques catch con printStackTrace() y tal vez System.exit() para ver si genera más información útil sobre la primera Exception que desencadena todo lo demás.