mattyx Posted January 27, 2016 Share Posted January 27, 2016 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. Quote Link to comment
John_M Posted January 27, 2016 Share Posted January 27, 2016 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? Quote Link to comment
mattyx Posted January 27, 2016 Author Share Posted January 27, 2016 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? Quote Link to comment
John_M Posted January 27, 2016 Share Posted January 27, 2016 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. Quote Link to comment
mattyx Posted January 27, 2016 Author Share Posted January 27, 2016 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. Quote Link to comment
John_M Posted January 27, 2016 Share Posted January 27, 2016 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. Quote Link to comment
mgworek Posted January 27, 2016 Share Posted January 27, 2016 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. Quote Link to comment
acurcione Posted January 27, 2016 Share Posted January 27, 2016 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?? Quote Link to comment
John_M Posted January 27, 2016 Share Posted January 27, 2016 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? Quote Link to comment
trurl Posted January 27, 2016 Share Posted January 27, 2016 From command line ls -lah /mnt/user and post the results. Quote Link to comment
mgworek Posted January 27, 2016 Share Posted January 27, 2016 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. Quote Link to comment
John_M Posted January 28, 2016 Share Posted January 28, 2016 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? Quote Link to comment
mattyx Posted January 28, 2016 Author Share Posted January 28, 2016 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! Quote Link to comment
trurl Posted January 28, 2016 Share Posted January 28, 2016 ... 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. Quote Link to comment
mattyx Posted January 28, 2016 Author Share Posted January 28, 2016 Ahh, I see. I can confirm I am not in that state. Quote Link to comment
mattyx Posted January 28, 2016 Author Share Posted January 28, 2016 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. Quote Link to comment
mattyx Posted January 29, 2016 Author Share Posted January 29, 2016 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... Quote Link to comment
itimpi Posted January 29, 2016 Share Posted January 29, 2016 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. Quote Link to comment
mattyx Posted January 29, 2016 Author Share Posted January 29, 2016 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. Quote Link to comment
trurl Posted January 29, 2016 Share Posted January 29, 2016 Go to Tools - Diagnostics and post the complete diagnostics zip. I am betting on filesystem corruption. Quote Link to comment
John_M Posted January 29, 2016 Share Posted January 29, 2016 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. Quote Link to comment
mattyx Posted February 1, 2016 Author Share Posted February 1, 2016 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. Quote Link to comment
John_M Posted February 1, 2016 Share Posted February 1, 2016 Glad you got to the bottom of it and thanks for reporting back. As you say, it might well help someone else. Quote Link to comment
YouinAnotherform Posted December 23, 2018 Share Posted December 23, 2018 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. Quote Link to comment
trurl Posted December 23, 2018 Share Posted December 23, 2018 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. Quote Link to comment
Recommended Posts
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.