1. You are viewing our forum as a guest. For full access please Register. WindowsBBS.com is completely free, paid for by advertisers and donations.

Are permissions enough or does a dir have to be shared?

Discussion in 'Windows Server System' started by LostUser, 2010/01/05.

  1. 2010/01/05
    LostUser

    LostUser Inactive Thread Starter

    Joined:
    2006/02/27
    Messages:
    100
    Likes Received:
    0
    Hey all.
    I have a question.

    We are using MsServer 2003. Is giving permissions to a user to a directory on the File Server enough to allow it to be mapped from their PC or does the directory have to be shared also?

    The directory is in the root of the C drive.
     
  2. 2010/01/05
    Steve R Jones

    Steve R Jones SuperGeek Staff

    Joined:
    2001/12/30
    Messages:
    12,315
    Likes Received:
    252
    Isn't that something a pro like yourself could test easily;)
     

  3. to hide this advert.

  4. 2010/01/05
    LostUser

    LostUser Inactive Thread Starter

    Joined:
    2006/02/27
    Messages:
    100
    Likes Received:
    0
    Haha, I never profess to be an expert in anything. However, I note your jest, and in hindsight, maybe I should rephrase my question but not before I answer your question I mean to say, I mention what I have tried.

    No, I could not map the directory after just adding the user to the list under the security tab and without the directory being shared. I had to share the directory before I could get it to map.

    I suppose my question should be ... What is the security on a directory for if it doesn't give someone access to the directory to be mapped? Is it only for local access when logging in directly to the PC? Does it fine tune the access once the directory is accessible via share or locally?

    Cheers
     
    Last edited: 2010/01/06
  5. 2010/01/11
    amdace

    amdace Inactive

    Joined:
    2009/09/08
    Messages:
    70
    Likes Received:
    3
    You create the share so that you can access it/map it in. You can add perms to the share so only certain groups/users can access it.
    Once access is granted to the share you can also control users perms on individual files/directories within the share using security.
    Example: you have a a share that only an accounting group can access.
    Within that accounting share you could create confidential directories for each accounting user that only they can access.
     
  6. 2010/01/12
    ReggieB

    ReggieB Inactive Alumni

    Joined:
    2004/05/12
    Messages:
    2,786
    Likes Received:
    2
    There are two levels of security - one at the share level and one at the file permissions level. The simpliest way to think about it is to use a warehouse analogy:

    • Share permission - Gateway access. Defines who can enter the warehouse (shared folder), and whether they have permission to only access and retrieve items (read only) but not bring new items into the warehouse, or can do both (read/write). This only takes effect as the user passes through the gateway (in a ware house: the main entrance. In a file system the share root).
    • File permission - Item by item access. Defines which items a user can access once they have got through the gateway and are into the warehouse.
    Therefore file permissions allow and admin much more precise control of access at the file and sub-folder level. However, they are useless if the user can't even get through the gateway, because they don't have the necessary share permission.
     
  7. 2010/01/15
    LostUser

    LostUser Inactive Thread Starter

    Joined:
    2006/02/27
    Messages:
    100
    Likes Received:
    0
    Thanks for the responses and I like the warehouse analogy. There are just a few things I want clarification on.

    I originally worked with Novell for a number of years so there are a few things I am just trying to understand. In Novell, you cannot see a directory you do not have rights to. It seems like with AD, you can see the shares but just not inside the shares unless you have permissions to the share. Is that right or is it because the server I am working with has the root directory c:\ shared also?
     
  8. 2010/01/18
    amdace

    amdace Inactive

    Joined:
    2009/09/08
    Messages:
    70
    Likes Received:
    3
    You are correct in that you can see all of the shares but cannot access them unless you have permission.
    There is a root administrative share (c$ for example) for all drives. It is not a good practice to share out the root of a drive.
     
  9. 2010/01/19
    LostUser

    LostUser Inactive Thread Starter

    Joined:
    2006/02/27
    Messages:
    100
    Likes Received:
    0
    Yeah, sharing the root drive isn't good, I know that. We didn't originally set up this file server ... so, it is what it is. We will be getting a new file server and I was asked to work on giving access to the directories but not use file sharing ... that's why I have been going along this line of questioning.
    From what I can see, with Microsoft, for a directory to be seen over the network, it has to be shared. Unless, the user is a local user on the server. At least, that's what it looks like.

    Anyway, we will be using a NAS (terastation) as our fileserver so I want to make things as neat and tidy as possible ... Separating user directories from departments, etc.
     
  10. 2010/01/19
    amdace

    amdace Inactive

    Joined:
    2009/09/08
    Messages:
    70
    Likes Received:
    3
    Creating shares on the root does not mean root itself is shared. When browsing the network, users would only see the shares.
    (You could actually lock local users out of directories on the local drives if you were so inclined.)
    If the server is configured as an Active Directory domain controller, you could configure security groups (ie. accounting, sales, support, etc.) and then add users to the groups. When applying perms to shares or directories/files within the shares, you give access to groups instead of individuals. It really lowers the admin overhead.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.