External hard drives no longer mount

  • Having trouble with two external USB hard drives. Both are formatted NTFS GPT. Both of these drives used to work fine with my setup (asus chromebox running 8.2.1). They are directly connected to the rear USB ports. I recently had them connected to my windows pc for a bit to move some files around. Now that the drives are connected to the chromebox again, they no longer mount. I have tried safely removing from windows, disabling the fast startup power option, even dismounting with the diskpart utility.

    When I try to mount it I get:

    LibreELEC:~ # mount -t ntfs-3g /dev/sdb2 /var/media
    mount: mounting /dev/sdb2 on /var/media failed: No such device

    Here's the output of blkid, sdb2 and sdc1 are the drives.

    LibreELEC:~ # blkid
    /dev/sda1: LABEL="System" UUID="58F5-65E2" TYPE="vfat" PARTLABEL="primary" PARTUUID="84674f76-b1c3-447a-b850-b169feeaf835"
    /dev/sda2: LABEL="Storage" UUID="5e3e178b-9301-4d87-aa20-fb9f0753b5e8" TYPE="ext4" PARTLABEL="primary" PARTUUID="124f1675-8044-4ea4-938b-661e05f580a6"
    /dev/sdb2: LABEL="Zoltan" UUID="9AAA1647AA161FF5" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="e559037d-372d-46fc-b12d-60d34749aef0"
    /dev/loop0: TYPE="squashfs"
    /dev/sdc1: LABEL="continuumtransfunctioner" UUID="BE761A60761A19AB" TYPE="ntfs" PARTLABEL="easystore" PARTUUID="695d4e48-d138-49d9-bb23-8ee926808983"
    /dev/sdb1: PARTLABEL="Microsoft reserved partition" PARTUUID="73bb2259-f3df-4103-94cb-4748d55a2fc7"

    And the output of mount

    and dmesg

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Also noticed that if I unplug the drive from the chromebox while libreelec/kodi is running, a popup notification shows saying the drive was removed.

    Any ideas? Thanks

  • Thinking it is related to this Windows 10 Fall Creators Update Breaks NTFS 64K Allocation Size Disks - Microsoft Community

    Both of my drives are 64k cluster as well. I will try to get access to a windows 7 pc later and run chkdsk on there to see if that fixes it. Otherwise I'll just reformat as ext4 I guess.

    Edit: just ran chkdsk and safely removed on my laptop running Windows 10 non-creators version and that fixed the issue. This is definitely a problem with windows 10 creators update. Seems like just connecting any NTFS drive (maybe only with 64k cluster size) to a creators update PC "breaks" the drive for any 3rd party ntfs systems.

    Edited once, last by jaba1337 ().

  • We'll add it to the growing list of Win10 pains. Good to hear chkdsk.exe is still 'the' solution of NTFS things :)

  • Sorry for reviving this old thread, but it seems to me that:

    a. This problem still persists & I think I'm facing the same issue. NTFS disks without errors from fully updated Windows 10 system that fail to mount on LibreELEC

    b. Windows 7 installation base is constantly decreasing (and I do not have access to a Windows 7 system atm, only fully updated Windows 10 systems)
    c. There seems to be a bugfix available for this exact issue at Bug 1527231 – Linux cannot mount NTFS filesystem from Windows 10 creators update 1709

    If (c) indeed corresponds with the issue described, I'll be happy to test a build (if someone can port the fix).

  • I am just preparing a new test of my community build 8.2.5 and will try to include this fix later today.

  • Big thanks to everyone for their help.

    Unfortunately, it seems my problems may be different than what I thought.

    I tried both the builds provided, and also a Fedora 28 live CD.

    In all three I failed to mount my NTFS drives.

    So I can't really comment on the fix (maybe it works, maybe it doesn't, maybe it solves some problems and causes others), but it would seem something else is wrong with my NTFS drive.

    If anyone has any more pointers on how to research my problem I would appreciate it. What I have until now:

    - External enclosure with 4TB NTFS drive

    - Windows 10 Home fully updated

    - Fast boot is disabled, and powercfg /h is set to off

    - Windows 10 sees the drive perfectly well, chkdsk reports no errors

    - fdisk -l claims "The primary GPT table is corrupt, but the backup appears OK, so that will be used."

    - gdisk output

  • Windows and Linux have fundamentally different approaches to drive mounting. Windows wants to ensure you can access your data so as long as there is 'a' valid disk scheme somewhere on the disk it will mount. Linux values integrity and will refuse to mount when issues are found.

    If you have other storage devices; move the data off (via Win) and reformat the drive, copy the data back. Test for a while. If all is good it was nothing to worry about. If you see further issues it may be a physical issue with the drive and it's time for a replacement.

  • My 0.02 cents...

    (If possible) Copy all data to a safe location, format the drive to EXT4, copy back the data, and stick to Linux on your (HT)PC.

    Sometimes a new approach is quicker/safer than keep looking for the culprit in the first place.

  • Actually it was hardware problems (combined with my lack on experience on EXT4) that led me back to NTFS after a catastrophic loss of data that even PhotoRec couldn't save in the end. (about 8TB worth).

    So now I'm trying to move whatever else I have on EXT4, back to NTFS, so that I can more easily work with them on Windows in case of problems.

    In the end, after a lot of trial and error, I managed to create new NTFS partitions (using GParted) that mount fine both on LibreELEC and Windows 10.

    Something in my setup, causes Windows 10 created GPT/NTFS partitions to be problematic on linux.

    Again, thanks to everyone for their help.

    Regarding the actual fix/patch discussed earlier, as I said, I can't offer any advice because it would appear my problems originate elsewhere. Unless someone can verify the fix actually works (or at least doesn't introduce new issues) I would advice against merging it.