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


mattyx

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.

 

 

Link to comment

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.

 

Link to comment

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.

Link to comment

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.

Link to comment

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?

Link to comment

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!

 

Link to comment

...

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.
Link to comment

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.

Link to comment

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...

Link to comment

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.

 

Link to comment

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.  :)

Link to comment
  • 2 years later...
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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.