Android microSD card won't mount on Linux OS (Unable to access). Why?

[Vincent Cheng Hoi Chuen]

Android microSD card won't mount on Linux OS (Unable to access). Why?

What is this error telling me?
a. Dolphin: http://i.imgur.com/DABMmKP.jpg
b. Nautilus http://i.imgur.com/6XgdcI1.jpg
==================================================================
Unable to access "134 GB Volume"
Error mounting /dev/mmcblk0p1 at /media/guest/21E3-00CC: Command-line
`mount -t "exfat" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,
iocharset=utf8,namecase=0,errors=remount-ro,umask=0077" "/dev/mmcblk0p1"
"/media/guest/21E3-00CC"'
exited with non-zero exit status 32: mount: unknown filesystem type 'exfat'
==================================================================
1. I have two micro-sd cards for my Android cellphone (32GB & 128GB).
2. Both work in the phone (and both have important data I wish to archive).
3. I archive by copying to my Linux HDD & then I burn to DVD (it's what I do).
4. I do not wish to use the cloud!
5. I just want to mount both flash cards (they fit into an adapter).
6. The 32GB microSD card (in the SD-card adapter) mounts just fine.
6. The 128GB microSD card (in the same SD-card adapter) will not mount.
==================================================================
What can I do to debug on Linux (and save my Android data)?
==================================================================

[Mike Easter]

Vincent Cheng Hoi Chuen wrote:
> Android microSD card won't mount on Linux OS (Unable to access). Why?

> unknown filesystem type 'exfat'

> What can I do to debug on Linux (and save my Android data)?

enable exfat

sudo apt-get install exfat-fuse exfat-utils

http://askubuntu.com/questions/364270/mount-unknown-filesystem-exfat
Mount unknown filesystem exfat

http://ubuntuforums.org/showthread.php?t=2238314 [SOLVED] Ubuntu 14.04
exfat problem

--
Mike Easter

[David W. Hodgins]

On Wed, 28 Oct 2015 18:30:51 -0400, Vincent Cheng Hoi Chuen <vcheng...@hotmail.com.hk> wrote:


> 6. The 32GB microSD card (in the SD-card adapter) mounts just fine.
> 6. The 128GB microSD card (in the same SD-card adapter) will not mount.

On my Mageia 5 x86_64 system, there are two packages needed to work
with exfat file systems. exfat-utils and fuse-exfat

Another possible cause for problems ...
See https://en.wikipedia.org/wiki/Secure_Digital#Storage_capacity_and_incompatibilities
SDHC vs SDXC cards (and card adapters).

Regards, Dave Hodgins

--
Change dhodg...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[Eef Hartman]

In alt.os.linux Vincent Cheng Hoi Chuen <vcheng...@hotmail.com.hk> wrote:
> ==================================================================
> Unable to access "134 GB Volume"
> Error mounting /dev/mmcblk0p1 at /media/guest/21E3-00CC: Command-line
> `mount -t "exfat" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,

^^^^^
The exfat is a MicroSoft variation on the "normal" fat32 of Windows-95
SR2 etc:
(from wikipedia):
> exFAT is a file system introduced with Windows Embedded CE 6.0 in
> November 2006 and brought to the Windows NT family with Vista
> Service Pack 1. It is loosely based on the File Allocation Table
> architecture, but incompatible, proprietary and protected by
> patents.[62]

> exFAT is intended for use on flash drives (such as SDXC and Memory
> Stick XC), where FAT32 is otherwise used. Microsoft's GUI and
> command-line format utilities offer it as an alternative to NTFS (and,
> for smaller partitions, to FAT16B and FAT32). The MBR partition type
> is 0x07 (the same as used for IFS, HPFS, NTFS, etc.). Logical geometry
> information located in the VBR is stored in a format not resembling
> any kind of BPB.

So to read that card from Linux you need to get support for this fs,
how, depends on your distribution. And MicroSoft does claim patents
on their VFAT extensions, so it may not even be available for you.
They did get TomTom to drop the usage of VFAT:
> In February 2009, Microsoft filed a patent infringement lawsuit
> against TomTom alleging that the device maker's products infringe on
> patents related to VFAT long filenames. As some TomTom products are
> based on Linux, this marked the first time that Microsoft tried to
> enforce its patents against the Linux platform. The lawsuit was
> settled out of court the following month with an agreement that
> Microsoft be given access to four of TomTom's patents, that TomTom
> will drop support for the VFAT long filenames from its products, and
> that in return Microsoft not seek legal action against TomTom for
> the five year duration of the settlement agreement.

[Vincent Cheng Hoi Chuen]

Mike Easter <Mi...@ster.invalid> wrote in d9d1fl...@mid.individual.net:

> sudo apt-get install exfat-fuse exfat-utils

Thanks for the pointer, which was spot on ... almost.
http://i.imgur.com/jgOHf7A.jpg

The good news is that command worked just fine.
Now the micro SD card mounts automatically.

The bad news is that I seem to have destroyed all my data, by mistake
when I was trying to mount it and dd it and copy it and stuff.

I don't even remember what I did.
Do you think there is a way to save the data?

[Chris]

Vincent Cheng Hoi Chuen <vcheng...@hotmail.com.hk> Wrote in message:

Photorec should work, but it'll be slow and give all files it
finds random names. It's designed to recover photos, but I think
it works with file types as well.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[The Real Bev]

If the exif data is also recovered, a free downloadable utility called
jhead (windows, linux, maybe mac) will rename the files.


--
Cheers, Bev
================================================================
"Is there any way I can help without actually getting involved?"
-- Jennifer, WKRP

[Vincent Cheng Hoi Chuen]

The Real Bev <bashl...@gmail.com> wrote in n0u639$tjo$1...@dont-email.me:

>> Photorec should work, but it'll be slow and give all files it
>> finds random names. It's designed to recover photos, but I think
>> it works with file types as well.
>
> If the exif data is also recovered, a free downloadable utility called
> jhead (windows, linux, maybe mac) will rename the files.

Both Photorec and Jhead seem like great ideas.
Jhead seems to work on Linux but Photorec seems to be a windows thing.

BTW, does anyone have experience who can tell me *why* there
is just a LOST.DIR and .android_secure directory?

What are those directories anyway?

[tjoen]

The Real Bev wrote:

>
> If the exif data is also recovered, a free downloadable utility called
> jhead (windows, linux, maybe mac) will rename the files.

Here's an alias that I use to rename files:
alias picname='for f in *.{png,PNG,jpg,JPG,jpeg,JPEG,gif,GIF}; do echo "picname $f";exiv2 -r '%Y%m%d-%H%M%S-:basename:' rename $f; done'

[John Hasler]

Vincent Cheng Hoi Chuen writes:
> ...Photorec seems to be a windows thing.

In Debian PhotoRec is in the testdisk package.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[Vincent Cheng Hoi Chuen]

John Hasler <jha...@newsguy.com> wrote in
87d1vxw...@thumper.dhh.gt.org:

> In Debian PhotoRec is in the testdisk package.

Thanks. I did not know that.

I don't have it on my system:
$ testdisk
The program 'testdisk' is currently not installed. You can install it by typing:
sudo apt-get install testdisk

But it was easy to add:
$ sudo apt-get install testdisk
$ which photorec
/usr/bin/photorec

$ photorec --help
PhotoRec 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <gre...@cgsecurity.org>
http://www.cgsecurity.org

Usage: photorec [/log] [/debug] [/d recup_dir] [file.dd|file.e01|device]
photorec /version

/log : create a photorec.log file
/debug : add debug information

PhotoRec searches various file formats (JPEG, Office...), it stores them
in recup_dir directory.

If you have problems with PhotoRec or bug reports, please contact me.

Now I just have to figure out the syntax so that the
recovery is on a different partition than the data.

[Vincent Cheng Hoi Chuen]

Chris <ithi...@gmail.com> wrote in n0sl9e$qd7$1...@dont-email.me:

> Photorec should work, but it'll be slow and give all files it
> finds random names. It's designed to recover photos, but I think
> it works with file types as well.

I tried Recuva from Piriform on Windows, but for some reason, Recuva
doesn't understand the 128GB micro-SD card's exfat file system on
WinXP.

http://i.imgur.com/pQweikt.jpg

Warning: Failed to scan the following drives.
E:: invalid drive size

[Vincent Cheng Hoi Chuen]

Vincent Cheng Hoi Chuen <vcheng...@hotmail.com.hk> wrote in
n0ujdu$tpt$1...@solani.org:

> Now I just have to figure out the syntax so that the
> recovery is on a different partition than the data.

On Linux, I installed testdisk and ran photorec and now I have to figure
out what type of file system exfat is, since it's not in the photorec
options.

http://i.imgur.com/4dtYwyu.jpg

My choices are:
a) [ ext2/ext3 ] ext2/ext3/ext4 filesystem
b) [ Other ] FAT/NTFS/HFS+/ReiserFS/...

I don't know which one to choose.
Looking up exfat, I find it's described here:
https://en.wikipedia.org/wiki/ExFAT

But it doesn't answer the question.
Which would you choose?

[The Real Bev]

On 10/29/2015 06:44 PM, Vincent Cheng Hoi Chuen wrote:
> The Real Bev <bashl...@gmail.com> wrote in n0u639$tjo$1...@dont-email.me:
>
>>> Photorec should work, but it'll be slow and give all files it
>>> finds random names. It's designed to recover photos, but I think
>>> it works with file types as well.
>>
>> If the exif data is also recovered, a free downloadable utility called
>> jhead (windows, linux, maybe mac) will rename the files.
>
> Both Photorec and Jhead seem like great ideas.
> Jhead seems to work on Linux but Photorec seems to be a windows thing.

http://www.sentex.net/~mwandel/jhead/ also has a jhead.exe download and
one for OS-X.

> BTW, does anyone have experience who can tell me *why* there
> is just a LOST.DIR and .android_secure directory?
>
> What are those directories anyway?

Not a clue, but there's a LOST.DIR on my nook reader too. Perhaps we'll
find out when we accidentally delete a directory we REALLY didn't want
to delete...

--
Cheers, Bev

"I love this country...
...and the freedoms we used to have..."
--George Carlin

[chris]

Well it's certainly not (a), so it must be (b)...

[chris]

LOST.DIR where the filesystem puts files that are 'broken' following a
disk check. Broken files are typcially created during program or system
crashes.

[Vincent Cheng Hoi Chuen]

chris <ithi...@gmail.com> wrote in n0vgq8$otn$1...@dont-email.me:

> Well it's certainly not (a), so it must be (b)...

I'm not sure how you knew it wasn't (a), since there is "ex" in the
name "exfat" and (a) had "ex" at the same time there was "fat" in (b)
and "exfat" also has "fat". (http://i.imgur.com/JSZOtJh.jpg)

Since the default chose "b", I went with the default and let it run.
It found lots of "errors". (http://i.imgur.com/CdFy8jH.jpg)

But, unfortunately, photorec found absolutely nothing.
(http://i.imgur.com/NxRC64Z.jpg)

[Vincent Cheng Hoi Chuen]

The Real Bev <bashl...@gmail.com> wrote in n0v01j$442$1...@dont-email.me:

> Not a clue, but there's a LOST.DIR on my nook reader too. Perhaps we'll
> find out when we accidentally delete a directory we REALLY didn't want
> to delete...

I looked up LOST.DIR and it apparently can often contain huge amounts
of data (mine isn't all that large, just a few megabytes).

It's sort of like a trash can for checkdisk type Android errors,
according to what I could figure out from the articles I read.

Nobody seems to know for sure, but most people just delete the
LOST.DIR with impunity when they see it.

So I don't think all my missing data is in there.

[Vincent Cheng Hoi Chuen]

chris <ithi...@gmail.com> wrote in n0vgtj$otn$2...@dont-email.me:

> LOST.DIR where the filesystem puts files that are 'broken' following a
> disk check. Broken files are typcially created during program or system
> crashes.

That's what I found out also. It doesn't seem to be where all my millions
of pictures went.

I also looked up the ".android_secure" directory, which seems to be where
apps are put when you tell Android to move an app to the SD card.

So, the ".android_secure" directory, which is the only other thing I
can see on that 128GB card, is not where my lost files are either.

[Vincent Cheng Hoi Chuen]

Vincent Cheng Hoi Chuen <vcheng...@hotmail.com.hk> wrote in

n0s0pq$obr$1...@solani.org:

>> sudo apt-get install exfat-fuse exfat-utils
>
> Thanks for the pointer, which was spot on ... almost.
> http://i.imgur.com/jgOHf7A.jpg
>
> The good news is that command worked just fine.
> Now the micro SD card mounts automatically.

I will try Recuva on Windows XP, which also seems to need the
exfat driver extensions because mine didn't recognize the card.

http://www.microsoft.com/en-us/download/details.aspx?id=19364
https://support.microsoft.com/en-us/kb/955704

[chris]

On 30/10/2015 13:00, Vincent Cheng Hoi Chuen wrote:
> chris <ithi...@gmail.com> wrote in n0vgq8$otn$1...@dont-email.me:
>
>> Well it's certainly not (a), so it must be (b)...
>
> I'm not sure how you knew it wasn't (a), since there is "ex" in the
> name "exfat" and (a) had "ex" at the same time there was "fat" in (b)
> and "exfat" also has "fat". (http://i.imgur.com/JSZOtJh.jpg)

I know because ext2/3/4 are default linux filesystems and all others the
aren't. exFAT, vFAT, FAT32 (possibly others) are all variants of the FAT
filesystem which is also mentioned in option (b). However, given the
list, it isn't clear whether photorec supports exFAT.

According to here http://www.cgsecurity.org/ it does, so that shouldn't
be an issue.

> Since the default chose "b", I went with the default and let it run.
> It found lots of "errors". (http://i.imgur.com/CdFy8jH.jpg)
>
> But, unfortunately, photorec found absolutely nothing.
> (http://i.imgur.com/NxRC64Z.jpg)

You might be out of luck :(

[chris]

On 30/10/2015 13:04, Vincent Cheng Hoi Chuen wrote:
> chris <ithi...@gmail.com> wrote in n0vgtj$otn$2...@dont-email.me:
>
>> LOST.DIR where the filesystem puts files that are 'broken' following a
>> disk check. Broken files are typcially created during program or system
>> crashes.
>
> That's what I found out also. It doesn't seem to be where all my millions
> of pictures went.

That's because you've probably affected the filesystem as a whole rather
than just the odd file here or there.

[Eef Hartman]

In alt.os.linux Vincent Cheng Hoi Chuen <vcheng...@hotmail.com.hk> wrote:
> a) [ ext2/ext3 ] ext2/ext3/ext4 filesystem
> b) [ Other ] FAT/NTFS/HFS+/ReiserFS/...

ext? are Linux "extended minix" filesystems, versions 2, 3 cq 4
(neither minix fs itself nor ext without a number are used in Linux
anymore, although the minix driver is still available in the kernel).

And if you look in the wikipedia entry, you'll find:

> exFAT is a file system introduced with Windows Embedded CE 6.0 in
> November 2006 and brought to the Windows NT family with Vista
> Service Pack 1. It is loosely based on the File Allocation Table

(abbreviation FAT)

> architecture, but incompatible, proprietary and protected by
> patents.

so exFAT means "extended FAT", but _not_ compatible with the Linux
vfat driver (which can handle fat12/16/32 with long filenames).

Hoepefully choice 2 with an exfat driver (manually) loaded will do the
trick, but no guarantees, unerase IS rather low level fs access.

[Eef Hartman]

In alt.os.linux chris <ithi...@gmail.com> wrote:
> I know because ext2/3/4 are default linux filesystems and all others the
> aren't.

Not quite true: ReiserFS, which _was_ mentioned under b) is a Linux fs
(at least: the 3.5 and 3.6 versions are, ReiserFS 4 never made it).

[Vincent Cheng Hoi Chuen]

chris <ithi...@gmail.com> wrote in n0vr0s$d5$2...@dont-email.me:

> That's because you've probably affected the filesystem as a whole rather
> than just the odd file here or there.

I think part of the problem is that I think at some point I formatted
the card using the machines that I only now realize never had exfat
file system support.

:(

[Vincent Cheng Hoi Chuen]

chris <ithi...@gmail.com> wrote in n0vqsm$d5$1...@dont-email.me:

> According to here http://www.cgsecurity.org/ it does, so that shouldn't
> be an issue.

I appreciate that you knew enough because you were right that exfat
was basically the "FAT" option, and not the "ex" option.

The program ran. It found errors. But it also found no files.

[Vincent Cheng Hoi Chuen]

Eef Hartman <E.J.M....@gmail.com> wrote in
56338278$0$23833$e4fe...@news.xs4all.nl:

> Hoepefully choice 2 with an exfat driver (manually) loaded will do the
> trick, but no guarantees, unerase IS rather low level fs access.

Choice 2 appears to be the correct choice.

[Lenny Pinto]

On Fri, 30 Oct 2015 13:08:03 +0000 (UTC), Vincent Cheng Hoi Chuen wrote:

> I will try Recuva on Windows XP, which also seems to need the
> exfat driver extensions because mine didn't recognize the card.

Maybe the san disk sd card formatter will work?
SD Formatter 4.0 for Windows
https://www.sdcard.org/downloads/formatter_4/

[Chris]

Vincent Cheng Hoi Chuen <vcheng...@hotmail.com.hk> Wrote in message:

Exactly. The filesystem is damaged so it can't do anything with
LOST.DIR

As an aside are these good quality 128Gb cards? There are a lot of
fake SD cards around which are very unreliable.

[Fritz Wuehler]

> > exFAT is a file system ... is loosely based on the File Allocation
> > Table architecture, but incompatible, proprietary and protected by
> > patents.[62]

In that case, perhaps exfat is a poor choice. Also considering that
it probably has the same chronic fragmentation problems that the other
FAT systems have.

A better approach is probably to format the card as ext4 in your
desktop, and configure your desktop to mount it with the
last-read-date bit turned off. Of course, that's only a good idea if
Android mounts it that way too. Out of curiosity, does anyone know?

[chris]

Frustratingly, android doesn't support ext2/3/4 ...

[Daniel James]

In article <5633831f$0$23833$e4fe...@news.xs4all.nl>, Eef Hartman wrote:
> In alt.os.linux chris <ithi...@gmail.com> wrote:
>> I know because ext2/3/4 are default linux filesystems and all others the
>> aren't.
>
> Not quite true: ReiserFS, which _was_ mentioned under b) is a Linux
> fs

It is a Linux FS, but not a *default* Linux FS, so what Chris wrote was in
fact "quite true".

Does anyone still use ReiserFS, anyway?

--
Cheers,
Daniel.

[The Real Bev]

Probably because most people use windows.


--
Cheers, Bev
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"I can't stand this proliferation of paperwork. It's useless to
fight the forms. You've got to kill the people producing them."
-- Vladimir Kabaidze

[chris]

On 01/11/2015 18:15, The Real Bev wrote:
> On 11/01/2015 02:56 AM, chris wrote:
>> On 31/10/2015 11:41, Fritz Wuehler wrote:
>>>>> exFAT is a file system ... is loosely based on the File Allocation
>>>>> Table architecture, but incompatible, proprietary and protected by
>>>>> patents.[62]
>>>
>>> In that case, perhaps exfat is a poor choice. Also considering that
>>> it probably has the same chronic fragmentation problems that the other
>>> FAT systems have.
>>>
>>> A better approach is probably to format the card as ext4 in your
>>> desktop, and configure your desktop to mount it with the
>>> last-read-date bit turned off. Of course, that's only a good idea if
>>> Android mounts it that way too. Out of curiosity, does anyone know?
>>
>> Frustratingly, android doesn't support ext2/3/4 ...
>
> Probably because most people use windows.

ext2/3/4 is in the kernel, so the android developers actively /removed/
support.

So what if most people use Windows? Android could quite easily be ext2
internally and also support FAT on SD cards.