KeithLM Posted August 21, 2015 Share Posted August 21, 2015 This may not be an unraid problem as such, but it's something I run into every time I either make a big upgrade in samba or set up a new linux box or when I set up a new windows computer. I have multiple windows computers working correctly right now with my unraid server, but my new laptop refuses to do what I want. After I mount a private share and provide the proper credentials and tell it to save the credentials, I reboot, and I have to enter the password again. I just can't figure out what I'm doing wrong, and I don't remember that magic combination to make this work. I've tried mounting via explorer, and use the "net use" command. I've tried no domain name as well as using my server's name as the domain. I can repeatedly connect to the shares again and again, but no matter what when I reboot it refuses to automate this connection. I have done this in the past, I have two computers doing this now, but it typically takes me dozens and dozens of tries over several hours before I luck into it, so I can never remember exactly how to repeat this. Does anybody else run into this issue? Link to comment
RobJ Posted August 21, 2015 Share Posted August 21, 2015 The only thing I can think of, is try going to the Credential Manager and cleaning out all related credentials first. Link to comment
KeithLM Posted August 21, 2015 Author Share Posted August 21, 2015 Hmm, I don't see anything there. I feel like this is an issue with the order in which I access private and public shares. Like the first time I connect to the server I need to either connect to the private first or the public, then reboot. I recall on my desktop I kept encountering errors regarding using multiple credentials when connecting to the server, even though only one share is private and all the rest are public. I did something with the net command to force my way through that problem. This particular laptop is about to be returned because of a deadspot on the screen. So I'll get a fresh start on this with a clean machine. Perhaps I'll stumble upon the right pattern the first time and all will be well. Link to comment
trurl Posted August 21, 2015 Share Posted August 21, 2015 Maybe this old post will shed some light. Link to comment
KeithLM Posted August 21, 2015 Author Share Posted August 21, 2015 Oh wow, thank you. I think that does cover it. See whenever I'm setting up a new system I typically go to a public share on my server called Public to get hold of some files I have there, config stuff, certain apps, etc., and start off with those. I'm pretty sure I did run "net use * /delete", multiple times I'm sure, but something somewhere was sticking around that shouldn't have been. I did return that laptop and exchange it, so I'll give the new laptop a new name and go straight to the private share when I first access the server. Link to comment
trurl Posted August 21, 2015 Share Posted August 21, 2015 And you might also try the trick of accessing the server by IP instead of by name. That is what I usually do if I want Windows to give me a different login. Link to comment
KeithLM Posted August 21, 2015 Author Share Posted August 21, 2015 Well it's working. Mostly, but as good as I can ask for I think. I first mounted the private folder where I always have it on every system I use. Then I rebooted and it was connected just fine. So then I went and mounted the public share. I rebooted, and it gave me an error message that not all drives had been reconnected. But as soon as I clicked on the private share it came up just fine and the public one looked fine too. So I may have to contend with an annoying message on restarts, but that is all. Now if I can only remember this next time. At least that thread you linked to thoroughly explained the issue so since I now understand what is happening between Windows and Linux I'll likely remember what to do. Big thanks for the help. Saved me hours of frustrating with the new PC. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.