I'm running Windows 10, and am unable to access folders I share with my local LAN boxes from an EFI partition. I have a GPT hard drive with single massive 'EFI System Partition' on it. Since Windows can't mount it automatically I run a batch script on boot which uses diskpart.exe to mount the partition. I've shared some folders from this disk, but am unable to mount them from any os (Linux, Freebsd, Windows 10 itself, Android, whatever). If I copy this folder to an MBR disk, sharing works just fine.

It's not a permissions issue (even though I'm getting access denies), because I apply the same exact acls to ntfs & share security on my non-gpt drive, and can mount that just fine. This leads me to an obvious conclusion that GPT/EFI is the problem.

Here's the relevant event:

Client Name: \\[-scrambled-]
Client Address: [-scrambled-]:xxxxx
User Name: -scrambled-\-scrambled-
Session ID: 0x98000000001D
Share Name: \\*\BOOKS
Share Path: \??\X:\BOOKS
Status: {Access Denied}
A process has requested access to an object, but has not been granted those access rights. (0xC0000022)
Mapped Access: 0x100081
Granted Access: 0x0*

The share is there:

-scrambled-@-scrambled-:~$ net share | grep -i books

I cannot convert the disk to MBR because I simply don't have any way of backing up the data (don't have spare 4Tbs of space). I can't boot EFI either because I've a mix of MBR/GPT disks and a funky multiboot setup...

Any suggestions will be greatly appreciated.


  • Why are you putting all that stuff in the ESP in the first place? Why can't you use a regular GPT partition type? – grawity Dec 4 '15 at 9:25
  • What exactly do you mean by 'regular'? – stacksharki Dec 5 '15 at 3:58
  • GPT does not automatically mean EFI. There are many partition types, for example, "Microsoft Basic data". – grawity Dec 5 '15 at 12:50

Please read the Wikipedia entry on the EFI System Partition (ESP):


The ESP is meant as a place to hold boot loaders and related data. It is NOT meant to store random user data (configuration files, etc.). Although the EFI spec doesn't say anything explicit about the size of an ESP, it's typically somewhere between 100 MiB and 1 GiB. If yours is significantly bigger than that, it's probably better to resize it to a reasonable size and devote the remaining space to a conventional FAT or NTFS partition. If your ESP is smaller than 1 GiB, then you should be able to find sufficient disk space for your needs elsewhere. If you can't do that, then your disk is too small and you should supplement or replace it.

It's also possible that the partition in question isn't really functioning as an ESP, but has its type code set inappropriately. If this is the case, the solution is to change the type code. I'm unfamiliar with most Windows partitioning tools, so I can't say how to do this task with them. In Linux, you could use parted or GParted to remove the "boot flag" from the partition; or use gdisk to change the type code from EF00 to something more appropriate (0700, if the partition uses FAT or NTFS). Before you change the type code, though, you should ensure that it really is not an ESP. An ESP will have a directory called EFI, which in turn will contain one or more subdirectories that holds boot loaders. To boot Windows, it will probably have EFI\BOOT and/or EFI\Microsoft directory trees. and at least one of those will have files with .efi extensions.

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.