Hello everyone.  The short story to my current issue is that I can no longer access the files on my UNRAID Server from my laptop anymore.  I used to have my server mapped as a drive on my laptop and was able to access and do anything with the files that way but now I cannot.  I can still access the UNRAID WebGUI, I can still access the files from my Windows VM, and my wife's laptop can still access them as well.

 

The long story is I heard about UNRAID a little over a year ago and started messing around with it.  Had no idea what I was doing but was able to get it up and running and everything was working great.  Then I decided to set up and run a Windows VM and that was working great too.  Then at some point I noticed that I was not able to delete files that were on my server from my laptop.  It kept saying that I needed permission from "nobody".  No idea what that was, but I was able to delete files from my Windows VM so that was the work around I was doing for months now and was ok with that.  Then I was talking to someone online about my issue and they said it sounded like a permissions issue and had me try all kinds of things.  But the things that I think were relevant to why it's not working for me now is I had tried to change the owner of the mapped drive located in the advanced Security ta in Properties.  The other thing I think may have done it was that I was suggested to remove the Windows Credentials for UNRAID.  I was told that it would fix itself then next time I tried to connect, but I haven't been able to connect again since.  It kept asking me for a username and password but I don't ever remember needing one before.  So I tried a couple things and now it doesn't even ask me anymore.  If it helps, below is a picture showing that my Windows VM can connect but my personal laptop cannot.  I hope this is enough information for you to go on and can help me gain access back.  Thank you.

 

-Clutz450

 

Edited April 21, 20215 yr by Clutz450

So update on my situation.  I started thinking that it was some kind of credential issue so I started searching that in Google along with UNRAID and came across this post here. 

 In it, it said that I need to have my username as guest with a password of 1234.  I don't ever remember having to do that on any other computer but that actually did the trick on my laptop.  I would still appreciate anybody else's input on my situation to see if there is anything else I should be looking at or doing to ensure everything is working as it should.  Thank you.

 

-Clutz450

1 hour ago, Clutz450 said:

need to have my username as guest with a password of 1234

Or you could just sacrifice a chicken.

 

While that might work accidentally there is no reason for it.

 

 

I just literally had an issue with one of my mapped drives 10minutes ago. 

 

I'm guessing some how My credentials for that drive got wacked, but deleting, rebooting and then remapping fixed it right up for me. 

Doesn't explain why the other 2 mappings worked fine, but none the less I'm golden now.

 

All 3 of my mapped drives have been error free for 3 or so years now. Today I guess was my turn to have a problem. 

On 4/16/2021 at 11:29 PM, trurl said:

Or you could just sacrifice a chicken.

 

Does eating KFC for dinner count? lol.

 

But anyway, the guest/1234 username/password trick seems to be working for me.  It was also suggested to me to use the "Docker Safe New Perms" option under Tools as well as download the "Fix Common Problems" plugin from Community Apps.  Already did the "Docker Safe New Perms", corrected the few things "Fix Common Problems" suggested, and am now doing their Extended Test which also seems to check and fix permissions of all files which seems like it is going to take a while before it finishes.  But overall, I think my issue is solved and will mark it as such.  Thank you.

 

-Clutz450

10 hours ago, Clutz450 said:

the guest/1234 username/password trick seems to be working for me. 

Anything that caused you to create new credentials would have worked, assuming the shares were public.