Friday, August 21, 2009

Serious gotchas with mounted drives or mount points on Microsoft Windows Server

I have used mounted drives on Windows Servers and clients for many years, and found them to be powerful tools for managing drive space.  However, there are a few things to keep in mind will keep you from pulling your hair out when they do not work as advertized. 

For the uninitiated, a mount point refers to the ability to create a folder on an existing NTFS formatted drive and change it into a pointer to a completely separate disk space.  For example, this folder could point to a seperate external drive, an assigned LUN from a SAN environment, or even a CD or DVD.  I can hear some of you saying, "What's wrong with drive letters?  They were good enough for grandpa and they're good enough for me."  Too true!  However, there are times when one of two things occur.  First, you may find that you run out of drive letters to assign, or that trying to navigate a flat directory of 17 drives may become cumbersome.  Second, you may run out of space in an existing drive, and although more space is available, your application is not easily set to change its data storage locale to the new formatted space.  Here is where the mount point comes in, letting you use your existing path, but in the background diverting the operation to occur on your larger, more available disk space.
Now, regarding the gotchas:

Permissions: A mount point folder appears as a child object somewhere inside of an existing drive.  This begs the question, what permissions will apply to an object that is inside the mount point?  The answer is simple, as long as you remember that a mount point folder is essentially just a shortcut that guides you to the root of a new partition.  If you build a file inside this partition, it will inherit the permissions of the parent drive, not the shortcut folder (mount point), or the drive that the the mount point folder resides on. 


A mount point folder appears as a child object somewhere inside of an existing drive.  This begs the question, what permissions will apply to an object that is inside the mount point?  The answer is simple, as long as you remember that a mount point folder is essentially just a shortcut that guides you to the root of a new partition.  If you build a file inside this partition, it will inherit the permissions of the parent drive, not the shortcut folder (mount point), or the drive that the the mount point folder resides on. 


This means that if you gave a group named managers full control on the mount point folder they would be able to open it, but would have no permissions on the files and folders on the partition that the mount point guided them to.  If you bring up the properties of your mounted drive folder, you will see that it identifies itself as a mounted volume, and has a second property button on the general tab.  This button opens up the properties of the partition, and it is from there that you can set the security permissions for this volume (assuming that is not a DVD that doesn't have permissions!).



The only other wrinkle in this configuration is that if you go to the advanced properties of a file that is in a mount point, it will identify that its permissions came from the mount point folder's volume.  DON'T BELIEVE IT!  Your permissions for this file will come, of course, from the root of the volume that contains it.

Now for the other gotcha - deleting folders in a mount point.  Here's what happens: you have a subfolder with some files stored in a mount point volume.  Life is good.  The project that the files relate to is several years old, and the data is no longer relevant.  Like a good admin, after ensuring that the data has been archived, you connect to your server via remote desktop, browse to the subfolder, and attempt to delete it.  To which the server replies, "access denied".  Bummer. 
You make sure that there are no applications or explorer windows that are locking it from deletion, and there aren't.  Hmmmm.  The problem is the recycle bin.  This "undo" option is maintained with a hidden system file that is on the partition that holds the files being deleted.  Unfortuantely, when the command to delete a folder is given, the system attempts to delete the folder using the mount point folder's Master File Table, and not the subfolder's Master File Table.  The mount point folder's MFT doesn't host the record, and an access denied message is kicked back to you for having the temerity to try and recycle a directory which apparently doesn't even exist!  The only solution for this is to not recycle subfolders and directories, but to outright delete them.  Locally, an easy method is to hold down SHIFT while deleting a file.  Remotely, when using a UNC path or a mapped network drive, all folders are automatically deleted, so this issue doesn't arise.  This could all make a person want to keep their files in a SharePoint library, but that is a post for another day.

7 comments:


  1. Your services are too good but i am looking for compTIA A+ Course London
    Services....
    Have you any service about CompTIA A+ Course London

    ReplyDelete
  2. I know this post is old but THANK YOU THANK YOU THANK YOU!!!!! This problem was driving me bonkers until I came across your post.

    ReplyDelete
  3. This helped me a ton. Thank you very much!

    ReplyDelete
  4. Great post - exactly what we needed to know. Thanks for sharing your knowledge!

    ReplyDelete
  5. I'm really glad that I'm not the only one who needed to research this one. Thank you for such a helpful post!

    ReplyDelete
  6. The pass4sure CompTIA 220-802 CompTIA A+ Certification examination has been liked by a number of people who've received a fantastic achievement. Pass4surekey comptia exam dumps

    ReplyDelete
  7. This is such a great resource that you are providing and you give it away for free.
    comptia a+ evening courses london

    ReplyDelete

Thank you for providing comments. Please... no advertising your amazing products on my blog. Thank You.