# Elasticsearch on read-only filesystem? **URL:** \ **Category:** Elasticsearch\ **Created:** [October 18, 2013, 11:46pm UTC](https://discuss.elastic.co/t/elasticsearch-on-read-only-filesystem/14022 "2013-10-18T23:46:15Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Philip\_Chimento](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/philip_chimento/32/2026_2.png) [@Philip\_Chimento](https://discuss.elastic.co/u/Philip_Chimento)\ **Post date:** [October 18, 2013, 11:46pm UTC](https://discuss.elastic.co/t/elasticsearch-on-read-only-filesystem/14022/1 "2013-10-18T23:46:15Z")
Hi list, I'm new to Elasticsearch. I was wondering if there was a way for the index and documents to live on a read-only filesystem; so far I've read about setting index.blocks.read\_only to true, but it seems that Elasticsearch still needs write access. I tested that by naively doing sudo chmod -R a-w /var/lib/elasticsearch sudo service elasticsearch restart after setting index.blocks.read\_only to true, but the service failed to start, as I feared but also expected 😉 Or what about splitting the index over two filesystems, where the volatile part lives on a writable filesystem and the static part on a read-only filesystem? I don't know much about Elasticsearch's internals yet, but I'm assuming that if you are not redistributing your shards over multiple running instances, and not having to reindex anything because you're not modifying any documents, then most of the index and all the documents should be able to be static? I read this message [1] on this list, but it seems that is more about restricting access to Elasticsearch rather than keeping the index on a read-only filesystem. (I'm running Elasticsearch on an Ubuntu 13.04 system, if that makes any difference.) Regards, Philip [1] [https://groups.google.com/d/topic/elasticsearch/QvRwx2RljMw/discussion](https://groups.google.com/d/topic/elasticsearch/QvRwx2RljMw/discussion) -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [October 19, 2013, 5:23am UTC](https://discuss.elastic.co/t/elasticsearch-on-read-only-filesystem/14022/2 "2013-10-19T05:23:25Z")
Why do you want to do that? In addition to this question, you need to know that Elasticsearch stores also it's own files in addition to Lucene files. Cluster state needs to be updated when a Node leave or join the cluster for example. -- David 😉 Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs Le 19 oct. 2013 à 01:46, Philip Chimento [philip.chimento@gmail.com](mailto:philip.chimento@gmail.com) a écrit : Hi list, I'm new to Elasticsearch. I was wondering if there was a way for the index and documents to live on a read-only filesystem; so far I've read about setting index.blocks.read\_only to true, but it seems that Elasticsearch still needs write access. I tested that by naively doing sudo chmod -R a-w /var/lib/elasticsearch sudo service elasticsearch restart after setting index.blocks.read\_only to true, but the service failed to start, as I feared but also expected 😉 Or what about splitting the index over two filesystems, where the volatile part lives on a writable filesystem and the static part on a read-only filesystem? I don't know much about Elasticsearch's internals yet, but I'm assuming that if you are not redistributing your shards over multiple running instances, and not having to reindex anything because you're not modifying any documents, then most of the index and all the documents should be able to be static? I read this message [1] on this list, but it seems that is more about restricting access to Elasticsearch rather than keeping the index on a read-only filesystem. (I'm running Elasticsearch on an Ubuntu 13.04 system, if that makes any difference.) Regards, Philip ## [1] [https://groups.google.com/d/topic/elasticsearch/QvRwx2RljMw/discussion](https://groups.google.com/d/topic/elasticsearch/QvRwx2RljMw/discussion) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [October 19, 2013, 7:43pm UTC](https://discuss.elastic.co/t/elasticsearch-on-read-only-filesystem/14022/3 "2013-10-19T19:43:15Z")
Read-only search could be useful for kiosk systems > **[Interactive kiosk](https://en.wikipedia.org/wiki/Interactive_kiosk)** > > An interactive kiosk is a computer terminal featuring specialized hardware and software that provides access to information and applications for communication, commerce, entertainment, or education. Early interactive kiosks sometimes resembled telephone booths, but have been embraced by retail, food service and hospitality to improve customer service. Interactive kiosks are typically placed in high foot traffic settings such as shops, hotel lobbies or airports. Integration of technology allows ki... While ES itself could run in volatile memory, an immutable index/search storage may prevent that malevolent accesses can tamper with the data in the index. The search storage could be located on field replaceale units. Jörg -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Philip\_Chimento](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/philip_chimento/32/2026_2.png) [@Philip\_Chimento](https://discuss.elastic.co/u/Philip_Chimento)\ **Post date:** [October 21, 2013, 3:05am UTC](https://discuss.elastic.co/t/elasticsearch-on-read-only-filesystem/14022/4 "2013-10-21T03:05:48Z")
Yep, I'm trying to have an immutable database in order to be able to do things such as update it with the OSTree updater [1] or have the database and index on a DVD. When it needs updating, the update will happen all at once, overwriting the old with an entirely new database and index. For that reason, I also don't need or want more than one node per cluster. [1] [Projects/OSTree - GNOME Wiki!](https://wiki.gnome.org/OSTree) -- Philip Op zaterdag 19 oktober 2013 12:43:15 UTC-7 schreef Jörg Prante: > Read-only search could be useful for kiosk systems > [Interactive kiosk - Wikipedia](http://en.wikipedia.org/wiki/Interactive_kiosk) > > While ES itself could run in volatile memory, an immutable index/search > storage may prevent that malevolent accesses can tamper with the data in > the index. The search storage could be located on field replaceale units. > > Jörg -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Philip\_Chimento](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/philip_chimento/32/2026_2.png) [@Philip\_Chimento](https://discuss.elastic.co/u/Philip_Chimento)\ **Post date:** [October 27, 2013, 8:45pm UTC](https://discuss.elastic.co/t/elasticsearch-on-read-only-filesystem/14022/5 "2013-10-27T20:45:50Z")
On Sunday, October 20, 2013 8:05:48 PM UTC-7, Philip Chimento wrote: > Yep, I'm trying to have an immutable database in order to be able to do > things such as update it with the OSTree updater [1] or have the database > and index on a DVD. When it needs updating, the update will happen all at > once, overwriting the old with an entirely new database and index. For that > reason, I also don't need or want more than one node per cluster. > > [1] [Projects/OSTree - GNOME Wiki!](https://wiki.gnome.org/OSTree) If anyone else ends up in the same situation, I found unionfs-fuse to give good results so far: mount the immutable database readonly, then mount an empty readwrite directory on top of it with copy-on-write semantics. Then, when updating, wipe the readwrite directory. UnionFS has several inherent problems but for a simple use like this, it seems sufficient. -- Philip -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:10am UTC](https://discuss.elastic.co/t/elasticsearch-on-read-only-filesystem/14022/6 "2017-07-06T02:10:23Z")