If I have a folder X on Windows Server 2016 that contains a junction point to another folder Y on the same machine and volume, and I share X over the network, will a remote user who connects to X be directed to Y?
The challenge is that the location and name of Y change periodically after a scheduled task execution, but I want remote users to always use the same network share name (X). One option is to update the junction point during the task’s execution, but I’m looking for other solutions.
Recreating or updating a network share named X and pointing it directly to Y works, but only if X is a top-level share.
I need a solution that also works for a subfolder A within Y, where remote users can access it via the network path X\A, as well as for a different path on the machine accessed via a network path such as X\B, which could be achieved by creating a junction point from Y\B to another path.
Can this be done?
3 Answers
What is an NTFS Junction Point?
NTFS junction points are a feature of the Windows NTFS file system that allows a directory to be linked to another directory on the same disk volume. When a program accesses a junction point, the operating system redirects the request to the target directory. Junction points are similar to symbolic links in UNIX-like operating systems.
Following an NTFS Junction Point Across a Network Share
In the scenario described, a folder X on Windows Server 2016 contains a junction point to another folder Y on the same machine and volume. The challenge is to share X over the network and have remote users directed to Y, even though the location and name of Y change periodically after a scheduled task execution.
The short answer is no, it is not possible to follow an NTFS junction point across a network share. When a folder is shared over the network, the operating system creates a new share point that is separate from the local file system. Remote users who connect to the share point are not aware of any junction points that may exist in the local file system.
Possible Solutions
One possible solution is to update the junction point during the scheduled task’s execution. This can be done using a batch script or PowerShell script that runs as part of the task. The script would need to identify the new location and name of Y and update the junction point accordingly. However, this solution may not be practical if Y changes frequently or if there are multiple junction points that need to be updated.
Another solution is to recreate or update the network share named X and point it directly to Y. This can be done using the “net share” command in Windows. However, this solution only works if X is a top-level share. It does not work for subfolders such as A within Y or for different paths on the machine accessed via a network path such as XB.
Alternative Solutions
One alternative solution is to use a symbolic link instead of a junction point. Symbolic links are similar to junction points but can be followed across network shares. However, symbolic links have some limitations compared to junction points. For example, they cannot be used to link to a file or directory on a different volume, and they require administrative privileges to create.
Another alternative solution is to use a DFS (Distributed File System) namespace. DFS allows multiple file servers to be grouped into a single logical namespace, which can be accessed by remote users using a single network path. DFS supports junction points and symbolic links, so it can be used to link to a changing target directory such as Y. However, setting up a DFS namespace requires additional configuration and maintenance.
Conclusion
In summary, it is not possible to follow an NTFS junction point across a network share. However, there are several possible solutions and alternatives that can be used to achieve the desired outcome. The best solution depends on the specific requirements and constraints of the situation. It is important to weigh the pros and cons of each solution and choose the one that best fits the needs of the organization.
Yes, it is possible for a remote user to follow an NTFS junction point across a network share. When a remote user accesses the network share X, they will be redirected to the target of the junction point, which is folder Y. This is because junction points are transparent to the user and operate at the file system level, rather than the network share level.
It is worth noting that junction points are only supported on NTFS file systems and are not recognized by other file systems, such as FAT or exFAT.
You can use the mklink command in Windows to create a junction point. For example, to create a junction point named “X” that points to “Y”, you can use the following command:
mklink /J X Y
You can then share folder X over the network and remote users will be able to access it as if it were a normal folder, with the added benefit that any changes made to the target folder Y will be reflected in the network share X.
If you need to redirect remote users to a different path on the machine, you can create additional junction points in the target folder Y and share them over the network as well. For example, you could create a junction point named “B” that points to another path on the machine, and share it over the network as X\B.
It’s also worth noting that you can use symbolic links instead of junction points for this purpose. Symbolic links are similar to junction points, but they are supported on all file systems and can be used to link to directories or files, not just directories. To create a symbolic link, you can use the mklink command with the /D option. For example:
mklink /D X Y
This will create a symbolic link named “X” that points to the directory “Y”. Like junction points, symbolic links are transparent to the user and operate at the file system level, so they can be used to redirect remote users to different paths on the machine when accessed through a network share.
The SMB fileserver has the ability to automatically follow directory junctions (created using “mklink /j“) even if the target is outside of a shared folder, and this has been verified through experimentation. However, the server will not follow symlinks (created using “mklink /d“), and it is up to the client to do so. By default, clients do not follow symlinks, but this can be enabled if the target is another shared folder. More information can be found in harrymc’s post.
Another option is to create a share as a DFS namespace on Windows Server. This allows for regular files and special “referral” directories to coexist, with the latter pointing to another share, even on a different server. These referrals are always followed client-side and are recognized by all Windows versions, as well as libsmbclient and Linux cifs.ko.
DFS is the recommended choice if folder Y may need to be moved to a different machine, as it doesn’t require Active Directory, although using a common authentication across all fileservers can make things simpler.