Explorer crashing when searching and naming folders on mapped drives in Win10

[FloodlightMedia]

Hi,

Our office has recently noticed a problem with Windows Explorer crashing a lot when people on Windows 10 Anniversary Edition computers try to search or create/rename a folder on a mapped drive.

This problem doesn't seem to affect our Windows 8 computer, and doesn't seem to be an issue when browsing the network share in a non-mapped path. It does occur on both of our NAS boxes though (one is a nightly backup).

A major source of this issue was a particular folder full of many files with long filenames that seems to be behaving fine since I moved it to a top-level location. This leads me to think that path + filename length might be related. On the other hand, mapping directly to that folder before I moved it (to attempt to bypass the length of the path) made no difference. Therefore I wonder if any possible path length issue is on the NAS rather than Windows?

Are there any known limitations in this area? If so, do the NAS and volume names count towards such a limit?

Quick stuff:

Firmware 6.6.0

Have rebooted the NAS boxes.

Have stopped and restarted SAMBA.

Thanks

[FloodlightMedia · Accepted solution]

It appears that an OS Reinstall has resolved the crashing issue, as far as we can tell. It was likely linked to the problem with data not getting deleted.

[StephenB]

OS software manual for 6.6 (page 45): http://www.downloads.netgear.com/files/GDC/READYNAS-100/READYNAS_OS_6_SM_EN.pdf

 A shared folder can contain subfolders to help you organize your data files. If all characters in the file or folder name are alphanumeric, the maximum length of the name is 255 characters. If you use other kinds of characters, the maximum length might be reduced. For example, if a file or folder name uses Kanji or Hanzi characters, the maximum length of the name might be 83 characters.

It says nothing about path.

[steveoelliott]

I would almost certainly say this was a client / OS specific issue.

My suggestion would be to prove that this ONLY happens on the Windows 10 machines and delve further from there. This likely affects file sharing irrespective of the server platform and you may find a wealth of information / troubleshooting advice on Google once you can be sure this is Windows 10 specific.

Lastly things like antivirus, firewalls etc can have an impact, have you disabled them? You could make one machine the test bed and take everything off it and see if the issue persists.

These things can be painful to identify...

[FloodlightMedia]

Yeah, I did a bit of elimination with antivirus and everything. It didn't seem to change anything. I'll have more opportunity to try later this week.

After finding out that it's possible to instantly move files on NAS through Explorer (20TB is a lot do via a 'cut and paste' network move 😛 ), I'll be trying that first to simplify the depth of the folder structure.

[FramerV]

Hi FloodlightMedia,

Thanks for the updates.

Please feel free to inform us through this post also.

Regards,

[FloodlightMedia]

Edit: An OS reinstall resolved the below. It's actively finding the space in front of my eyes now. I'll leave it for the reference of anyone else who has problems. Hopefully it also resolved the initial problem.

So I don't know if this is related, but it was brought to my attention that deleting files no longer frees up any space on the NAS. That's a big problem, since it's nearly full and new data needs to be put onto it.

As you can see in the screenshot below, only 18.3TB is 'consumed', but less than 700GB is free on a 21.81TB volume.

I read a bunch of other threads and this KB article on this problem, but we don't have snapshots, and running both balance and defrag only slightly *increased* the disk usage. I haven't scrubbed yet because that takes days, and everything I read suggests that it can't actually fix anything anyway (we use RAID 0).

I logged in via SSH in Putty and tried the commands

# btrfs fi show
# btrfs fi df /data

But they just immediately bring up another blank command prompt, so I'm not sure what I'm doing wrong there.

The files were deleted via Windows Explorer, but they are also absent when I look at the relevant folder in the browser Admin page.

Any thoughts?

I think I'm going to do an OS reinstall, especially since DHCP also started freaking out recently. I really don't want to have to format everything again. I only did that a few months back and it was a huge hassle with this much data.

[FloodlightMedia · Accepted solution]

It appears that an OS Reinstall has resolved the crashing issue, as far as we can tell. It was likely linked to the problem with data not getting deleted.

[steveoelliott]

Hmm... I think everybody would be keen to know the root cause of this. Did your raise a case and / or provide logs to the ReadyNAS experts?

Also you original question was very different to the problem described in the solution where you were having issues around free space. It is this I am very keen to know the root cause of.

[FloodlightMedia]

No, I didn't raise a case. These NAS boxes seem to have software problems all the time, and only an OS or full wipe ever seems to fix them. My best guess is that the software upgrades tend to break stuff.

In regards to how the two issues here were linked, I see them as both being about the NAS failing to accurately tell what data should and shouldn't be there, but that's only a guess. An OS reinstall is a very easy fix, so I'm fine with it for now.

[steveoelliott]

It is a shame a case wasn't raised and did you collect any logs etc before do the SW re-install?

Ideally having one of the experts take a look would have been the best course of action rather than the OS re-install. It would have avoided the tremendous effort and potentially they would have identified root cause for the future.

[FloodlightMedia]

Are you confusing an OS reinstall with the factory default reinstall? It only took like 2 minutes, and the only thing I had to fix afterwards was ReadyCloud. Honestly, I feel like there's room for a more comprehensive wipe that deletes more stuff while leaving only the volume intact, but that may be a lot harder than it sounds.

As for logs, I only know of the ones in the Admin page, and they never said anything was wrong, just that we were running out of space.

[steveoelliott]

Oh OK... So you just did the OS re-install and then fixed it. Very odd...

The logs you see in the GUI are a tiny proportion of the full logs available... If you go to download the logs and peruse them, you will see for yourself that they are VERY extensive. There would be a host of information within these that would help in potentially diagnosing issues such as this.

You can almost think of the GUI logs like your cars dashboard. It may give you notifications and warnings but won't give you the wealth of information available within the cars ECU / diagnostics.

[FloodlightMedia]

Ah, cool. I'll keep that in mind for future problems.