3

I used to be able to access a separate ssd for windows, but after updating to Ubuntu 23.10 it gives me the following error :

Unable to access location Error mounting /dev/sdb1 at /media/abdelrahman/2A907C5D907C3185: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error

Also there is another partition on that ssd that is accessible without issues.

How to solve this issue without formatting the other drive ?

image of the error msg

Abdelrahman Elhosiny
  • 43
  • Is it an NTFS filesystem? Can you try mounting it manually: create a mountpoint mkdir ~/my_mount then mont it specifying FS sudo mount -t ntfs3 /dev/sdb1 ~/my_mount – Raffa Nov 16 '23 at 16:49
  • Some helpful information that you might want to include in your question are the output of findmnt --fstab and sudo file -Ls /dev/sdb1 and sudo fdisk -l /dev/sdb1 – Raffa Nov 16 '23 at 17:02

2 Answers2

4

This problem usually occurs due to bad clusters, dirty states or due to a missing helper program.

The basic fix for missing helper program is to install the following:

sudo apt install nfs-common
sudo apt install cifs-utils

Still if you are unable to fix the problem, ntfsfix might help fix the partition

The ntfs-3g package contains the ntfsfix utility(This usually comes preinstalled). If not,

sudo apt install ntfs-3g

Then try to fix the partition using the following commands

Change the partition based on your system. In your case the 634 GB Volume is /dev/sdb1 as displayed in the screenshot you provided. In order to fix that particular partition, run the following

sudo ntfsfix -b -d /dev/sdb1

-b tries to fix bad clusters and -d to fix dirty states.

Hope it helps!

Arjun K Shibu
  • 951
  • 1
    I don't quiet get what helper program you mean? ... NTFS filesystems are supported by the kernel ... Please see https://www.kernel.org/doc/html/v5.17/_sources/filesystems/ntfs3.rst.txt ... And rushing to run checking/fixing tools on filesystems you don't investigate first might lead to data loss/corruption, so be careful please. – Raffa Nov 16 '23 at 17:10
  • 1
    sudo ntfsfix -b -d /dev/sdb1

    this fixed the issue, thank you very much.

     – Abdelrahman Elhosiny Nov 16 '23 at 18:40
  • 1
    @Raffa Earlier on my system, NTFS partitions were marked as fuse filesystem and were mounted using fuse. In most of the cases it displayed the same error as displayed on the above screenshot. I had to manually change fuse from mounting the filesystem. Permissions won't take effect on a fuse filesystem. The first two commands helped me in fixing the issue and mounting ntfs using default ntfs-3g driver. As of my knowledge ntfsfix is widely used to fix ntfs partition in linux with very minimal data loss chances. Correct me if my understanding is wrong, I'm still in the learning phase. Thank you! – Arjun K Shibu Nov 17 '23 at 02:46
  • @ArjunKShibu FUSE is not the case anymore, in fact it may cause problems with recent kernels and ntfsfix schedules a future check on Windows that might override changes made on Ubuntu, so not that safe ... I have added an answer that I hope will clear things up. – Raffa Nov 17 '23 at 08:35
3

Helpful technical information

ntfs-3g is not the thing anymore

The FUSE based ntfs-3g implementation of reading/writing NTFS filesystems in Ubuntu is no more advised and is now obsolete in favor of the current native NTFS kernel driver/module NTFS3.

ntfsfix is not your first go to tool

It dosn't fully fix anything, but rather, mainly, removes the safety markers that trigger the safety measures on Ubuntu so that the affected partition will not be mounted or will be mounted in read-only (to protect your data) and therefore allowing you to make changes to that filesystem that might damage your Windows installation and cause data loss on both sides, Ubuntu and Windows, in regards to that filesystem ... Quoting from man ntfsfix (emphasis is NOT mine) it says:

ntfsfix is NOT a Linux version of chkdsk. It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows.

... which means that neither your newly written data (from Ubuntu) on that filesystem nor the preexisting data (from Windows) is considered safe/fixed yet, but rather pending a filesystem check the next time you boot to Windows ... and quoting from man ntfs-3g (emphasis is mine) it says:

On computers which can be dual-booted into Windows or Linux, Windows has to be fully shut down before booting into Linux, otherwise the NTFS file systems on internal disks may be left in an inconsistent state and changes made by Linux may be ignored by Windows.

Why is this happening

In dual boot systems with Windows managing those filesystems, this issue is, in the majority of cases, is caused by Windows hibernation which saves the current running session to disk or Windows fast boot/reboot feature enabled which will do the same i.e. saving current running session to disk which might include unsaved user data or system operations and changing/"fixing" that filesystem in such state from within Ubuntu is not recommended to prevent data loss and/or filesystem corruption … Therefore, the default system response of refusing to mount such filesystem or at most mounting it in read-only mode that you see on Ubuntu is because such unstable filesystem state is detected and it’s not safe enough to be mounted as a read and write filesystem.

What to do then?

Check NTFS filesystems from within Windows and not from within Ubuntu and then make a clean shutdown from Windows and not a hibernation or a reboot with fast reboot feature enabled.

Raffa
  • 32,237
  • 1
    Much appreciated! Thanks for the information! – Arjun K Shibu Nov 17 '23 at 12:48
  • yeah fast boot was actually on, also worth mentioning that when booting to windows last few weeks every boot it was scanning for drive errors and doing the auto repair thing, but never stopped doing it even when I let it finish the repair, but after I ran sudo ntfsfix -b -d /dev/sdb1 from ubuntu it stopped – Abdelrahman Elhosiny Nov 17 '23 at 15:11