2012-07-11 08:24 AM - edited 2015-12-18 02:59 AM
Nice challenge, and I hope someone could help me.
I'm a provider of remote backup with OSSV. Until today, each of my customer have it's own vFiler as secondary snapvault, and this vfiler is joined to the customer AD domain. The snapvault qtree are shared with CIFS and I add a shrotcut to my customer to acces the history and drag and drop the desired file. No problem.
But the number of vFiler is limited. I expect more than 64 customers :-)
So I decided to create one vFiler for more than one customer and so to leave the vFiler outside of the AD domain of the customers. Good idea ? no...
As you know, the ACL of the primary server are also snapvaulted to the secondary. So when the customer try to access the cifs shares of it's own snapvaulted qtree, he receive an access denied, because the vFiler cannot authenticate the user belong to the customer AD. So I create a local user of the vfiler, but a local vFiler user is not listed in the ACL of the qtree file. So I add the shared vfiler to a dedicated domain and give a special username/password to the customer, but same result....
Perhaps (not tested yet), instead to share the qtree with CIFS, I could export to NFS? but my customer need a NFS client on it's Windows box. It could work ? To convert the qtree to UNIX style, the ACL should be deleted, and I create a UNIX user wich as full access to the qtree.
Has someone a good idea to give the ability to my customer to "self" restore it's own file with drag and drop ?
Thanks for your comment