# [UFS] Failing to fsck a USB flash disk



## realtime (Sep 19, 2013)

I have a USB flash drive that is reporting errors in phases 1 and 4 of `fsck`.

When unmounted or mounted, in read-only or read-write mode, with several combinations of CLI options, this USB flash drive refuses to cooperate. Basically `fsck` can not get past thinking the drive is in read-only mode - but I've mounted it specifically as read-write.

Suggestions on how to solve this? Thanks.


```
[cmd]# mount -w -t ufs /dev/da0s1 /media/usbflash[/cmd]
[CMD]# mount -v | grep da0s1[/CMD]
/dev/da0s1 on /media/usbflash (ufs, local, journaled soft-updates, writes: sync 2 async 0, reads: sync 2 async 0, fsid fd8da351dfa63be7)

[CMD]# fsck -f /dev/da0s1[/CMD]
** /dev/da0s1 (NO WRITE)
SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on /media/usbflash
** Phase 1 - Check Blocks and Sizes
UNKNOWN FILE TYPE I=321250
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? no
...

[CMD]# fsck -p /media/usbflash[/CMD]
/dev/da0s1: NO WRITE ACCESS
/dev/da0s1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
```

I _am_ running you MANUALLY, fsck! Hello?


----------



## wblock@ (Sep 19, 2013)

What it means is that fsck(8) can't write to a mounted filesystem (except the root filesystem in read-only).  Boot in single-user mode from the menu, then run fsck(8): `fsck -tufs -y /dev/da0s1`


----------



## realtime (Sep 19, 2013)

I was hoping to avoid booting to single-user mode.

Sidetracking for a moment; if there was one thing I'd like to see different about FreeBSD, it'd be being able to do these types of things without rebooting, including resetting kern.securelevel for `freebsd-update`'s, etc.

Alright, appreciate the info, I'll give it a shot next opportunity.

Thanks!


----------



## realtime (Sep 19, 2013)

It looks like that did the trick. I now have all my files back and the filesystem is reporting proper disk space usage.


----------



## throAU (Sep 24, 2013)

realtime said:
			
		

> Sidetracking for a moment; if there was one thing I'd like to see different about FreeBSD, it'd be being able to do these types of things without rebooting, including resetting kern.securelevel for `freebsd-update`'s, etc.



kern.securelevel is this way by design - if you were to enable it to be re-set *after* boot, it would enable a remote attacker to potentially reset it and make changes to things that kern.securelevel is intended to prevent.


----------

