If this works, please respond back to the group so we can understand the behavior.

Thanks!

Andrew Chung

EMC²| Isilon Storage Division

Practice Architect

This happened recently to one client I was involved with and support was able to eventually get them up and running again.  Common denominator is you are both running v7.0.2.1

So just to mention it, even if you go into the CLI and attempt to list the shares using the v7.x syntax, you will likely also not be able to view them.  What fixed it for the client was to use the original v6.5 syntax to create a new share (via: isi_classic) and then the webui fixed itself.

1) Create a new directory for example:

mkdir /ifs/data/fixMe

2) Create a share using the original v6.5 syntax

isi_classic smb share create --path=/ifs/data/fixMe --sharename=fixMe

3) Return to the shares view within OneFS GUI.

Can you confirm the same?  You should be back in business.  You can then of course delete the above share and directory.

Thank you for the suggestion.  Here is what I did:

So the classic list worked.  The share was created.  isi smb shares list did not show the shares and the webUI is still not populating the shares.

Thanks for the quick response.  Correct as you experienced, until this is resolved, you won't be able to view/create with isi smb (v7.x syntax), just isi_classic smb (v6.5).

Hmmm... at this point not certain.  If you haven't already, can you open a ticket with support?  I will pm you the support ticket number of the incident I mentioned above and can you include that as reference for whomever is assigned your SR?

Thanks for your assistance.

So essentially one of the shares has some corrupt information.  If you just need to move on then you can start deleting shares 1 at a time until the situation is resolved.  You could use the isi_classic command to look at each share to get the info before you delete it so you can then immediately re-create the share.  I would start with the newest shares you created and work backward.  You don't have too many shares so it may not be too bad.

The other alternative is to open a support ticket and have it worked on by support.

We have a second cluster also running 7.0.2.1 that has the same behavior.  I just deleted all the shares except ifs.  No change.

Then rebooted the cluster.  The webUI shows only 1 share is present on the cluster.  In the list it still shows "Loading records..."  CLI shares list command still does not work:

isiclus-01-1# isi smb shares list

Not all share variables set: No error: 0

isiclus-01-1# isi_classic smb share list

SMB Shares:

ifs

isiclus-01-1#

mkuhns,

Have you followed-up with support?  I have received confirmation that they have acknowledged and identified the bug and now have a process to rectify it.  It involves cleaning up the gconfig database manually.

Thanks for checking in on this.  I have contacted support and they did identify the issue.  The fix is scheduled to be in an upcoming patch.

We are waiting for that patch instead of having support do the database clean.

Still waiting on the patch with the fix.  Looks like there are several other fixes they are trying to fit into this patch.