The transition to NetApp MS Azure AD B2C is complete. If you missed the pre-registration, you will be invited to reigister at next log in.Please note that access to your NetApp data may take up to 1 hour.To learn more, read the FAQ and watch the video.Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.
I have a NetApp system running 7-mode which we stopped using for a while. I need to access some CIFS data on the storage. The DC that was in use has been decommissioned, currently using a new one. I used 'cifs setup' to configure the new DC but was having permission issues when I tried to access the files. Using 'cifs setup' i configured WORKGROUP and created a user with all access on the filer, some folders can be accessed (even though you can't copy the files) whiles some folders give 'access denied'. Kindly assist on the workaround for this issue, I need those files urgently.
I think that the easiest and most supported way to guarantee access and copy off the files is to have a domain or local user a member of the "administrators" and "Backup Operators" groups - verify with:
#for local user
useradmin user list -g Administrators
useradmin user list -g "Backup Operators"
#for domain user (and use "cifs lookup SID" for any SID's you see)
useradmin domainuser list -g Administrators
useradmin domainuser list -g "Backup Operators"
And to have that the same user /group with full_control on the share level - verify with command:
Once you have set this. Open a CMD as admin on any windows device, using the below "net use" commands map the source (with the above user) and destination as drives within the same CMD window. And copy the files of using robocopy with the /B option (see my favourite flags below, but do check it applies to your needs before using it)
net use s: \\src_filer\c$ /USER:filer_or_domain\username
net use t: \\dst_filer\c$ /USER:filer_or_domain\username
robocopy "s:\share\folder" "t:\share\folder" /COPY:DAT /MIR /r:2 /w:1 /b /XJ /MT:8 /log+:"c:\temp\robocopylog.txt"
# Gidi's favourite robocopy flags:
/COPY:DAT, D=Data, A=Attributes, T=Timestamps (not including security and audit ACL/DACLs).
/MIR, MIRror a directory tree.
/R, number of Retries on failed copies (low to avoid long waits).
/W, Wait time between retries (low to avoid long waits).
/B to use backup operator priv for read
/XJ eXclude Junction points and symbolic links
/MT Multitrhead - i usually put twice as the amount of cores the system has.
/log+, output status to LOG file (append to existing log).
Again, that's the easiest and most supported way to do it. there some others dirty ways like manipulating user mappings so it ignores NTFS ACLs (i don't have simulator at hand to easily confirm the commands) , reset ownerships and then ACLs (takes time, require multiple runs and sometimes fails), or make the filer applying new set of ACL on the path (takes long time).
If you do need more help or to explore the above options - give a shout and I'll try to share more.
1) Use \\IP\share : Using the IP address, will skip kerberos and fall back on NTML authentication is used. Are you able to access the shares?
2) As you mentioned, old cifs and new cifs server name is 'same', so I suggest set the SPN:
Have a user, who is a member of Domain Admins, run the following from a command prompt: Set SPN for vsdata1: C:\>setspn.exe -S HOST/FILER01 C:\>setspn.exe -S HOST/FILER01.kitc.org C:\>setspn.exe -S cifs/FILER01 C:\>setspn.exe -S cifs/FILER01.kitc.org
C:\>setspn -L FILER01 <now you should see all the SPNs attached>