i.MX6DL/Solo booting Android 4.2.2 over NFS: error: cannot create dir, Permission denied

[brenton]

I am trying to get a MX6-Solo to boot Android from TFTP and run over NFS.  But it always fails with Android encountering filesystem Permission denied during init (installd processing). 

Specifically, the board successfully loads the kernel image (using tftp), and Android mounts the nfs root filesystem and begins its initialization (init.rc operations).  However, logcat shows that the installd process can't create the necessary subdriectories, e.g.

  E/installd( 2421): cannot create dir '/data/data/com.android.providers.contacts': Permission denied

At this point /data/data is owned by system (1000) with permissions 771. 

This seems suspicious to me because init.rc launches the installd service as system/system.  So why doesn't it have permissions to create subdirectories?

Additionally, if I change init.rc so that /data/data is created with permissions 777 instead of 771 (just so it can get past this problem), installd will then create directories for all the system apps in /data/data, and these will be owned by 1012/1012 (AID_INSTALL/AID_INSTALL - see android_filesystem_config.h) with 751 permissions.  But unfortunately then fails to chown these directories, reporting in logcat:

E/installd( 2420): cannot chown dir '/data/data/com.android.providers.contacts': Operation not permitted

I'm presuming this is where installd wants to chown each directory to its corresponding application uid (e.g. u0_a0/u0_a0 as I observe in the Emulator). But, at least under Linux, a regular user (such as installd) can't chown a file or directory to another user.  So Android must have hacked this part of linux, which is fine except in this case it doesn't work because the nfs server is linux not Android.  Is that why Operation not permitted is thrown?  Nevertheless this is a secondary problem.  The original problem is why installd can't create directories within /data/data which is owned by system (1000) with 771 permissions? 

Has anyone been able to boot and run Android over nfs? 

Things I've tried with no success:

1. Followed the instructions in the Android_User_Guide.pdf for configuring init.rc and init.freescale.rc to boot over nfs.

2. Moved all users and groups on the nfs server that might collide with Android's uid/gids out of the way up into the 90000 range.  I've verified this works as Android uses 1000/1000 for its System uid which doesn't exist on the NFS server, and observe Android is successful in chown'ing directories there from root to 1000.  So Android is able to modify the filesystem.

3. Switched the Android build target from user to eng thinking it might be a security setting for production to not allow it to run over nfs.  But even under eng target there is the same problem.

Gory details -

/etc/exportfs:

/home/b8t/rootfs *(rw,sync,nohide,insecure,no_subtree_check,no_root_squash)

bootargs given to kernel:

Kernel command line: console=ttymxc0,115200 video=mxcfb0:dev=ldb,800x480M@60,bpp=32 fbmem=10M var_ts_type=ctw6120 init=/init nosmp gpumem=64M vmalloc=400M androidboot.console=ttymxc0 androidboot.hardware=freescale root=/dev/nfs ip=192.168.2.58 nfsroot=192.168.2.21:/home/b8t/rootfs,v3,tcp

Using Android 4.2.2.

[brenton]

Seems like the placement of "setprop ro.nfs.mode yes" in init.freescale.rc is significant.

If positioned at the end of the "on boot" section, then the above problem (insufficient permissions) is observed.  However, if the property is set earlier in the section then Android won't encounter this problem - although other errors still exist.

I'll post another update if/when I can get this to work better after some more experimentation.

[brenton]

I find putting "setprop ro.nfs.mode yes" in init.rc at beginning of boot section ("on boot") works best. 

[alejandrolozan1]

Hi,

I tried to boot over NFS using and the boot was successful. I have not checked if I get a error in logcat.

I wonder if you can try with JB43 ? http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Design_Tools_Tab#

Best Regards,

Alejandro

[brenton]

I'm using JB 4.2.2 (basis of product) and hence not able to switch at this time to JB 4.3.

[nikitayushchenk]

I'm facing exactly same situation on different (not Freescale's) hardware.

I guess problem is caused by installd's code that tries to drop privileges but keep filesystem access permissions via capabilities.

See code in drop_privileges() routine in installd source. Perhaps NFS server knows nothing about capabilities of client-side process and thus denies requests.

Don't yet know how to workaround this. Probably commenting out permission dropping in installd source will work, but don't know what consequences this will cause.