Administrator Guide

SMB Maximum Connections Reached
Description The maximum number of SMB connections per NAS controller has been reached.
Cause Each NAS appliance is limited to a certain number of connections.
Workaround
If the system is in an optimal state (all NAS controllers are online) and the number of SMB clients
accessing one of the NAS controllers reaches the maximum, consider adding another NAS appliance.
If the system is in optimal state (all NAS controllers are online) but the clients are significantly unbalanced
between NAS controllers, rebalance the clients using Storage Manager.
If the system is in a degraded state (one or more NAS controllers are down) and the SMB clients are
connected to the remaining NAS controller, wait until the system returns to optimal or decrease the
number of SMB clients using the system.
SMB Share Does Not Exist
Description Client attempts to connect to a nonexistent SMB share.
Cause
Spelling mistake on client side.
Client is accessing the wrong server.
Workaround List the available SMB shares and verify that all SMB shares are displayed and nothing has changed
unintentionally.
Verify that you can access the problematic SMB share using a Windows client:
1. Click Run.
2. Enter the client access VIP and share name: \\<client_VIP_or_name>\<SMB_share_name>
SMB Share Name Truncated In Event After Mapping SMB Share
Description
After a client maps a SMB share, the following event is generated and the SMB share name is truncated in
the event. In this example, the SMB share name is share1_av.
SMB client connection failure. Un-available share \\172.22.151.106\share1_a
Cause This is a known issue with Windows. Windows attempts to map the SMB share by its name and also by the
name truncated by one character.
Workaround This event can be safely ignored.
SMB Path Share Not Found
Description
Client accessed a share that refers to a nonexistent directory in the NAS volume.
Cause This error usually occurs in one of the following scenarios:
The FluidFS cluster is restored from a backup or remote replication. During restore time, the directory
structure is not complete and a few directories might not exist.
When a client with an authorization to access a higher directory in the same path deletes or alters a
directory that is being mounted by another client. When multiple clients are accessing the same data set,
it is recommended to apply a strict permission level to avoid this scenario.
Workaround
1. If the FluidFS cluster is being restored, communicate the current status to the client and instruct the
client to wait for the restore process to complete.
2. In the case of another client deleting or altering a directory, there are three options:
Restore the problematic path from a backup.
Manually create the missing directories to enable access. Clients receive errors when trying to access
existing data in a deleted path.
Remove the SMB share and communicate this to the client.
3. List all available SMB shares on the FluidFS cluster and identify the problematic SMB share. It must have
an indication that it is not accessible.
FluidFS Administration 461