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 BOOKS X:\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.
Thanks!
Please read the Wikipedia entry on the EFI System Partition (ESP):
https://en.wikipedia.org/wiki/EFI_System_partition
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.
User contributions licensed under CC BY-SA 3.0