If you have read this blog before, you know I am not a Microsoft Windows fanboy. For those who have not read it before, let's talk about one of its annoying features: the use of drive letters to make fileshares available to the user. I understand the idea of using drive letters... in the 80s personal computers since they had at best two floppy drives or if you were really rich a floppy and a hard drive. During those bad hairstyle times, you only needed some way to differentiate two devices, so why not call them A and B or 0 and 1? But we now live in a time where a lot of people in our planet do not even know what a floppy drive is (hint: it is not a sex toy) and might connect a phone, a portable storage device of some kind, and who knows what will come next? 26 "drives" might run out quickly. Also,
why must we mount a new device/fileshare at the top level ("drive") instead of in a directory inside another fileshare like you do in UNIX (including Linux and OSX)?
The dirty little secret is that you can, but most users who grew up using Windows are so used to drive letters they cannot think of the option. And, there are Windows programs out there which can only handle drive letters. Point is, Microsoft is not to blame. In fact, they have been trying to convince people to use Microsoft (duh!) UNC Paths, which might not follow the path convention used by every other operating system out there but it is a huge improvement from the drive letter thingie. So, credit to where credit is due.
But, this article is not about path conventions and the religion around them. All we want to do is mount a fileshare inside another in windows. Humble goal, yes? Well, as the poem says, "The best laid schemes of mice and men / Often go awry."
There are instructions out there to mount a fileshare without using drive letters in Windows; the one I picked uses the Computer Management GUI thingie, which might be important since coworkers are paralytic fearful of the command line:
Why is it not showing the D: drive? After all, diskpart can see it:
PS C:\Users\raub.adm> diskpart Microsoft DiskPart version 6.3.9600 Copyright (C) 1999-2013 Microsoft Corporation. On computer: Srv12R2 DISKPART> list volume Volume ### Ltr Label Fs Type Size Status Info ---------- --- ----------- ----- ---------- ------- --------- -------- Volume 0 F New Volume NTFS Simple 99 GB Healthy Volume 1 D Data NTFS Simple 2959 GB Healthy Volume 2 C Srv12R2 NTFS Simple 59 GB Healthy Boot Volume 3 System Rese NTFS Simple 350 MB Healthy System Volume 4 E Utility NTFS Simple 61 GB Healthy Volume 5 Z DVD-ROM 0 B No Media Volume 6 Volume NTFS Partition 4095 GB Healthy DISKPART>
And I can mount it from diskpart into some folder in the D: drive without a problem.
DISKPART> select volume 6 Volume 6 is the selected volume. DISKPART> assign mount=d:\tmp DiskPart successfully assigned the drive letter or mount point. DISKPART>
I wants 2 c mah driv!
Similar to an issue we talked about in an early article, we have a bad case of access control being too controlling. Specifically, the mount stuff is defined in Drive_Letter:\System Volume Information\spp for each drive and those who need to see it are not. Let me show you what I mean. Here is the E: drive, which we know we can mount a fileshare inside it using the GUI.
PS C:\Users\raub.adm> cacls 'e:\System Volume Information\spp' e:\System Volume Information\SPP AD\SOD_Domain Admins:(OI)(CI)(ID)F BUILTIN\Administrators:(OI)(CI)(ID)F NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F PS C:\Users\raub.adm>
Now here is the problematic D: drive:
PS C:\Users\raub.adm> cacls 'd:\System Volume Information\spp' d:\System Volume Information\SPP AD\NETWORK_Domain Admins:(OI)(CI)(ID)F PS C:\Users\raub.adm>
As you can see, the local admin entities, Administrators and the SYTEM accounts, can't access D:. So let's correct that:
PS C:\Users\raub.adm> cacls 'd:\System Volume Information\spp' /e /g system:f processed dir: d:\System Volume Information\SPP PS C:\Users\raub.adm> cacls 'd:\System Volume Information\spp' /e /g administrators:f processed dir: d:\System Volume Information\SPP PS C:\Users\raub.adm> cacls 'd:\System Volume Information\spp' d:\System Volume Information\SPP NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)F AD\NETWORK_Domain Admins:(OI)(CI)(ID)F PS C:\Users\raub.adm>
Much better! Moral of the story, if you or your computer cannot access a drive in some way or form, do check permissions.