Posts Tagged ‘SMB’

Accessing DFS files using ExtremeZ-IP Network Reshare

Wednesday, June 6th, 2012


Prior to the release of version 8.0, ExtremeZ-IP supported Mac AFP access to Microsoft Distributed File System (DFS) file shares in several ways. Traditional ExtremeZ-IP DFS support requires one or more DFS namespaces to be added to the DFS tab in the ExtremeZ-IP Administrator’s Settings window. Then, Mac clients must be set up with one of the following options:

  • – The “Zidget” Dashboard widget – Used to browse DFS namespaces and mount specific resources within them.
  • – The ExtremeZ-IP “DFS Client” application – Used to allow mounting of DFS volumes in the Finder and browsing of the related DFS namespace, similar to the experience Windows presents to users.
  • – Manual modification of the Mac’s “auto_master” file – Provides the same experience as the DFS Client option, but requires editing a standard Mac config file rather than installing client software.

All of these options require client side software or changes on each Mac that requires access to DFS.

ExtremeZ-IP 8.0’s Network Reshare feature introduces an additional option for providing Macs with access to DFS resources. Network Reshare allows ExtremeZ-IP AFP file volumes to give access to folders located on other servers and NAS devices on your network. Macintosh clients continue to connect to ExtremeZ-IP using the standard AFP file sharing protocol, while ExtremeZ-IP utilizes the SMB/CIFS file sharing protocol to access files that are requested by Mac users from remote servers and NAS systems. By doing so, Mac users retain all the benefits of AFP file sharing while gaining access to resources that have traditionally only been available through SMB/Windows file sharing.

DFS shares can be configured as ExtremeZ-IP Network Reshare volumes. DFS target resolution simply occurs in the SMB reshare communication layer and Macs are able to seamlessly browse and access the reshared DFS resources presented in a standard AFP volume. No Mac client-side software or changes are required. Macs simply connect to ExtremeZ-IP AFP Network Reshare volumes in the Finder and can immediately browse the DFS namespace.

For more details on Network Reshare, see our Configuring Network Reshare support in ExtremeZ-IP knowledge base article.


ExtremeZ-IP Server acts as DFS client
When hosting a Network Reshare DFS volume, the ExtremeZ-IP Windows server makes requests for resources located in DFS namespaces on behalf of the the Mac client. From the perspective of DFS, the Windows server itself is the client, not the actual Mac user making the request. For this reason, all DFS target selection and site costing will be negotiated for the Windows server, rather than the Mac client.

All Network Reshare communication is routed through the ExtremeZ-IP Windows server
Network Reshare routes all communication between your Mac clients and your DFS namespaces through the Windows server where ExtremeZ-IP is installed. This requires an extra network hop compared to the Mac client accessing DFS targets directly. For the best possible performance, it is recommended that ExtremeZ-IP is installed on a server with the fastest available NICs, and ideally this server has one or more NICs dedicated to communicating with the servers, NAS, or DFS namespaces being reshared.

ExtremeZ-IP Network Reshare feature and Network Reshare DFS volume configuration

For full details on configuring your ExtremeZ-IP server for Network Reshare and instructions on setting up a Network Reshare DFS volume, please see our Configuring Network Reshare support in ExtremeZ-IP knowledge base article.

Adobe InCopy does not properly handle file locks on network storage

Tuesday, February 1st, 2011

Within the application, Adobe InCopy performs file check-ins and check-outs to support multiple users working within a single document. When a segment of a document is checked out, it is given a file lock, which can be seen on the server as an .IDLK file. The idea behind this is that all client computers will be watching for these lock files, see them, and both display and honor them when access is requested from another individual.

In testing, we have found this functionality to be problematic on network shares. The results of our testing three different workflows follow:

– Windows server using SMB: Lock files are created, but do not display and are not honored by the software. For example, UserA begins editing a segment of an InCopy (or InDesign) document using InCopy, UserB will be able to go in and make edits to that segment as well. This will result in data integrity issues.

– Mac OS X server using AFP: Same behavior as SMB above, but after unknown periods of time, the locks may display inside the InCopy software, but still are not honored.

– Windows server using ExtremeZ-IP for AFP: Locks are always honored, but only display intermittently.

Files that can be seen from OS X 10.4 Macs are missing when viewed from 10.5 or 10.6 Macs

Wednesday, July 28th, 2010

There is a known issue that can occur when a Mac client connected to a Windows server using SMB creates a file or folder with a trailing space in the name. Mac OS X 10.4 Mac clients can connect to the server using AFP / ExtremeZ-IP and list the entire volumes contents, but newer 10.5 and 10.6 Mac clients will stumble on the file or folder that contains the trailing space and fail to list all subsequent items.

To fix this issue: From a Mac OS X 10.4 client, mount the volume via SMB (Go -> Connect to Server -> smb://) and remove the trailing space from any files or folders that contain them.

ExtremeZ-IP and AFP do not have this trailing space issue. All Mac OS clients are able to properly create a file/folder name with a trailing space correctly for the NTFS filesystem. Once the SMB trailing space names are fixed be sure that users only connect via AFP to keep this problem from occurring again.

How To Prevent Mac Clients From Mounting Volumes Using SMB

Tuesday, September 22nd, 2009

While most Macintosh users understand they should avoid using SMB to connect to AFP shares, there is a Finder bug in Mac OS 10.5 which may be adding to confusion and contributing to users accidentally connecting to AFP shares using SMB.

The Finder bug manifests when you expand the Sidebar’s “Shared” triangle. When you navigate “Shared” the Finder attempts to connect via SMB (even if the volume is already connected via AFP). This leads users to mistakenly believe they have been disconnected and prompts them to connect using SMB.

Here are a few tips you can use to help limit confusion:

  1. Under Finder > Preferences > Sidebar:
  • Uncheck “Connected Servers” and “Bonjour Computers”.
  • Sidebar

    This will make the “Shared” option disappear from the Sidebar altogether.

  • Check “Computer”.
  • Volumes under Computer

    This will allow you to navigate servers and shares from “Devices”.

  1. Under Finder > Preferences > General:
  • Check “Connected Servers” to place Volume icons on Desktop.
  • Finder Preferences

    This will allow users to navigate and always get to AFP Volumes via “Computer”.