April 21, 200917 yr This issue has been solved for me - jump to my last post on 05/19/09 to see the solution. Read on here for more problem description and what we tried... I started this topic on a different thread, (http://lime-technology.com/forum/index.php?topic=3156.0) but it really wasn't appropriate based on the topic of that thread so I'm starting it here with more information. I'm running unRAID 4.4.2 (free version - 3 drives) and my clients are all Macs (10.5.6). I've got a few samba shares, all export read/write. My disk & flash shares are export read/write, hidden. I have no NFS shares setup. Shortly after booting (or rebooting) the unRAID server, everything works just great. After "a while" (somewhere between 12 and 36 hours) I loose access to the user shares. They still show up in Finder and (sometimes) I can drill down a directory or two, but they're really not there. I can't read/write any files. If I unmount the shares they won't mount again. Trying to mount from Finder gives me an "error code -6602" (can't find this error code anywhere) Trying to mount from the command line give me "mount_smbfs: mount error: <mountpoint>: Broken pipe" If I browse the network in Finder, I can see the server and the user shares but when I click on one I get "The operation cannot be completed because the original item for <sharename> cannot be found." If I try to mount any of the disk shares, they work just fine. This only happens with user shares. When this happens, it happens for all the Mac clients. I don't have any Windows clients so I can't check to see if those would be effected (If you think that would help, I can setup a Windows client and see what happens with one of those.) Rebooting the Macs doesn't help. The only solution I've found is to reboot unRAID. Then everything works fine again for "a while". This might only happen when there is no activity for that long - I seem to remember some long video encode jobs that I was doing directly to a user share that lasted a lot longer than that and it didn't happen. I can setup something like that again if you think that would give a clue. There's nothing in my syslog since boot time so I can't find anything there. Any ideas? UPDATE: This last time, before rebooting the server, I thought I'd try just stopping and restarting array (using the standard web interface). When I restarted the array, disk shares could still be mounted from the Mac but not user shares. When I went to the Shares page on the web interface, ALL my user shares were GONE!!! After rebooting the server, my shares show up again in the web interface and they can all be mounted from the Mac again. Looks to me like there's something wrong with my server. Now to just figure out if it's a problem with unRAID, my configuration, or with something I did (didn't do much but add some user packages with unMenu). Consequently, I changed the subject from "Loosing user shares on Mac clients" to "Loosing user shares on 4.4.2". Hope that gives someone another clue...
April 21, 200917 yr Thank you for taking the time to add all of the details, that is helpful. If you don't mind, please attach the current syslog anyway, there might still be something unusual during the boot, specific to your system. And could you provide some details of your unRAID hardware, motherboard, RAM, disk controllers, drives, PSU, ... My first suggestion is to return to a completely stock unRAID, no addons at all, and the original go file, and let us know of any differences in behavior. Afterward, you can start adding tweaks and addons back, and testing.
April 21, 200917 yr I am running a few addons and don't currently have the time to mess with the server and do some digging around… but when I get a chance and this problem happens again I will try a few different things. 1. Check to see if the shares are still available from a windows machine 2. Reboot my Router to see if that fixes it 3. Reboot my computer (this usually fixes it for me) I will also check to see if the disk shares are still available but I think they were for me last time also. I remember this because I needed to copy something to the server and the shares stopped working so I loaded up the disk directly and copied to it.
April 21, 200917 yr Author RobJ, Thanks for the response: Thank you for taking the time to add all of the details, that is helpful. If you don't mind, please attach the current syslog anyway, there might still be something unusual during the boot, specific to your system. And could you provide some details of your unRAID hardware, motherboard, RAM, disk controllers, drives, PSU, ... My first suggestion is to return to a completely stock unRAID, no addons at all, and the original go file, and let us know of any differences in behavior. Afterward, you can start adding tweaks and addons back, and testing. A couple questions about how to do what you recommend: If I boot from a flash drive with stock unRAID on it, will I loose my settings (i.e. user shares, split depth, export settings, server name, etc.)? I'm new at this - is all that is on the flash / none of that information is on the hard drives? If so, how do I revert to a stock install but keep my settings (maybe there's just a file I need to preserve?)? Alternately, can I boot from the stock flash, re-enter my settings and not loose the data that's already out on the hard disks? I've attached the current syslog. Note this is with my current configuration (haven't gone back to stock install yet). At this time, the user shares are working as expected (since the reboot last night). My system configuration is in my signature (I think it's fairly complete). If you have questions about that let me know (some of my abbreviations might not be obvious). Thanks.
April 21, 200917 yr RobJ, Thanks for the response: Thank you for taking the time to add all of the details, that is helpful. If you don't mind, please attach the current syslog anyway, there might still be something unusual during the boot, specific to your system. And could you provide some details of your unRAID hardware, motherboard, RAM, disk controllers, drives, PSU, ... My first suggestion is to return to a completely stock unRAID, no addons at all, and the original go file, and let us know of any differences in behavior. Afterward, you can start adding tweaks and addons back, and testing. A couple questions about how to do what you recommend: If I boot from a flash drive with stock unRAID on it, will I loose my settings (i.e. user shares, split depth, export settings, server name, etc.)? I'm new at this - is all that is on the flash / none of that information is on the hard drives? If so, how do I revert to a stock install but keep my settings (maybe there's just a file I need to preserve?)? Alternately, can I boot from the stock flash, re-enter my settings and not loose the data that's already out on the hard disks? All of your settings are in the "config" folder. You can copy that folder from the one flash drive to the other and keep all your settings. You will want to use a "stock" config/go file. Do not copy it from the old flash drove to the new. Yes, you could just re-define your config options and re-assign your disks on the new flash drive instead of copying the config folder. Just make sure you get the parity drive assigned correctly to the same physical disk when you do the device assignments. (The others are not as critical) When you finish the copy, make sure the "config/go" file does not have any of the lines you might have added. I've attached the current syslog. Note this is with my current configuration (haven't gone back to stock install yet). At this time, the user shares are working as expected (since the reboot last night). My system configuration is in my signature (I think it's fairly complete). If you have questions about that let me know (some of my abbreviations might not be obvious). Thanks.
April 21, 200917 yr Author OK - Preserve the /Config directory except for the Go file. Everything else (including the Go file) gets replaced. Thanks, Joe
April 21, 200917 yr A couple questions about how to do what you recommend: If I boot from a flash drive with stock unRAID on it, will I loose my settings (i.e. user shares, split depth, export settings, server name, etc.)? I'm new at this - is all that is on the flash / none of that information is on the hard drives? If so, how do I revert to a stock install but keep my settings (maybe there's just a file I need to preserve?)? Alternately, can I boot from the stock flash, re-enter my settings and not loose the data that's already out on the hard disks? Sorry, did not mean to over-complicate this. All you need to do is either rename your current go file and temporarily use the original one from any unRAID distro, or place pound signs (#) in front of anything that you have added to your go file. There's no risk of data or settings loss. Everything will stay the same, except that your addons and tweaks will not start. Adding preceding pound signs to a line in a script causes the line to be treated as a comment to be ignored, instead of being executed. It is an easy way to temporarily disable something, knowing it is easy to re-enable by removing the added pound symbols, and rebooting. I've attached the current syslog. Note this is with my current configuration (haven't gone back to stock install yet). At this time, the user shares are working as expected (since the reboot last night). Like you, I don't see anything unusual. Unrelated issue, you are starting the APC package twice, so you should pick one, and remove the other from starting. The first one that starts seems to be working correctly, as it handled a brief power outage. This syslog has unusual end-of-lines, a combination of DOS and Mac ones. It consists of a pair of carriage-returns followed by one line feed. My system configuration is in my signature (I think it's fairly complete). Sorry, I did not notice your sig.
April 21, 200917 yr Author Sorry, did not mean to over-complicate this. No worries. I'll go back to stock this evening when I get back home. This syslog has unusual end-of-lines, a combination of DOS and Mac ones. It consists of a pair of carriage-returns followed by one line feed. That's probably from a combination of capturing the syslog by tunnelling home to my Mac (using unmenu), emailing it to myself from the Mac using "Send Windows-friendly attachments", saving it to my Windows machine here at work (taking a peek at it) and then attaching it to the thread -- Now that I spell it out it doesn't seem quite as simple as I did a minute ago... Thanks for the catch on the apc package, too.
April 27, 200917 yr Author Sorry, it's been a while since I gave an update on this. I thought I was onto something for a while. It seemed that the loss of my shares was related to the use of OS-X Sparse Bundle images on user shares (i.e. Time Machine backup, iPhoto Library in a Sparse Bundle, etc.). It turns out that the way OS-X calculates free space in the image vs. on the drive where it's kept might be an issue when they're on user shares. Say the split level is set to 1 and you're user share is across 3 drives. Well, the user share is going to report a lot more free space than you actually have available for that image to grow because it's restricted to one drive. Pretty soon the image is going to run out of space to grow even though the user share says there's plenty of room left. I went down this path because there was a possible correlation between heavy use of these sparse bundle images and the loss of my shares. What I still can't figure out is why that would cause the problem I'm reporting. Seems like the sparse bundle would barf and that would be the end of it. Not trash SAMBA or whatever is really going on. This might be a red herring. I'm still not sure. Something to think about... In the mean time, I've gone back to the stock 4.4.2 release with no add-ons or configuration changes. We'll see how that pans out. I'll report back if I find something.
May 5, 200917 yr Author It's been a week now since I rolled back to a plane-Jane 4.4.2 release and I haven't had this problem for that entire week I've been using it pretty hard almost day & night so at this point, I'm confident the problem was removed. Now just to figure out the problem is/was. Next Step: Reinstall unMenu (by itself) and keep pounding away on it for run another week or two. Keep your fingers crossed (though I don't have much worry about this addition)...
May 5, 200917 yr Author It happened again. I did NOT install unmenu like I said I was going to in the last post. I lost the shares prior to getting to that. Here's what I know: - Generic install of 4.4.2. No ad-ons, nothing special. - I lost the shares while I was deleting a bunch of photographs using Picasa. It's a 'beta' program and could be "doing something wrong" but I don't know. In any case, I don't think that should cause my shares to go away. - The event happened May 5 at about 9:15-9:20. I see a bunch of duplicate object messages in the log about that time but I don't know if that's a clue. Those messages are also earlier in the log when I did not experience a problem. Maybe it has something to do with the number of times the message was repeated - there are a bunch at the time the shares went away - maybe a clue, maybe not. - I only lost SOME shares. I'm sure I lost "Software" and "PicasaLibrary". I'm sure I did NOT loose "Video" NOR "Backups" though I did not try anything significant on these at the time - just a top level directory listing (maybe these were cached?). I'm not sure about the other shares. - I stopped and restarted the array (also in the log). When the array restarted there were no shares listed on the "Shares" page of the unRAID web interface and OS-X could not find these share on the network either. - At this point I captured the attached syslog (prior to rebooting the server). - I rebooted the server and now everything is working again. Any ideas? Thanks
May 5, 200917 yr May 5 09:31:19 HunRAID01 emhttp: shcmd (160): mkdir -m 700 /mnt/user May 5 09:31:19 HunRAID01 emhttp: shcmd: shcmd (160): exit status: 1 May 5 09:31:19 HunRAID01 emhttp: shcmd (161): /usr/local/sbin/shfs /mnt/user May 5 09:31:19 HunRAID01 emhttp: shcmd: shcmd (161): exit status: 1 May 5 09:31:20 HunRAID01 emhttp: _list_user_shares: scandir: Transport endpoint is not connected There is an issue with the restart of the system, specifically (shown above) with the restart of the User Share system. Tom will need to look at this. However, you are using an older version of the unRAID software (v4.4.2), and this problem may have been addressed in versions since then, so please upgrade to v4.5-beta4, to eliminate that possibility. There are no known problems or compatibility issues with upgrading temporarily to v4.5-beta4, and you can revert back later if you choose. Monitor it the same way, force the problem to occur if possible. unRAID v4.5-beta5 may be too new, stability is not yet sufficiently proven, but with a couple of days of use, there are no serious problems reported.
May 5, 200917 yr Author I will upgrade to 4.5-Beta4 tonight and monitory / post back here with results. However, the restart issue which you highlighted occurred after I lost the shares. When they disappeared, I stopped and restarted the array in an (unsuccessful) attempt to get them back. Normally stopping and restarting the array does not cause an issue (all the shares come back up as expected). But when this loss-of-shares issue arises, then the array won't restart properly. The restart issue may not be root cause but just a side effect of the real problem (once the problem occurs, it also causes the restart issue). All that is speculative on my part, but based on my experience with this issue. How do I report the problem to Tom (or will he see these posts)? Thanks for the help.
May 5, 200917 yr Maybe not a coincidence that 'duplicate object' messages were generated at time that shares were 'lost'. Perhaps OS X (or Picassa) is getting confused when it thinks it deleted all the files of a directory, but really it didn't (because of duplicates). The "duplicate object" log entries are generated because of .DS_Store files that OS X likes to generate (like Windows likes to generate desktop.ini and thumbs.db files). Evidently you were running for a while by accessing individual disk shares, then later via user share. By accessing the individual disk shares, OS X created .DS_Store files on each disk. Later when retrieving directory listing of user share, the same named file exists in same folder on multiple disks, hence the 'duplicate object' messages. One thing to try as a test is this: - First, delete all the .DS_Store files (instructions below). - Second, prevent their further creation by following these instructions: http://support.apple.com/kb/HT1629 Now run for a while and see if shares no longer disappear. To delete all the .DS_store files, open a telnet session (or from console), type these commands: cd /mnt/disk1 find -name .DS_Store -delete cd /mnt/disk2 find -name .DS_Store -delete (do this for each /mnt/diskN directory) Note: the -delete option does just that: deletes the objects found by find... to be safe, you can just type this: cd /mnt/disk1 find -name .DS_Store and verify that the only output is a list of '.DS_Store' files. Then add -delete option: find -name .DS_Store -delete
May 6, 200917 yr Author OK - I have to say that I'm blown away here. unRAID AND OS-X support at the same time! You don't see that every day. Usually you get one vendor pointing fingers at the other but neither offering a solution. You guys are amazing! I've implemented the recommended changes on all my Macs (and all the accounts) and have deleted all the .DS_Store files found on the unRAID server (there were literally hundreds of those). Since then I've been hammering away at it all night/morning with a ton of file operations (create, copy, move, delete, edit, etc.) from different client machines. Just now: "find /mnt/disk1 -name .DS_Store" ==> nothing "find /mnt/disk2 -name .DS_Store" ==> nothing "grep duplicate /var/log/syslog" ==> nothing WOO HOO! In fact, the only thing in the syslog since boot-up are informational (connection) references. Now just to let her run for a week or two and see what happens. I can't thank everyone enough for your help on this. It was really starting to get me discouraged about my solution (but I knew there had to be an answer). Keep your fingers crossed - Hopefully it'll be a week or two before I come back to this thread... Thanks again.
May 19, 200917 yr Author It's been two full weeks of hard use and not a single issue. I call this one solved. Tom provided the fix... One thing to try as a test is this: - First, delete all the .DS_Store files (instructions below). - Second, prevent their further creation by following these instructions: http://support.apple.com/kb/HT1629 Now run for a while and see if shares no longer disappear. To delete all the .DS_store files, open a telnet session (or from console), type these commands: cd /mnt/disk1 find -name .DS_Store -delete cd /mnt/disk2 find -name .DS_Store -delete (do this for each /mnt/diskN directory) Note: the -delete option does just that: deletes the objects found by find... to be safe, you can just type this: cd /mnt/disk1 find -name .DS_Store and verify that the only output is a list of '.DS_Store' files. Then add -delete option: find -name .DS_Store -delete Thanks again for all your help. Kyle
Archived
This topic is now archived and is closed to further replies.