App Layering: Supporting DFS File Shares
Article ID: CTX227613
Updated On:
Description
The ELM can only access a DFS namespace if SMB 1.0 is enabled on the servers. If SMB 1.0 is disabled, as is becoming more common, the ELM cannot access a DFS namespace directly. Attempts to test the connection will fail.
Resolution
For load distribution and data availability, many customers are choosing to use DFS file shares instead of single-server shares. And for security purposes, customers are choosing to disable SMB 1.0 on those servers. Although the ELM cannot access a DFS namespace when SMB 1.0 is disabled, App Layering still can leverage DFS. Since App Layering uses native Windows for file share access, as long as Windows can access your DFS shares, and the data is there in the DFS namespace, features like Elastic and User layers will work fine.
Since the ELM itself does not support DFS, your only option is to point it directly to a shared folder on one of the servers in the namespace. The ELM will then upload the layers and configuration files normally to that specific server. On the backend, DFS replication will manage duplicating the data to the rest of the DFS servers. The data is actually available in your DFS namespace even if the ELM could not directly talk to DFS. And if the specific server the ELM is configured to talk to becomes unavailable, the file server information can be changed at will to point to another server in the cluster.
And that means that your published images absolutely can take advantage of DFS namespaces, for load sharing and data redundancy. The published images don't need to find the files in the exact place the ELM put them, they simply need to find the files where they are told to look for them. So you just need to reconfigure your published images to read data from DFS instead of the direct file server. When publishing an image, the ELM puts in the registry the name of the share it uploaded to, so that the layering software in the image will download its elastic layers from the same location. However, that registry key can be changed after publishing, by a script or a GPO.
See https://support.citrix.com/article/CTX222107 for the registry information as well as a sample GPO template.
Since the ELM itself does not support DFS, your only option is to point it directly to a shared folder on one of the servers in the namespace. The ELM will then upload the layers and configuration files normally to that specific server. On the backend, DFS replication will manage duplicating the data to the rest of the DFS servers. The data is actually available in your DFS namespace even if the ELM could not directly talk to DFS. And if the specific server the ELM is configured to talk to becomes unavailable, the file server information can be changed at will to point to another server in the cluster.
And that means that your published images absolutely can take advantage of DFS namespaces, for load sharing and data redundancy. The published images don't need to find the files in the exact place the ELM put them, they simply need to find the files where they are told to look for them. So you just need to reconfigure your published images to read data from DFS instead of the direct file server. When publishing an image, the ELM puts in the registry the name of the share it uploaded to, so that the layering software in the image will download its elastic layers from the same location. However, that registry key can be changed after publishing, by a script or a GPO.
See https://support.citrix.com/article/CTX222107 for the registry information as well as a sample GPO template.
Problem Cause
The CIFS/SMB module in the CentOS Linux kernel currently available does not support DFS on SMB higher than 1.0.
Was this article helpful?
Yes
No
Powered by
