it all works fine until until it gets to the New-NaCifsPasswordFile command. when entered above it prompts for a password and if i enter 1$netapp it says it changes the password but it won't let me log in using the username root with the password 1$netapp.
if i use the "-password 1$netapp" switch it says it changes the password but i can't log in using root/1$netapp
If use the "-password $password" switch it errors out. it seems that i can't use the $password variable i'm setting earlier in the script.
I'm lost and can really use some help with this.
in case you are curious about the abnormally long timeout, i had a lot of issues with thee 8.0.1 simulator. it seems to have random connectivity issues. 7.3 didn't have this. i have putty disconnect issues in the 8.0.1 version and script connectivity issues that i didn't have in 7.3. but the script issues were fixed by just making a long timeout.
I haven't forgotten about you... It's just required a little more testing than I anticipated. It seems the ZAPI command that New-NaCifsPasswordFile uses doesn't work quite like the console "cifs setup" command. In particular it won't actually create a new root user for the filer, and it doesn't actually update the root user's password. At least in my testing I was still able to log in fine with the "old" password.
The other gotcha I ran into was setting up cifs for workgroup authentication. I had to dig around a bit to discover that the "-Domain" parameter ("domain-info" in ZAPI) is used to specify the workgroup like this:
the workgroup setup part was next after the file creation. My total script is actually pretty long, I was just pasting in the parts up to the failure. here is the script up to the line that you are talking about adding.
New-NaCifsPasswordFile -Password "1`$netapp" -controller $ss1filer (fails or changes the password to an unknown string)
Set-NaCifs -controller $ss1filer -CifsServer ss1 -AuthType workgroup -SecurityStyle multiprotocol -Domain NETAPP (fails because missing /etc/passwd file, or fails because it does change the passwd and now i don't know what it is)
here is the problem. on a new storage system that nas never been set up before there is no /etc/group or /etc/passwd file. so if you try to run the "Set-NaCifs -CifsServer" command it fails because the files are missing. so i added the two previous lines to add the files. the /etc/group file creation works fine. the /etc/passwd file creation is a mess. i'm tempted to call it a bug at this point.
if i cheat and run cifs setup on a controller, then unlicense cifs i can run the entire script including the "Set-NaCifs -CifsServer" command and everything works like a champ (i remove the New-NaCifsGroupFile and New-NaCifsPasswordFile commands). i'm tempted to do that but i'd prefer to start with a system thats totally new, never been touched.
I was able to reproduce the issue after disabling "security.passwd.rules.enable" and it looks like a problem with the toolkit (or at least one we can fix in the toolkit). We are not encoding the password information correctly for the New-NaCifsPasswordFile command.
Until we can get a fix in, there is a quirky little workaround/special case I found where you can use an empty password:
PS C:\> New-NaCifsPasswordFile ''
Here's the weird part. At this point if you have password rules enabled, your password did not change because it silently failed validation. If you had password rules disabled, your password is now empty/blank. You can reconnect and set your password back with Set-NaUserPassword. Either way the file gets created and it doesn't really matter if the root password in that file is correct.
I tested this on 8.0.1, I'm not sure if it will work the same way on 7.3x.
Thanks for bearing with me. Let me know how your script turns out.
This will be fixed in the next release of the toolkit (1.5). In addition, the password parameter will be optional. If you omit it (which I'd recommend) it will create the file without changing the root password.
I don't believe there is a target date set yet. But, the big picture goal is to put out one release approximately every quarter. Since 1.4 just came out a few weaks ago, I expect 1.5 will follow in a few months.
If you want a very similar workaround today, you can create the passwd file yourself like this:
The "*" for the root password is an invalid hash, which will basically disable root access for the very few access schemes that authenticate against the file (e.g. CIFS configured for "passwd" authentication, PCNFS, or FTP with unix security & file authentication). Most of the time that file is ignored or only used to map Unix IDs to user names.