# What could cause a filesystem to be unwritable?



## n8ur (Jul 16, 2012)

I'm still struggling with the problem stated in my threat on nanoBSD.  The symptom is that a UFS1 filesystem created on a CF card under 9.0-STABLE mounts with no write permissions and nothing I've been able to figure out will let me change the permissions, or write to the filesystem.  I've explicitly mounted the slice on the host system with rw options, but still it shows as read only.  fsck indicates that the filesystem is clean.

I'd love to find out what things I can look for that might cause a filesystem or slice to be locked as unwritable.  I've played with tunefs, dumpfs, fdisk, fsck, etc. and don't see any obvious problems -- but then again, I'm neither a filesystem guru nor a FreeBSD native.

Thanks much for any pointers.


----------



## jb_fvwm2 (Jul 16, 2012)

```
mount
mount -o rw /dev/da0
```
Slight chance that command with modifications would make it r-w... or give some error message.


----------



## n8ur (Jul 16, 2012)

Thanks very much for the reply, but I've already tried mounting explicitly with "-o rw".  No error message, but still no write permissions.

Attemting to chmod u+w after mounting yields "Operation not permitted."


----------



## da1 (Jul 16, 2012)

Are the partitions ro or rw in /etc/fstab?


----------



## imrozx (Sep 20, 2012)

n8ur did you try to boot your nanobsd? all nanobsd are meant to be in read only mode. so each time you wanted to do a modification to it manually you need to run this command.

make changes in / (nanobsd)

```
# mount -u -o rw /
after make change in /
# mount -u -o ro /
```

to enable permission in /cfg (first time only)

```
# mount /cfg
# chflags -R noschg /cfg
# umount /cfg
# reboot
```


----------



## n8ur (Sep 21, 2012)

Following up on a couple of responses...

My problem was that I could not write to the /cfg filesystem that is supposed to be rw to store config info that overwrites into /etc at boot. This worked properly in my old nanobsd system, but not u der FreeBSD 9.

I have not found a fix within nanobsd but a workaround is to manually recreate the /cfg filesystem onto the s2 slice after the nanobsd script finishes.  For some reason, this creates a writeable /cfg filesystem when the same command within the nanobsd script fails to do so.


----------

