Access denied on migrated qtree using ndmpcopy (7.2.5.1 -> 8.0.2P6)

[#1]

Hello,

I am migrating some qtrees from one filer (FAS270 - 7.2.5.1) to another one (V3240 - 8.0.2P6). I am using ndmpcopy to copy all qtrees under volume X to the volume Y on the destination filer.

Both X and Y have mixed secutity style set. After the first copy, all qtrees were automatically created on the destination filer with the correct security style configuration. Then I was able to re-create the shares that point to those migrated qtrees.

When creating the shares, I get this warning from console:

The share name 'ABCD' will not be accessible by some MS-DOS workstations

Trying to access this share with a domain admin account gives me access denied. All permissions on the qtree seems to be identical to the source filer.

Does anyone know what could be possibily happening?

Kind regards,

Pedro Rocha

[#2]

Have you checked whether volume language is identical between old and new volume?

[#3]

Hi,

source volume is C (POSIX)

destination volume is C.UTF-8 (POSIX with UTF-8)

Could UTF-8 been messing things up?

Regards,

Pedro Rocha

[#4]

Pedro,

what's the output of the "qtree" cmd on your storage device?

It's likely that your qtree security style is set to UNIX by default for volumes on your destination filer (options wafl.default_security_style), hence why you are having issues on Windows machines.

If you are only using that volume for CIFS data, change the qtree security style on your volume(s) to NTFS and try again.

Regards,

[#5]

Hello Bertaut,

Actually all the qtrees created during the migration process through the ndmpcopy command were created with the same security style that was set on the source. So all of them are set with mixed. Is this the problem?

The strange thing is that I am able to access some of the qtrees (few of them), but not the majority. All with mixed sec style.

Regards,

Pedro Rocha.

[#6]

The mixed security shouldn't be a problem Pedro. The fact that you are able to access some qtrees is intriguing, then again the ontap code between the source and destination volumes is pretty significant. I would try to run the steps again (you could create a vol with the same specs and ndmpcopy/vol copy) and see if this issue is replicated.

Regards,

[#7]

Hey guys, I have found that the issue was somehow related to the workstation where I was making my tests. I am sorry for that.

Thanks for all efforts.

Pedro.