I'm trying to recover accidentally deleted video from HUAWEI P10. I use Ubuntu so I tried to recover it using photorec.

The problem is that I can't see mobile internal storage or SD card storage in the list:enter image description here

First row is a HDD, second row is SSD, third is external HDD and the fourth is I don't know what but not any of the mobile storages.

The last row is present only when mobile is connected to the PC.

The mobile is connected to the PC through USB cable and I've set transfer files option. Same result with Transfer photos.

enter image description here

Do you know what to do?


Connecting to PC through USB (MTP) doesn't expose underlying filesystem (ext4 or f2fs) of internal storage (/data partition) to PC. But recovery programs need direct access to filesystem i.e. block level access and won't work with MTP (Transfer Files) which is just a client-server type protocol for data transfer.

You need USB Mass Storage (UMS) which is disabled on Android 3.1.x and above, when MTP was introduced and then UMS was discontinued gradually afterwards in later releases. See Android's Storage Journey and my answer to What is /storage/emulated/0/? for details.

OEMs may add UMS configuration to their devices. For samples you may see on property:sys.usb.config=mass_storage triggers in init.qcom.usb.rc and init.msm.usb.configfs.rc files in a Qualcomm device source.

However it's always possible to enable UMS manually provided that kernel support is present. The process described below should also work for older devices those had UMS officially supported. You need root access or at least custom recovery to enable UMS.


Android Composite Gadget driver (which is an extension to Linux kernel's USB Gadget API) exposes Android in USB device mode to a USB host like PC. Different USB functions (like UMS, MTP, RNDIS etc.) can be configured and switched using sysfs interfaces. Later mainline Linux kernel added the ability to configure USB gadget modes through configfs interfaces. New Android devices also use the same (see this sample init's .rc file).


Kernel must be built with CONFIG_USB_F_MASS_STORAGE and Android Composite Gadget driver (CONFIG_USB_G_ANDROID):

cd /sys/class/android_usb/android0
echo -n 0 >enable
echo -n '/dev/block/bootdevice/by-name/userdata' >f_mass_storage/lun/file
echo -n 'mass_storage' >functions
echo -n <VID> >idVendor
echo -n <PID> >idProduct
echo -n 1 >enable

* Other files in gadget such as {iSerial,iProduct,iManufacturer} are usually set on device boot when creating the gadget.


Kernel must be built with CONFIG_USB_CONFIGFS_MASS_STORAGE:

cd /config/usb_gadget/g1
echo -n 'msc' >configs/b.1/strings/0x409/configuration
echo -n <VID> >idVendor
echo -n <PID> >idProduct
for f in configs/b.1/f*; do rm $f; done
ln -s functions/mass_storage.0 configs/b.1/f1
echo -n '/dev/block/bootdevice/by-name/userdata' >configs/b.1/f1/lun.0/file

* Other files in gadget such as UDC and strings/0x409/{manufacturer,product,serialnumber} are usually set on device boot when creating the gadget.


  • Paths may vary - including directories g1, b.1, f1 etc. - depending on device and the hard-coded configuration.
  • In most cases you need to set proper USB Vendor ID (VID) and Product ID (PID) to make the PC identify the mass storage device. E.g. 05C6 is Qualcomm's VID and 1000 is their PID for UMS device. See .rc files on your device for device specific IDs.
  • Exposing mounted /data filesystem to UMS may corrupt the filesystem, and must be avoided. Use UMS in recovery mode.
  • If your /data partition is FDE encrypted, you need to decrypt it before exposing to UMS.
  • To make sure your data is recoverable, see my answer to How to make a complete factory reset, without anyone being able to retrieve my data?

Now /data will appear as a partition on Linux PC which you can mount (preferably read-only to avoid overwriting data). However recovery tools including extundelete mostly don't need mounting filesystems.

If you have custom recovery, another option is to dd out an image of /data partition to external SD card and then mount it on Linux PC as a loop file. For this and other options to access internal storage at block level, see my answers to related questions.

Using the same methods it's possible to expose a loop file like ISO image or any other filesystem as UMS or CDROM device by writing its path instead of block device path.



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.