Unable to access hard drive

[jbl85]

After running pkg upgrade that installed 350 updates, this: Is there a quick fix to this issue? Thank you in advance.

 

[covacat]

can be a a need for fsck (can't mount dirty fs as rw);or not enough permissions when mounting as non root user

 

[FrankL]

After running pkg upgrade that installed 350 updates, this: Is there a quick fix to this issue? Thank you in advance.

View attachment 22092

da0s1 ? S??? Slices predate the GEOM framework and pkg so I'm surprised. I don't think I've seen it since FreeBSD 10.
But however you got there, "not permitted" suggests to me there may be a problem with devfs not being mounted or da0s1 not being a recognised file system. Did you pkg upgrade mess with FUSE?

 

[ralphbsz]

We need way more details to know what the issue is.

What file system is on /dev/da0s1? Is it removable? How are you trying to mount it? Do both the device and the mount point exist, and what are their permissions?

 

[jbl85]

da0s1 ? S??? Slices predate the GEOM framework and pkg so I'm surprised. I don't think I've seen it since FreeBSD 10.
But however you got there, "not permitted" suggests to me there may be a problem with devfs not being mounted or da0s1 not being a recognised file system. Did you pkg upgrade mess with FUSE?

I ran pkg update, and then pkg upgrade. Nothing specific regarding FUSE.

 

[bsdimp]

da0s1 is just the MBR name for the first slice. It's not pre-GEOM at all, and GEOM redid the 'slice' code we had before, but kept the names.

Usually this means either (a) the volume was uncleanly mounted and the mount code in the kernel is detecting that and rejecting it. This would be true of UFS, but that's unlikely on an MBR device. FAT/MSDOS filesystem wouldn't have this problem. or (b) the code that mounts it is missing or was damaged in the update process. pkg + kernel modules are known to not get along, so it's possible that if you were using FUSE to access the device, the new fuse binaries don't work with your kernel.