locked
Windows NFS client re-connect to NFS target on reboot RRS feed

  • Frage

  • Hello All, Any ideas how to get the Windows 2008 R2 NFS client to mount a NFS share w/o a script and to occur BEFORE login. I want the NFS resource available for a service to write to that is installed on the server. I've loaded the "Services for Network File System" and that still does not resolve the issue. I need a persistent (aka permanent) connection that survives reboots similar to iSCSI which is outside of the Windows profiles. The hard mount option doesn't appear to work. mount -o mtype=hard \\192.168.1.10\ShareName D: /persistent:yes Thanks, -Ben
    Dienstag, 21. Juni 2011 02:58

Antworten

  • you are looking for option  to have persistent NFS mount.  This is not an option with NFS. Also this scenario is not recommended and does not guarantee a sure shot solution. We have a confirmation from the engineering team on the same. The reason you may face issue is :

     

    This behavior is by design and due to security enhancement in Windows. NFS mounted drive letters are session specific so running this in a script at startup will most likely not work. The service would probably need to mount its own drive letters from a script running in the service context. We have specific guidance that this is not recommended http://support.microsoft.com/kb/180362

     

    When the system establishes a redirected drive, it is stored on a per-user basis. Only the user himself can manipulate the redirected drive. The system keeps track of redirected drives based on the user's Logon Security Identifier (SID). The Logon SID is a unique identifier for the user's Logon Session. A single user can have multiple, simultaneous logon sessions on the system. All devices including mapped drives are associated with an authentication ID (LUID) - an ID generated for each logon session. (A process running in LocalSystem context can create a device name in the Global device namespace, although local namespace objects can hide global namespace objects.)

     

    We completely understand that this behavior is not at par with Unix style of doing the same thing.

     

    Workarounds:

    ·         The workaround for this issue would be creating a batch file : ( This is just a suggestion and not a recommendation )

     

    Create  a batch file which maps the drives and scheduled it to run at Windows
    start up in NTAUTHORITY\SYSTEM context. Drives mapped in SYSTEM context are visible
    in all logon sessions.

     

    You can make the following entry on the batch file  

    net use w: \\Unixmachine\share name 

     

    You can refer to the blogs below to automate the procedure. Though this blog talk about mapping a share (NFS), however it applies to any accessible share.

     

    ·         http://blogs.technet.com/b/sfu/archive/2010/05/26/accessing-nfs-shares-through-an-application.aspx.

     

    ·         http://blogs.technet.com/b/sfu/archive/2009/11/20/making-nfs-volumes-available-to-users.aspx

    Please get back if you have more queries around this.

     


    Ketan Thakkar | Microsoft Online Community Support
    Dienstag, 28. Juni 2011 06:13

Alle Antworten

  • I'm also interested in this question. Hope someone can give some clues.
    Donnerstag, 23. Juni 2011 06:30
  • Sadly, I tested a # of configurations on Windows with the new 2008 R2 NFS client and found nothing that works. I also reviewed about five 3rd party NFS clients and demo-ed a few and NONE supported this feature. All "map" the NFS share AFTER Windows profile login. So, any service that depends on this NFS storage would have an issue. So, I suspect the feature set for disk availability on boot is not possible. It's probably not part of the NFS feature standard. So, I've returned to use iSCSI LUN/targets and bought an extra iSCSI storage solution so I have a "swing" target to make adjustments now.
    Freitag, 24. Juni 2011 03:03
  • you are looking for option  to have persistent NFS mount.  This is not an option with NFS. Also this scenario is not recommended and does not guarantee a sure shot solution. We have a confirmation from the engineering team on the same. The reason you may face issue is :

     

    This behavior is by design and due to security enhancement in Windows. NFS mounted drive letters are session specific so running this in a script at startup will most likely not work. The service would probably need to mount its own drive letters from a script running in the service context. We have specific guidance that this is not recommended http://support.microsoft.com/kb/180362

     

    When the system establishes a redirected drive, it is stored on a per-user basis. Only the user himself can manipulate the redirected drive. The system keeps track of redirected drives based on the user's Logon Security Identifier (SID). The Logon SID is a unique identifier for the user's Logon Session. A single user can have multiple, simultaneous logon sessions on the system. All devices including mapped drives are associated with an authentication ID (LUID) - an ID generated for each logon session. (A process running in LocalSystem context can create a device name in the Global device namespace, although local namespace objects can hide global namespace objects.)

     

    We completely understand that this behavior is not at par with Unix style of doing the same thing.

     

    Workarounds:

    ·         The workaround for this issue would be creating a batch file : ( This is just a suggestion and not a recommendation )

     

    Create  a batch file which maps the drives and scheduled it to run at Windows
    start up in NTAUTHORITY\SYSTEM context. Drives mapped in SYSTEM context are visible
    in all logon sessions.

     

    You can make the following entry on the batch file  

    net use w: \\Unixmachine\share name 

     

    You can refer to the blogs below to automate the procedure. Though this blog talk about mapping a share (NFS), however it applies to any accessible share.

     

    ·         http://blogs.technet.com/b/sfu/archive/2010/05/26/accessing-nfs-shares-through-an-application.aspx.

     

    ·         http://blogs.technet.com/b/sfu/archive/2009/11/20/making-nfs-volumes-available-to-users.aspx

    Please get back if you have more queries around this.

     


    Ketan Thakkar | Microsoft Online Community Support
    Dienstag, 28. Juni 2011 06:13
  • I thought I would share my opinion on this scenarion, as I have been in this exact position.

    The solution provided by Ketan is the "best alternative" to creating an application/service that relies on network based storage within best practice in the first place. I have mounted both CIFS and NFS shares to a Windows 2008 R2 server at system startup/boot (that services/applications can all access) using task scheduler and running the task as NTAUTHORITY\SYSTEM. This solution does work. I had to use this rather than rebuilding the application correctly, because in the real-world, the customers you support aren't always going to fork over the money to rebuild their applications correctly. It works just fine.

    The notable details are that:

    1) Troubleshooting could become more difficult than usual because the mapped drive shows a "disconnected" icon when you try and access it-- even though the data source is completely accessible. DOCUMENTATION.

    2) You won't know if the drive has become disconnected, partially because of step 1, so you need to put procedures in place to make sure if there is a disconnect, that your drive will be "re-mapped". You might consider making your scheduled task run every 5 minutes forever, if you dont mind your event logging filling up.

    We're using the above in a production scenarion, and I can tell you from experience that it works. If you're unable to re-produce the results listed above, you need to find out where your actual issue lies, because the listed solution is not at fault.

    Donnerstag, 21. Juni 2012 21:27