Freenas Root Filesystem Read Only

[mrwillz]

This is more of an configuration question then install. I Freenas 7.2 i was able to modify files via the GUi and they would be persistent across reboots. But now in Freenas 8 I do not see any way to do this. This wouldn't be a problem but sicne the / filesystem is ro I can not login via the command and modify the file either. Is there anyway around this?

 

[ProtoSD]

Have a look at the FAQ #22/23 (Link below in signature) and this thread:
Settings-reverting-and-files-disappearing-on-reboot&p=5817#post5817

 

[mrwillz]

Thanks the mount -uw / worked perfectly.

 

[Paktas]

read-only filesystem - why?

But why would FreeNAS filesystem need to be read-only? USBs are good enough for writing, no? We had a FreeBSD running on USB stick with writeable filesystem... worked fine...

Now with Freenas we've got logs dissapearing, reporting dissapearing after reboots... So, again, the question is - why is the filesystem is made to be read-only? Can we enable it to be writable on boot? What are the risks?

 

[Paktas]

can anyone comment on this?

 

[Durkatlon]

Well mounting / rw on boot wouldn't help you with log files and reporting. All those files are in /var which is running from a memory disk. So these directories will end up lost after a reboot no matter what.

 

[Paktas]

ok, I get that it's read-only. BUt the question was WHY is the filesystem read-only?

 

[tconley]

He has a good point. I am running freenas off a 8gb memory stick which leave about five gigs empty. how hard would it be to change var log to runn on that space so the logs can be maintained?

 

[Durkatlon]

First guess is that it is because it is based on nanobsd and this is how that distro works. I would love to have RRD graphs that persist across reboots. Having that "Yearly" button on the Reporting page is a bit of a joke right now :D.

 

[tconley]

Exactly. Plus it seem like running all of that in a ram disk is a waste of memory. the memory foot print when up so much from 7 anything that would reduce the memory foot print is something that should probably be looked at.

 

[jgreco]

The filesystem is read-only because that's best practice for designs of this sort. Flash has a limited number of write cycles. It's trivially easy to make an error in your design that writes frequently to flash; I commented on this early in the 8 series where something was tickling atime on a rw filesystem and causing a boatload of flash writes. Locking off something that doesn't need to be written to is more secure, reduces the chance of inadvertent things, and reduces the chance of failure making the system unbootable.

 

[ProtoSD]

Actually the RAM use is minimal and your flash would be the thing getting wasted if it weren't being used.
Here's a screen shot from RC1:


So we're talking a measly 81MB of RAM...