SQL Server FCI installation with Mount Point permissions issues
You may need to set permissions on the mount point volume instead of at a folder level.  I suspect this is the issue you're running into.

From Guidelines for Setting SQL Permissions on Mount Point Folders (highlighting is Microsoft's):


  Gotchas
  
  Unfortunately, it is still possible to set/view permissions on the
  mount-point root folder via Windows Explorer, which can lead to
  unexpected results because the permissions of the mount-point root
  folder may seem valid and you can see “proper” inherited permissions,
  however these are not the permissions applied to the mounted volume. 
  
  
  https://connect.microsoft.com/SQLServer/feedback/details/569895/installation-of-sql-server-2008-r2-on-mount-points-fails
  
  
  Guidelines
  
  
  It is recommended that you do not place any files directly in the mount-point root folder. This will make permissions management much
  simpler, because the tendency is to always check the folder
  permissions, which in this case is misleading. Instead, create a
  subfolder under the mount-point root folder, and set the proper
  permissions to that subfolder.  Since the subfolder is a regular
  folder, the folder permissions you observe and set are indeed the
  permissions being applied. So using the previous example, you would
  want to create a new folder: D:\FolderForVol3**SubfolderXYZ**. Now,
  set your folder permissions against that new SubfolderXYZ folder
  as you normally would.
  If you absolutely must place items directly in the mount-point root folder (Not the recommend approach), then you will need to set
  volume permissions, not folder permissions.  Recall, that this is
  because the mount-point root folder permissions are not the
  permissions which will actually get set on the mounted volume (because
  the mount-point root folder is not a real folder). You can set volume
  permissions as follows:
  
  
  Start->run->diskmgmt.msc (View the properties of a volume  http://technet.microsoft.com/en-us/library/cc740097.aspx )
  Select the volume->Properties->Security tab
  
  If you are adding a new folder for SQL to use, be aware of the required permissions for SQL access:
  
  
  Beginning with SQL Server 2012 permissions are assigned to the per-service SID for each of its services.
  http://msdn.microsoft.com/en-us/library/jj219062.aspx
  Configure Windows Service Accounts and Permissions  http://msdn.microsoft.com/en-us/library/ms143504.aspx
  
  


The way I had to solve this was by using the cacls.exe utility.  Detailed instructions for it can be found here.  I suspect your command to grant full permission to a user would be as follows:

cacls E:\MSSQL\Log\L1 /M /E /G YourUserName:F
cacls E:\MSSQL\Data\Tempdb1 /M /E /G YourUserName:F


You'll want to run this for your account and the SQL Server Service Accounts or group(s) as well.

Final note here, it is imperative that you include the /E flag, otherwise it will overwrite permissions on that path.  This behavior carries additional side effects of ulcers and heavy drinking, so make sure you don't forget the edit flag when running this command.



Another option is to delete the drives and repartition them from scratch.  They're still likely messed up from the original attempt at setting up security via Windows Explorer (e.g. check out the Gotcha clause from the first MS article).

In this case if you still want to write to the root folder on the mount path, you'll want to use the cacls utility.  I would also suggest setting up three sub folders on E:\ such as Data, Logs, and TempDB and then install everything to the sub folders.  Don't nest the mount points into a directory you'll install files to.