That was one of the main questions.

"Can we rename the path with no issue to users?"

In this case, we may have to move to a NEW folder structure which I am fairly certain is going to cause some major issues with users finding their shares, SMB links, etc.  Like -- a major headache.  Going forward this is the plan for standardization but that doesn't solve the inherited configurations which we would like to fix with minimal impact to users.

Usually about this time Dynamox would chime in and be "The Answer Man", hah.

I never liked the idea of /ifs/data/ as being the main share.  That's one extra level I felt wasn't needed and the higher up the tree we can go, the easier it goes for chargeback.

In my experience, this should work fine with no impact on the clients other than needing to reconnect. I believe that the isi smb modify command will allow you to change the path without deleting/recreating the share, so even better, but I am not quite certain of that.

I am wondering why the two steps; to my mind, those are the same thing. Unless you mean create the new path and then move the data to the new path.

So are your smb shares at the FOLDER level or at the data level?

We've never used the /ifs/data construct for data.

These are all mapped drives through active directory, SMB links.

Brian,

i have not had to do this within the same cluster. For one thing folder being moved will need to have its and subfolder quotas removed otherwise mv will be blocked. Also be careful about smb sessions, i had an instance where share was removed yet Mac users were still able to write to the old location. Once they rebooted they were redirect to the new location and they started screaming that all recently created data was gone. Well it was not gone, it was still located in the old location.  You have a slightly different scenario here but something to consider. Also think about SyncIQ polices if any.

@cariliek:  at the /ifs/DATA level.  We want to move them into a folder straight off of /ifs instead.

@dynamox:  I would remove the quotas and reapply them after the move.  What I am concerned about is the file structure as it relates to the folder paths. If I change the path, do the DFS links have to be changed as well?  And yes, FULL SYNC is going to required again but we'll have backup copies in the meantime.  I really need to answer quickly as to how we can do this safely, effectively with minimal impact to users.

Brian_Coulombe_Disney,

Working to see if I can find away to do this with minimal impact.

How are your users connected to the shares? via a mapped drive or utilizing UNC path?

Dynamox,

Some good things to think about there as well. Quotas and SyncIQ policies, I did not cover those in the test I did but, they would need to be addressed as you said. Good info!!

In regards to the Mac clients, I would assume that killing lwio would force them to the new share path. Unfortunately I do not have a Mac client to test on.

Ah, I misunderstood. Yeah, there's no way you're getting away with this without the SMB clients disconnecting/reconnecting.

Dynamox,

Yup, all SMB client connections will be effected from killing lwio.

First paragraph of my response covers that

"Or I can kill lwio to force all SMB clients connected to the cluster to reconnect."