I'm in the (rather lengthy) process of rebuilding a server which had a Motherboard USB Controller and a disk failure last week*. All of the disks are back online and/or rebuilt, the server upgraded from 4.5.1 to 5.0.5 (incrementally), and such.

 

The User Shares on my Win 7 PC required re-mapping, and everything seemed great...except that on one share, on the 3rd folder level down /ShareName/Sub1/Sub2/Sub3  Sub 3 is inaccessible. It "refers to a location which is inaccessible...".  ShareName/,  ./Sub1, and ./Sub2 all work fine, as well as all the other directories on the ./Sub3 level (8 in all).  I cannot reach it from the mapped drive letter or from the //Tower/ShareName/... hierarchy. However, I know the folder exists on the server, because I CAN get to it by going to //Tower/Disk5/.../Sub3 and all the files there are happily existing.

 

To put the crazy one notch higher, I can enter the share name of a Sub4 folder (/ShareName/Sub1/Sub2/Sub3/Sub4) and it works! But I can't then select the folder above without getting the same error.

 

I'll be moving all the files over to a new set of drives next week with a completely fresh server install, and am hoping that may remedy the situation, but until then this is going to vex me, especially since it's one of the locations I access on a regular basis  (though I've made temporary link to the Disk 5 location)

 

Any ideas on what might be giving windows fits?

 

*Technically, the USB controller failure happened sometime in the last 10 months, which is the last time the server was booted.

Sounds like a permissions issue.  Did you run the New Permissions Utility on the v5 series?

To see the permissions in unRAID, from console or telnet

ls -al /mnt/user/ShareName/Sub1/Sub2/Sub3

for example

I had run the permissions update, so I'm fairly certain at this point this is some odd windows issue. Permissions look fine using ls. My laptop failed to see any of the drives, but (I presume) it's because I had logged in with root credentials for the mappings on the old drive in order to get W8 to see the drives. Remapping by logging in with a new name and no pwd seemed to fix that (W8 won't, apparently, let you change to no username).

 

[sOLVED]

 

Removing the mappings, *Deleting the server in the Credential Manager* (using Start|Search for Programs and Files, then select Credential Manager from the list) and rebooting to free up all of the mappings or open connections allowed me to remap with no problems.  At one point I mapped top the server with my root username and pwd, even if I didn't need to. 4.5.1 didn't seem to mind that, but keeping those for 5.0+ was a problem. In order to make Windows forget that the server user/pwd existed, it had to be deleted from the Credential Manager so I could start "fresh".

 

Note that the Credential Manager worked on W7, though I have not yet done that for W8 (which I need to do to remove the username I entered in the step above) and I expect that will fix everything.

unRAID v5 and above does not allow SMB connections as root. If you need anything other than public shares you need to create unRAID users, either with the same names as your Windows users, or you can just respond to the login box Windows throws up.