Sometimes I really wish they hadn't messed around with Linux so much! I know there's an
/etc/fstab in there somewhere, but where?
I'd like to mount some partitions with alternative filesystems (because I don't like FAT32).
Don't think about Android as a heavily modified Linux distribution. Because it's not. The nearly only thing that Android shares with a Linux distribution is the kernel. And even this component is modified. Also other core components, like the libc, differ.
Android has no
You don't need
/etc/fstab to mount an partition. But there is IIRC no
mount command either.
dev_mount should work (root required). To answer your questions title: All startup system mounting is done with the
/etc/vold.fstab helper script.
I'm seeing conflicting information. One resource says it's hardcoded, so not something you can change user-side:
Android-specific init programs are found in device/system/init. Add LOG messages to help you debug potential problems with the LOG macro defined in device/system/init/init.c.
The init program directly mounts all filesystems and devices using either hard-coded file names or device names generated by probing the sysfs filesystem (thereby eliminating the need for a /etc/fstab file in Android).
/etc/vold.conf are mentioned. I have them on my device under CM 7.1 but I'm not sure of how they are used.
You can remount your external storage to be executable by running
mount -o remount, rw /mnt/sdcard
this will remove the noexec, nosuid and nodev flags, but it will still be vfat fs. You can make links to this fs but not from within. The remount does not survive a reboot, because the vold.fstab file will be read and they will be remounted at reboot with the noexec flags.
If you reformat any of your external storage to anything other than vfat, then they will not be remounted at reboot, and any apps that you have moved to any external storage will not be usable. If you don't intend to use external storage for apps then you can unmount your external storage and use
busybox mke2fs DEVICE to make it ext2. Use
busybox newfs_msdos DEVICE to return it to vfat and make it usable again.
busybox mkfs.vfat is broken, you will get something like
lseek: Value too large for defined data type
so don't waste your time. All of this assumes you are rooted, and have a working busybox binary.
I realize that this is an old topic, but some of the answers here actually hindered my efforts to learn about
fstab and Android because they so strongly imply that the
fstab situation in Android is extremely different from other Linux distributions. From what I can tell, it isn't.
However, reading different responses here made me wonder: what
fstab-equivalent file or files are on my device?
Stepping back for a moment, noting that "Android has no /etc/fstab" is probably not helpful to the OP since they must have already known this. If this were untrue, their question (asking what the Android equivalent of
/etc/fstab is) would not make any sense. On the other hand, we know @Flow was not trying to imply that there was no equivalent on Android, since they mentioned one of them, a "helper script" named
All in all, I think the takeaway from @Flow's post is that on some systems, there is a file (possibly a "helper script" - I can't verify that on my phone) called
/etc/vold.fstab, and on those systems, this file is the nearest equivalent to
Getting back to wondering about my own device, I am going to post my findings here for several reasons, in spite of the age of the OP:
fstab-style files I can find on my phone, a Pixel 2XL.
So let me try to sum up everything I have learned from all of this:
Android, or at least its variants that I have access to, does make use of
fstab-style files. However, the exact name, location, and function of these files vary by distribution - meaning by Android version and device, and also by ROM if you use a custom ROM.
To find these files on your system, open up a terminal emulator like
adb shell and run something like this:
find / -type f -iname '*fstab*' 2>/dev/null. The redirection of file 2 (
/dev/null will make your output much cleaner as you will be able to ignore the onslaught of error messages you will get from
find, even if you are
On my system (a Pixel 2XL, code name "taimen"), I found three candidate files:
taimen:/ # find / -type f -iname '*fstab*' 2>/dev/null /sbin/.core/mirror/vendor/etc/fstab.taimen /vendor/etc/fstab.taimen /data/data/com.android.omadm.service/files/dm/dmt_data/fstab
The first two are separate files in that neither is a hard or symbolic link to the other, but if you
diff them you will find that they are identical. Looking a little deeper, if you run
stat on the files you will see that they have the same Device and Inode values:
taimen:/ # stat /sbin/.core/mirror/vendor/etc/fstab.taimen /vendor/etc/fstab.taimen File: `/sbin/.core/mirror/vendor/etc/fstab.taimen' Size: 1326 Blocks: 16 IO Blocks: 512 regular file Device: fc00h/64512d Inode: 925 Links: 1 Access: (644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-01-01 02:00:00.000000000 Modify: 2009-01-01 02:00:00.000000000 Change: 2009-01-01 02:00:00.000000000 File: `/vendor/etc/fstab.taimen' Size: 1326 Blocks: 16 IO Blocks: 512 regular file Device: fc00h/64512d Inode: 925 Links: 1 Access: (644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-01-01 02:00:00.000000000 Modify: 2009-01-01 02:00:00.000000000 Change: 2009-01-01 02:00:00.000000000
stat reports both of these filenames as regular files with only one link each (so no hard or symbolic links are involved). I'm not a filesystem expert but what has happened here is that the same device has been mounted twice. You can see this in the output of the following command, where the only differences between the two lines of output in are the mount points (the part immediately after "on"):
taimen:/ $ mount | grep vendor /dev/block/dm-0 on /vendor type ext4 (ro,seclabel,relatime,block_validity,delalloc,barrier,user_xattr) /dev/block/dm-0 on /sbin/.core/mirror/vendor type ext4 (ro,seclabel,relatime,block_validity,delalloc,barrier,user_xattr)
The third file is only visible to me if I login as root, so if you have a device identical to mine, you still will not find, or have access to, this file unless your phone is rooted. That file has to do with a service called Open Mobile Alliance Device Management, but that is a service I know very little about, so I will just mention it here, and you can Google for details about that if you'd like.