After a weeks worth of debugging, I finally solved the issue.
When I tried to use SMBPASSWD to verify my password, I was getting an error. I figured that it’s probably because there isn’t a user account setup (even though the dashboard reflects that there is a user). When I was checking the passwd file (in \etc), it didn’t have my account name listed.
I tried the USERADD command and it failed with “Unable to lock password file”. I did some searches on this and found that I should remove passwd.lock from the \etc directory. I downloaded the file to my machine and then deleted it on the My Book.
I ran the USERADD command again and it failed with “cannot lock shadow password file”. I did the same procedure as above but with the shadow.lock file.
I deleted and recreated my account via the dashboard. I tried USERADD one more time and this time it failed with "user erick exists".
I tried accessing the private share and bingo. I got in. I confirmed the log.smbd log and it showed that it was my user account accessing it, not the guest account (named nobody).
So the lock files (dated 9/28, about how long I have been working on this) locked out the dashboard from making any changes to the actual underlying files themselves.
Note that I wasn’t doing any work with the SSH client before this problem. All configuration changes were made via the dashboard. It was only when I couldn’t get to any private shares that I enabled SSH to do the troubleshooting myself.
I can now access the file shares and prevent access to shares that I don’t want others accessing.
I have posted this so it can help others who may run into the same issue.
