Problems creating an SMB share on a windows cluster
TLDR: If you experience the error “New SMB shared folder cannot be created. The object already exists.” on a clustered windows server, ensure that storage dependencies to the Fileserver service are correctly registered. The cluster virtual machine name and the clustered disk holding the share have to be in the dependency list.
I was recently trying (and failing) to add a windows share to a folder on a Windows cluster. Windows kept throwing the following error message:
“New SMB shared folder cannot be created. The object already exists.”
I knew that the folder was not already shared and checked in the “Share and Storage Management” console to ensure that there wasn’t another folder using that share name. The question was now “Why can’t I create a windows share on a clustered disk?”
I dug around in the failover cluster manager and checked all areas, trying to find something that wasn’t right. Low and behold, there was a missing dependency between the clustered fileserver service and the physical disk that it was serving.
When you run a cluster and want to serve files from it, a separation between the physical storage resource and the logical storage location is made (to allow failovers and multi-node access to the storage). Windows adds a file server service into the cluster which then serves the underlying storage to user requests. As the fileserver service can only serve data when the storage is physically available, the service has a dependency on that storage. This, and any other dependency, is stored as a property of the service that is running. You can see these dependencies by viewing the properties of any clustered service, application or resource.
For easier viewing, you can also run a dependency report at the service level. This will create a detailed html style report showing which dependencies exist.
I had recently moved a lot of storage subsystems around on this particular cluster, which removed some drives and added some new ones. Through this housekeeping work, the dependencies of the cluster had been removed. This didn’t have any adverse effects, as the dependencies to other services ensured that the fileserver always had access to the underlying drives.
As soon as the missing dependencies had been re-instated I was able to create new shares on folders stored on those disks.
The error message thrown by windows is very misleading. It states that the share already exists, when what really should be thrown is an error saying the storage dependencies are not OK.
Lesson learned: Always check your dependencies when you are making changes to cluster resources!