Jump to content
mattyx

[FIXED] Some disk directories (and user share) appear empty via SMB

32 posts in this topic Last Reply

Recommended Posts

Hi folks,

 

I'm having an issue lately on my Mac accessing Unraid shares via SMB.  The issue displays itself like this:

 

  • Opening my Photos user share via SMB results in no files (appears empty).
  • Opening disk1/Photos and disk2/Photos is the same, no files in the Finder window.
  • Opening disk[3-8]/Photos via SMB displays properly.  Files are there
  • All disks and user share display files via ssh/ls

 

My gut says this is a Mac/SMB illegal file character issue (after googling a bit), but I can't figure out a good way to grep for the illegal characters to confirm.  Does anyone have any general advice on isolating possible illegal characters?  Any other ideas what might be causing this issue?  I've done an 'ls -tr' to look for the most recent additions and manually remove commas, dashes, backslashes, etc, but that has not solved it for me.

 

Many thanks in advance for any suggestions!

 

EDIT:  Removed Mac from title, as I am seeing badness on my linux client also.

 

 

Share this post


Link to post

Colons and forward slashes are ones to look out for, too, as they occur quite often in media-related names. Does it work if you use AFP instead of SMB?

 

Share this post


Link to post

Great suggestion, John.  I just checked and clearly my SMB theory is wrong, as the same behavior exists via AFP.  Disk[1-2] are "empty" and the rest look fine.  The user share is also empty. 

 

Any ideas what might be causing this?

Share this post


Link to post

Do your shares definitely have content if you telnet into the server and ls -l /mnt/disk1 ? Try unmounting from your Mac then, from a telnet session into your unRAID server, deleting the .AppleDB folder at the root of each disk share:

 

rm -rf /mnt/disk1/.AppleDB
rm -rf /mnt/disk2/.AppleDB
...

 

and at the root of any user shares

 

rm -rf /mnt/UserShare/.AppleDB

 

Careful! rm -rf is a dangerous command but that hidden folder is safe to remove and OS X will recreate it soon enough. I don't guarantee this will help but it won't do any harm.

 

Share this post


Link to post

Hmm.  I only see the .[_.]DS_Store files.  I'm not seeing the AppleDB files in either the user share or the disk root directories.  I again did confirm that the files are all visible via ssh on all disks and on the user share, so the files do seem to still exist in place.

 

I'm tempted to start moving chunks of files to new disks via mc, but that seems tedious and not terribly elegant.

Share this post


Link to post

The .DS_Store files are everywhere - potentially present in every folder and sub-folder. .AppleDB folders only exist in the root of each volume. What isn't clear at the moment is whether this is a Mac problem or an unRAID problem. A little Googling found this - it might give a clue or two.

Share this post


Link to post

Have you tried to just let Finder sit there? I have a few folders in my share then when I first open it, it spins then tells me there are 0 files. After all the drives wake up and the caching starts, 4-5 mins the files are there.

Share this post


Link to post

What OS version are you on? I'm not seeing this behavior on 10.11.3 and wasn't seeing it on 10.10 either. I'm only using SMB at the moment though.

 

I don't have any permissions set on the SMB share(s) though. Could it be a permissions thing??

Share this post


Link to post

It could certainly be permissions related, if the Finder window never gets populated, even after waiting. Does the Finder display the rotating "please wait, I'm busy" indicator at the bottom right and if so, does it stop if you wait long enough?

Share this post


Link to post

From command line

ls -lah /mnt/user

and post the results.

Share this post


Link to post

Ok, just opened a folder. The rotating "please wait, I'm busy" indicator at the bottom right was there for 31 seconds and then it stopped spinning and now it's telling me 0 items.

 

Running stopwatch to see how long it takes before it actually shows me files.

 

2 minutes and 40 seconds later, it went from 0 items to showing 3,099 items.

Share this post


Link to post

What are your Finder View Options settings? 3099 files is a lot to have in one folder across a network, and especially so if you have, say, Show icon preview selected. How is it with less populated folders? How is it copying files? Your network hasn't dropped to 100 Mb/s, has it? Was it once much faster than this?

Share this post


Link to post

Hi folks,

 

Thank you for all of the helpful suggestions!  Let me try to answer all the questions in one go (reverse order):

 

Finder settings:  I am in list view, and when I view other disks (disk5/Photos), they appear after a small delay.  I'm thinking the finder settings are ok due to this behavior.  Happy to try other things if you disagree.

 

Rotating indicator:  On the bad disks (and user share), I never see the spinning wheel.  On the good disks, I see it very briefly (<1s), and then the files appear.

 

ls -hal /mnt/user:  I'd prefer not to post my list of directories, but I'm moderately familiar with linux permissions.  They are all "drwxrwxrwx nobody users" (777).  Was there something else you were looking for in the output of this command?

 

OS version:  I am on 10.10.5, and have only seen this behavior for the past couple weeks (I dont recall it appearing right after any upgrade).

 

Finder just sitting there:  I have let it sit on disk2/Photos since I started typing this post, and nothing has appeared.  Probably going on 5-6 minutes now.  I checked the dashboard, and all disks are spun up at the moment.

 

 

Thanks again for all of the help, sorry for the lag in response.  Busy day!

 

Cheers!

 

Share this post


Link to post

...

ls -hal /mnt/user:  I'd prefer not to post my list of directories, but I'm moderately familiar with linux permissions.  They are all "drwxrwxrwx nobody users" (777).  Was there something else you were looking for in the output of this command?

...

Maybe not an issue with Apple but many Windows users have "lost" their share by accidentally creating another one with the same name except for upper/lower case. Then Windows winds up showing only one of them and it is often empty because the user never intended for it to exist in the first place.

Share this post


Link to post

Some further testing:

 

I just also noticed that on the bad disks, the share is listed as "zero bytes" when I have calculate all sizes on my mac.

 

On my linux device, I attempted to connect over SMB and AFP.

 

On SMB:  The user share will open, but displays less than 1% of the total files in the share.

 

On AFP:  I can connect to another AFP user share fine, when I connect to the bad one I get "Sorry, could not display the contents of 'Photos on Tower': Got error 'kFPMiscErr' from server." 

 

EDIT:  Further weirdness, if I try to create a new folder from the mac in disk1/Photos, it quickly disappears.  If I then check the directory via ls, it appears...

 

Currently googling for answers, but wanted to post here in case anyone has ideas.  Cheers.

Share this post


Link to post

I think I owe John_M an apology. 

 

I was digging more into this today, and did see .AppleDB files in the root of the user share.  I attempted to rm -rf them, but I got a warning the directory was not empty (odd since I am root, and -r'd it).  I then moved into the .AppleDB directory where I see a ton of .fuse files.  I rm -r'd those, and it looked like the command executed:

 

root@Tower:/mnt/user/Photos/.AppleDB# rm -f .fuse_hidden00058c5*
root@Tower:/mnt/user/Photos/.AppleDB# ls -hal
total 15M
drwxr-xr-x 1 root   root   528 Jan 28 17:07 ./
drwxrwxrwx 1 nobody users   72 Jan 28 17:01 ../
-rw-r--r-- 1 root   root     0 Jan 28 16:59 .fuse_hidden00058c5300000060
-rw-rw-rw- 1 root   root     0 Jan 28 16:59 .fuse_hidden00058c5400000061
-rw-rw---- 1 root   root   10M Jan 28 17:00 .fuse_hidden00058c5500000062
-rw-rw---- 1 root   root   24K Jan 28 16:59 .fuse_hidden00058c5600000063
-rw-rw---- 1 root   root  3.5M Jan 28 17:02 .fuse_hidden00058c5700000064
-rw-rw---- 1 root   root   11M Jan 28 17:02 .fuse_hidden00058c5800000065
-rw-rw---- 1 root   root  160K Jan 28 17:00 .fuse_hidden00058c5900000066
-rw-rw---- 1 root   root   12M Jan 28 17:02 .fuse_hidden00058c5a00000067
-rw-rw---- 1 root   root   48K Jan 28 17:00 .fuse_hidden00058c5b00000068
-rw-rw-r-- 1 root   root  416K Jan 28 16:59 .fuse_hidden00058c5c00000069

 

But when I ls -hal after this (see above), the files still exist.  Any ideas why that might be, or other ways I might blow this directory away?

 

Mea Culpa, John_M, I think I was only looking at the /mnt/disk$ directories or something.  Dunno.  Derp.

 

I am also seeing some errors in my syslog that look like they might be related:

 

Jan 28 16:58:39 Tower cnid_dbd[23366]: Conversion failed ( UTF8 to CH_UCS2 )
Jan 28 16:58:39 Tower cnid_dbd[23366]: idxname: conversion error
Jan 28 16:58:39 Tower cnid_dbd[23366]: error deleting key/value from cnid2.db: DB_SECONDARY_BAD: Secondary index inconsistent with primary
Jan 28 16:58:39 Tower afpd[8408]: getmetadata: utompath error
Jan 28 16:59:16 Tower cnid_dbd[15223]: Conversion failed ( UTF8 to CH_UCS2 )
Jan 28 16:59:16 Tower cnid_dbd[15223]: idxname: conversion error
Jan 28 16:59:16 Tower cnid_dbd[15223]: Conversion failed ( UTF8 to CH_UCS2 )
Jan 28 16:59:16 Tower cnid_dbd[15223]: idxname: conversion error
Jan 28 16:59:46 Tower cnid_dbd[15223]: Conversion failed ( UTF8 to CH_UCS2 )
Jan 28 16:59:46 Tower cnid_dbd[15223]: idxname: conversion error
Jan 28 16:59:46 Tower cnid_dbd[15223]: Conversion failed ( UTF8 to CH_UCS2 )
Jan 28 16:59:46 Tower cnid_dbd[15223]: idxname: conversion error

 

Any smoking gun here?

 

EDIT:  Good news!  I figured out the .fuse_hidden issue, 2 processes had a lock on the files.  I lsof'd them, kill -15'd and now .AppleDB is history. 

 

Bad news:  Seems to have no change on the underlying Samba issue, but I do seem to have AFP back...

Share this post


Link to post

have you checked the permissions of the files/folders causing problems using the ls -l command from a console/telnet session?  Just wondering if that could be your issue as I do not see any mention of running Tools->New Permissions to ensure that they are all correct.

Share this post


Link to post

I did recently run a permissions fix on all drives (sorry for not mentioning).  The permissions change does not seem to have changed the Samba issues I am seeing.

Share this post


Link to post

Go to Tools - Diagnostics and post the complete diagnostics zip. I am betting on filesystem corruption.

Share this post


Link to post

The .AppleDB folders are a nuisance because files inside are kept open for as long as the share is AFP mounted, this tends to prevent disks from spinning down and the mover from completely flushing the cache pool. The contents are also changed without the access timestamp being updated, which isn't very friendly towards bit-rot detecting utilities. I thought that something might have become corrupted inside but unfortunately that doesn't seem to be the case. They contain metadata about the volume itself, including a log of recent filesystem changes that (on local disks, at any rate) Time Machine uses to decide which files to include in its next incremental backup, rather than having to scan the entire volume.

 

.DS_Store files are rather less trouble, which is just as well because they are much more plentiful - potentially one in every folder. They just contain metadata relevant to the most recent Finder view on that particular folder - icon size and layout, scroll-bar position, etc.

 

Both can be deleted, which resets everything to default and, when needed, they will be re-created by OS X. I'm disappointed this wasn't the cause of your problem, perhaps it's an unRAID issue rather than an OS X issue.

 

Share this post


Link to post

FOUND IT! 

 

There was a file with a bad character in the root of the user share.  I found it by going line by line over the files (via ls) and looking for odd names.  I ended up finding something like "/389" in the filename of 2 files.  Once I removed those, SMB is back and working as expected.

 

Thank you SO much for the help; in the end I just needed to patiently go over the files.  Hope this helps someone else.  :)

Share this post


Link to post

Glad you got to the bottom of it and thanks for reporting back. As you say, it might well help someone else.

Share this post


Link to post
On 1/31/2016 at 7:48 PM, mattyx said:

FOUND IT! 

 

There was a file with a bad character in the root of the user share.  I found it by going line by line over the files (via ls) and looking for odd names.  I ended up finding something like "/389" in the filename of 2 files.  Once I removed those, SMB is back and working as expected.

 

Thank you SO much for the help; in the end I just needed to patiently go over the files.  Hope this helps someone else.  :)

How did you go through the root with ls? I'm on a Mac, and was reading through this forum. Am I supposed to connect through telnet via terminal, type the server address in, and search through there? If so, how do I enter the user/pass for the server, or get around it? Because it doesn't allow me to enter my info. I'm in the same situation, missing files in the shared folder.

Share this post


Link to post

The telnet login is the same as the webUI login. If you haven't set a password for the webUI, then the user is root and the password is blank.

 

I do wonder if you are really having the same problem or not though. Can you post screenshots that illustrate the files actually do exist on the server but they aren't being displayed when looking over the network?

 

Might also be useful if you posted your diagnostics. Go to Tools - Diagnostics and attach the complete diagnostics zip to your next post.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now