Nezil

I've tried both firmwares on the SAS-LP card, and get BLK_EH errors with both. I'm back on .21 now.

Perhaps I'm wrong, but I was under the impression that if files were open, the array would not stop. Issuing the stop command cleanly takes down all the services first, making sure there are no open files, and then unmounts all /dev/md drives. When this happens all of my client computers give me a warning that shares are no longer available, as you would expect. I've not noticed any more serious errors.

True, but if the second BLK_EH error comes, and it could at literally any time without warning, you're far more FUBAR because all drives on the SAS controller will freeze, as will the Web UI, along with any safe way to reboot. These are precisely the reason why these errors are so serious, and not just a mild irritation. I would rather have my server reboot safely, than have to do a hard reset, even if the reboot was at an inconvenient time. Better that than data loss.

Until we have a solution to the BLK_EH_NOT_HANDLED errors, can I suggest the following that might help users with the issue: I'm assuming here that the first BLK_EH_NOT_HANDLED error doesn't lock up your system, and it's the second one that does this. That's the 100% repeatable experience I have, so I've come up with a simple loop that looks for the presence of the first offending line in the syslog every 10 minutes. If the line is found, it stops the array, and starts a controlled reboot. This is far from an ideal solution, but it should mean that your system is always available, and won't need a hard reset to get it going again. Create a file on your flash drive with the following contents: #!/bin/bash while [ ! `cat /var/log/syslog | grep BLK_EH_NOT_HANDLED` ]; do sleep 600 done # Access a blank page in case this is first request since startup. /usr/bin/wget -q -O - localhost/update.htm >/dev/null # Have emhttp do all the work as if user clicked 'Stop' in webGui. /usr/bin/wget -q -O - localhost/update.htm?cmdStop=apply >/dev/null # Have emhttp do all the work as if user clicked 'Reboot' in webGui. /usr/bin/wget -q -O - localhost/update.htm?reboot=apply > /dev/null And then a line calling for it in the go script: /boot/custom/BLK.sh & in my case.

Thanks for your suggestions Phil, though I think I see why you're not having any problems... If I were to restart my server once per day, I think I wouldn't notice any issues either. The only serious issue I have is the BLK_EH errors, but the only seem to happen after the server has been on for around 2 days. Oddly (a least odd to my mind) is that they tend to happen when the server isn't doing anything. It's not related to drive spin down from what I can see, because my log files have lots of spin downs and no issues. Good tip on the EARX drives, I don't have any 3TB drives yet, and don't think I'll need any soon. I have 6 2TB drives now, and 9 1TB. I'm swapping out the 1TB drives as I need more space, and was thinking of swapping 2 of them pretty soon. I was going to get EARS as they're 'known good' but EARX are no more expensive here. Neil.

I've held my tongue, mostly out of respect, but also because I don't think it gets us anywhere. Having said that, it has been nearly a month since Tom's last activity on these forums; our only source of status updates. I understand that Tom has a life of his own, and that it's far more productive to put your head down and try to fix problems, rather than spend time chatting on the forums. I also understand that most of the issues that users are facing these days (e.g. BLK_EH errors and Realtek LAN issues) may very well be linked to the Linux Kernel and drivers that Tom doesn't control. unRAID however, is a product that we've paid for, and for most new users there isn't any reliable options available to us. 4.7 final has a known issue that Tom's mentioned in the past which to my knowledge still isn't fixed. More importantly though is that 4.7 doesn't support much of the newer hardware that we're all forced to buy now due to lack of availability on the older kit; for many of us... 5.0beta is the only option. I think the most frustrating thing is that for nearly a month we don't know what is going on, and what he's working on. I personally agree with the speculation that Tom is likely investigating the drivers / kernel issues, but let's not forget this is speculation. My suggestion to Tom, should he choose to ignore it or otherwise, is to use a one-way method of communication (so as not to get bogged down in conversations) for status updates, what's being worked on, apologies etc. A blog would be an ideal place to put this information or in today's age of social networking, even a twitter message saying 'Sorry about the delays, these Realtek drivers are a real bitch, new build for the weekend... I hope'. I also think that the resources out there, the community of users, might actually be able to help solve a lot of the problems... I'm not suggesting that Limetech release the source code of all the work, as I can see that this does have considerable value to other commercial storage providers; if Tom wishes to keep his hard work closed source then I can't fault him for that. There are however other similar software developments which are closed source, but do allow a closed group of 'Friends' to assist in certain areas. Plex is a good example of this, where there are only a few (originally just a couple) of developers who own the code. There are several other developers who get involved out of love, and don't expect anything in return. In addition to this, they also have an extended group of advanced testers who help with troubleshooting new versions, making use of real time chat tools etc. unRAID goes some way towards this goal, but stops short of really making the most of the resources available, and this fact adds further frustration to the lack of communication. Please understand that I'm not trying to flame here, I am a frustrated user, but I did know that I was buying into the 'beta' versions when I started, and for the most part I have been happy with unRAID I hope Tom comes out of hiding soon, ideally with a solution to my BLK_EH problem

I've noticed this too, but it's not anything new. Frustrating indeed, though I don't often access the page, so I've never really been that bothered. Right now it's the BLK_EH errors that are really starting to drive me mad. Neil.

Much as I would love to see an official 5.0 release, I personally still don't think it's quite ready. Tom mentioned in the release notes for 12a that he's tried to tweak something to resolve the BLK_EH_NOT_HANDLED errors that several of us are seeing. In my experience, this issue still isn't fixed, and causes the server to become unresponsive (at least from the UI point of view) and all of the MV8 connected drives to be in-accessible from the terminal / ssh when it happens. As far as I can see, the only solution is a hard reset, which isn't a nice thing to have to do. Again, in my experience, it takes about 2 days for this issue to manifest. As before, I'm attaching a few complete sys logs that show the problem; some from beta11, some from beta12, and some from beta12a. Extracting all of the BLK_EH_NOT_HANDLED lines from the logs, there doesn't seem to be any pattern, and using Google I wasn't able to find any information on what the (presumably) Hex codes for 'command' and 'task' relate to. Beta 11 Aug 16 09:14:21 unRAID kernel: sas: command 0xd9fa9e40, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED Aug 16 10:27:13 unRAID kernel: sas: command 0xf77af6c0, task 0xdf71c140, timed out: BLK_EH_NOT_HANDLED Aug 16 13:30:37 unRAID kernel: sas: command 0xf7661240, task 0xdf71db80, timed out: BLK_EH_NOT_HANDLED Aug 16 13:53:49 unRAID kernel: sas: command 0xf6ded6c0, task 0xdf71ca00, timed out: BLK_EH_NOT_HANDLED Aug 16 15:42:56 unRAID kernel: sas: command 0xf75efcc0, task 0xdf4dd2c0, timed out: BLK_EH_NOT_HANDLED Aug 16 23:14:38 unRAID kernel: sas: command 0xf6fc6a80, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED Aug 17 02:32:09 unRAID kernel: sas: command 0xf6fc6480, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED Aug 17 05:35:40 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED Aug 17 06:05:34 unRAID kernel: sas: command 0xcdf13f00, task 0xdf71cf00, timed out: BLK_EH_NOT_HANDLED Aug 17 18:11:49 unRAID kernel: sas: command 0xd9f8f9c0, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 17 19:11:08 unRAID kernel: sas: command 0xd9f8fd80, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 17 20:47:38 unRAID kernel: sas: command 0xcdf13b40, task 0xdf71d680, timed out: BLK_EH_NOT_HANDLED Aug 18 00:40:51 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71cdc0, timed out: BLK_EH_NOT_HANDLED Aug 18 05:07:55 unRAID kernel: sas: command 0xcdf13d80, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED Aug 18 18:16:28 unRAID kernel: sas: command 0xf75ef780, task 0xdf4dd7c0, timed out: BLK_EH_NOT_HANDLED Aug 19 10:30:41 unRAID kernel: sas: command 0xf75ef600, task 0xdf4dc280, timed out: BLK_EH_NOT_HANDLED Aug 19 17:48:24 unRAID kernel: sas: command 0xcdf133c0, task 0xdf71c3c0, timed out: BLK_EH_NOT_HANDLED Aug 20 05:07:11 unRAID kernel: sas: command 0xf6fc6300, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 20 08:17:25 unRAID kernel: sas: command 0xcdf13f00, task 0xdf71d2c0, timed out: BLK_EH_NOT_HANDLED Aug 20 20:13:56 unRAID kernel: sas: command 0xcdf13e40, task 0xdf71d400, timed out: BLK_EH_NOT_HANDLED Aug 20 20:42:10 unRAID kernel: sas: command 0xf754f000, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED Aug 20 23:10:46 unRAID kernel: sas: command 0xcdf13000, task 0xdf71d900, timed out: BLK_EH_NOT_HANDLED Aug 21 02:18:10 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71cc80, timed out: BLK_EH_NOT_HANDLED Aug 21 05:37:45 unRAID kernel: sas: command 0xcdc47540, task 0xdf71e500, timed out: BLK_EH_NOT_HANDLED Aug 21 07:10:02 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4ddb80, timed out: BLK_EH_NOT_HANDLED Aug 21 18:08:19 unRAID kernel: sas: command 0xf75eff00, task 0xdf4dd900, timed out: BLK_EH_NOT_HANDLED Aug 21 23:32:21 unRAID kernel: sas: command 0xf75ef480, task 0xdf4dcf00, timed out: BLK_EH_NOT_HANDLED Aug 22 13:19:01 unRAID kernel: sas: command 0xd0c2bb40, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED Aug 22 15:08:13 unRAID kernel: sas: command 0xcdf36d80, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 23 00:08:40 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED Aug 23 04:12:11 unRAID kernel: sas: command 0xf75efc00, task 0xdf4dd7c0, timed out: BLK_EH_NOT_HANDLED Aug 23 10:26:29 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4dc280, timed out: BLK_EH_NOT_HANDLED Aug 23 15:32:48 unRAID kernel: sas: command 0xf75eff00, task 0xdf4dc3c0, timed out: BLK_EH_NOT_HANDLED Aug 23 16:45:50 unRAID kernel: sas: command 0xf75ef180, task 0xdf4dcc80, timed out: BLK_EH_NOT_HANDLED Aug 24 04:40:28 unRAID kernel: sas: command 0xcdf13180, task 0xdf71cc80, timed out: BLK_EH_NOT_HANDLED Aug 24 07:31:50 unRAID kernel: sas: command 0xcdc47480, task 0xdf71ea00, timed out: BLK_EH_NOT_HANDLED Aug 24 14:04:09 unRAID kernel: sas: command 0xf6f70b40, task 0xdf4ce140, timed out: BLK_EH_NOT_HANDLED Aug 24 17:13:11 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71c280, timed out: BLK_EH_NOT_HANDLED Aug 25 00:19:54 unRAID kernel: sas: command 0xcdf13b40, task 0xdf71cf00, timed out: BLK_EH_NOT_HANDLED Aug 25 08:20:32 unRAID kernel: sas: command 0xcdc479c0, task 0xdf71f180, timed out: BLK_EH_NOT_HANDLED Aug 25 09:52:37 unRAID kernel: sas: command 0xcdc470c0, task 0xdf71e280, timed out: BLK_EH_NOT_HANDLED Aug 25 12:22:13 unRAID kernel: sas: command 0xcdf13240, task 0xdf71d180, timed out: BLK_EH_NOT_HANDLED Aug 25 16:00:00 unRAID kernel: sas: command 0xf6f70b40, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 25 20:01:00 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71db80, timed out: BLK_EH_NOT_HANDLED Aug 27 05:08:45 unRAID kernel: sas: command 0xf75ef840, task 0xdf4dcf00, timed out: BLK_EH_NOT_HANDLED Aug 27 07:02:40 unRAID kernel: sas: command 0xf6f459c0, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 27 16:11:21 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4dd400, timed out: BLK_EH_NOT_HANDLED Aug 27 16:11:51 unRAID kernel: sas: command 0xf75ef000, task 0xdf4dd680, timed out: BLK_EH_NOT_HANDLED Aug 27 21:02:06 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71d2c0, timed out: BLK_EH_NOT_HANDLED Aug 28 04:38:11 unRAID kernel: sas: command 0xcdf36f00, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED Aug 28 07:06:22 unRAID kernel: sas: command 0xf75ef840, task 0xdf4dc8c0, timed out: BLK_EH_NOT_HANDLED Beta 12 Sep 1 03:11:26 unRAID kernel: sas: command 0xdf8c1180, task 0xf47d8780, timed out: BLK_EH_NOT_HANDLED Sep 1 06:03:19 unRAID kernel: sas: command 0xdf95f0c0, task 0xf467f2c0, timed out: BLK_EH_NOT_HANDLED Sep 10 18:42:59 unRAID kernel: sas: command 0xeface180, task 0xdf86fcc0, timed out: BLK_EH_NOT_HANDLED Sep 11 23:00:34 unRAID kernel: sas: command 0xf4752600, task 0xdf826500, timed out: BLK_EH_NOT_HANDLED Beta 12a Sep 13 23:29:33 unRAID kernel: sas: command 0xdf872cc0, task 0xdfb04280, timed out: BLK_EH_NOT_HANDLED Sep 14 12:56:14 unRAID kernel: sas: command 0xda60d240, task 0xdf87c780, timed out: BLK_EH_NOT_HANDLED [email protected] [email protected] [email protected] [email protected]

I'm also getting this error, and have been since at least beta12, maybe longer. It didn't click with me that this might be responsible for the web UI lockup that I tend to see after a few days of the server running. Two sys logs attached, both from 12, rather than 12a I'm afraid, though I don't think 12a has done anything to influence this. For reference, my setup is as follows: Case: Lian Li PC-P50B Motherboard: Foxconn H67MP CPU: Intel i3 2100 RAM: 2 x 2GB Samsung PC3-10600 Controller: Supermicro AOC-SASLP-MV8, Biostar DC3SA 2 Port SATA III PSU: Antec Neo Eco 520 Drive Racks: Icydock 5in3 x 3 HDDs: 15 Green Drives - 2TB EARS x 2, EVDS x 2, EADS x 2; 1TB EAVS x 3, EADS x 6. Edit: I should add that the BLK error on the latest syslog (named just syslog) has not caused any obvious issues so far, web UI is still working. Edit 2: Got a new BLK_EH_NOT_HANDLED error overnight, Web UI hasn't worked since; new syslog attached ([email protected]). I'm going to update to 12a at this point, and see if it improves things at all. syslog.zip [email protected] [email protected]

Savestheday: I'll go through my setup again in another post, when I've got a little more time. I think I have a good understanding of how Netatalk is working, and where the performance issues exist and could be improved, as well as what the pros and cons are of doing this. In short, the way it's set up by Tom in the latest betas (including beta11) is good, and I can't see any issues with his choice of settings. Personally, I have made several changes from Tom's options, which I believe improve browsing performance a little.

I foolishly messed up on my first fix for Lion Sidebar SMB Shares. I've gone through it again and updated the thread with a fix that does actually work this time. Just posting here again for Tom and others to see, and in the hope that the fix can be integrated into future builds for the Lion users among us. Fix can be found here: http://lime-technology.com/forum/index.php?topic=14623.msg138068#msg138068

OK, apologies for missing something in my first post. I've done a bit more digging, and it seems that when I fixed this myself the first time, a change I'd made to the /etc/samba/smb.conf file was persisting, and clouding my judgement. It seems that the problem stems from the following facts OS X Lion does indeed expect SMB shares to be on port 445. The 'Connect to server' dialog will try both ports, resulting in a connection Bonjour advertised services that advertise SMB on port 139 just won't connect (maybe because Lion believes that this is a legacy connection port) even if the service is in fact running on that port To fix the problem, the SMB service must be: Identified in Bonjour as being on port 445 Actually running on port 445 & 139 (Which is the default for Samba, but not default for unRAID - Not sure why?) I have fixed this by editing the /etc/avahi/services/smb.service file as follows: <?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h-SMB</name> <service> <type>_smb._tcp</type> <port>445</port> </service> <service> <type>_device-info._tcp</type> <port>0</port> <txt-record>model=Xserve</txt-record> </service> </service-group> And the /etc/samba/smb.conf file like this: [global] # configurable identification include = /etc/samba/smb-names.conf # log stuff only to syslog log level = 0 syslog = 0 syslog only = Yes # we don't do printers show add printer wizard = No disable spoolss = Yes load printers = No printing = bsd printcap name = /dev/null # misc. smb ports = 445 139 unix extensions = No wide links = Yes use sendfile = Yes aio read size = 0 aio write size = 0 # hook for user-defined samba config include = /boot/config/smb-extra.conf # auto-configured shares include = /etc/samba/smb-shares.conf # Hide Mac Created Files hide files = /Network Trash Folder/Temporary Items/ Avahi detects the change as soon as you edit the file, and updates it's broadcasts. Samba however didn't seem to update to the change until I stopped, and then re-started the array. This time, I've tried rebooting unRAID and re-applying the changes, as well as rebooting Lion and Snow Leopard... This time, my fix does seem to work.

Hmm.... looks like many of you are still having issues. I'll do some more digging, maybe my suggestion didn't fix it after all! Apologies if so.

I know this isn't the right place to make a full post, so I'm just linking to a thread I've created in the General section with a solution to the 'OS X Lion Finder Sidebar SMB' issue. Thread is here: http://lime-technology.com/forum/index.php?topic=14623.msg137872 Hopefully Tom might be able to put this fix into the next build for the Mac users among us.

New Method Posted Further Down the Thread; This First Post is Missing One Important Part I'm posting a new thread here because it probably relates to all Lion users, but just to be clear, I'm using 5.0beta10. The Issue: Several people have noticed that it's not possible to use the SMB server shortcut in the Finder Sidebar in OS X Lion. It's still possible to connect by using Go -> Connect to Server, or by typing Cmd+K and the inputting your server's address, but this isn't ideal, and you're left with a pretty useless icon in your sidebar. The Diagnosis: I've been able to track the problem down to the fact that Avahi (The bonjour service on unRAID) is advertising the SMB server as running on port 139. There's nothing wrong with this, and unRAID's SMB server is indeed running on port 139, but Lion seems to want believe that the server is actually running on port 445. From some reading on the internet, it seems that port 139 was the original port used by Microsoft in the days of Windows NT for file sharing, when NetBIOS over TCP/IP was also being used. Newer versions of Windows (2000 onwards) apparently use port 445 instead, though all operating systems will fall back to 139 if 445 doesn't work. The Solution: Avahi uses XML files stored in /etc/avahi/services to know what to advertise, a line in the smb.service file lists the port number as 139. If this is changed to 445, even though the service isn't, Lion will connect perfectly. My smb.service file now looks like this: <?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h-SMB</name> <service> <type>_smb._tcp</type> <port>445</port> </service> <service> <type>_device-info._tcp</type> <port>0</port> <txt-record>model=Xserve</txt-record> </service> </service-group> Surviving Reboots: You can make the changes to this file each time you boot up, or you could copy it first to somewhere on your flash disk, make the changes there, and then add a line to your go script, to copy the file back to the original location each time you boot. The Caveat: This solution seems to work fine for me, but as with anything with a new OS like Lion, Apple may change something in the next release that breaks this. -- Edit: This change does not affect a Snow Leopard machine's ability to connect to the share, and shouldn't affect Windows either, as they don't use Bonjour by default. Good luck!

Plex is working fine for me too in this release. I'll post a new walkthrough on how I set things up in either a new thread, or an existing one nice I've done a search to find out where's best. I have already posted much of the information already on page 7 of this thread.

Hmm... that's a good point Eddie. In my case, I've modified the /etc/profile setting in the bzroot image (along with many other modifications) rather than add it to the go script. The profile script in my case then applies to all sessions; I'd not thought of that problem if using the go script. In the go script case, you'd be better to add two lines then: echo "export TMPDIR=/mnt/cache/tmp" >> /etc/profile export TMPDIR=/mnt/cache/tmp as that will cover the current session and future ones. Is that right?

Savestheday, your Plex issues... The best way for me to help you is to explain what I've done to install Plex; something I should have done long ago actually. As I've stated before, I'm running an additional 2.5" HDD connected by USB and mounted inside my case to house all of my apps, rather than a cache drive (which I don't use at all), some things may differ because of this, but I don't think anything major. The first thing I did was to unpack the latest Plex tarball, and rename the folder. You've already done this. My understanding from other posts, is that for transcoding, the alsa-lib-1.0.23-i486-1.tgz package is required. I'm not sure if this will be the case in future, but for now this needs to be added to your install. The easiest way to achieve this is by putting it in the /boot/extra folder of your flash drive. Plex was originally written for the Mac operating system, and when it first runs, it creates a Library folder structure in the user's home folder. In unRAID, you'll probably be using the root user to run Plex, so the folder structure will be created in the /root directory. This directory is on the RAM disk, and will be lost on every boot, loosing your Plex library database and all settings; not good. To fix this problem, you'll need to make a Library Folder on your cache drive, and then create symlinks in the /root location to this location. You can do this by adding the following lines to your go script: ln -s /Library /mnt/cache/.Plex/Library ln -s /root/Library /mnt/cache/.Plex/Library Plex includes all the required dependancies, which does make things simple. You need to tell the unRAID OS where this folder is by appending a line to the ld.so.conf file and then reload the new configuration. As before, in your go script add: echo "/mnt/cache/.Plex" >> /etc/ld.so.conf ldconfig By default, Plex stores the 'HTTP Live Streaming' chunks in the /tmp folder, which can get pretty big. It doesn't matter that this folder will disappear on reboots, but it does matter that it will grow in size taking up RAM, which you don't want. Luckily Plex honours the TMPDIR environment variable, and that's the easiest way to move the location of these temporary files. There have been some other suggestions for this issue, such as bind mounts, but this can cause issues with starting and stopping the array, so a better solution is to add the TMPDIR variable to /etc/profile. To do that, you need to add this line to your go script: echo "export TMPDIR=/mnt/cache/tmp" >> /etc/profile Finally, to actually start Plex, you could telnet in and do it, but a better way is to have a script that automatically does this when you start the array, and automatically stops it when you stop the array. As part of the as yet unfinished add-ons system, unRAID calls a file located at /usr/local/sbin/emhttp_event before or after certain unRAID events, and you can hook onto this to start and stop applications. I should give credit to Joe L for pointing this out. I've butchered Joe's original proposed script until this add on system is finalised, the script I use is shown below, and located at /boot/custom/emhttp_event/event . To get this script to be called, you must add a line to your go script as follows: echo '/boot/custom/emhttp_event/event $1' >> /usr/local/sbin/emhttp_event # A script to start up and shutdown services running when the array starts and stops case $1 in svcs_started) if ! ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep; then /mnt/cache/.Plex/start.sh >> /Library/Logs/.Plex\ Media\ Server.log 2>&1 & logger -t Plex\ Media\ Server Started fi;; svcs_restarted) if ! ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep; then /mnt/cache/.Plex/start.sh >> /Library/Logs/.Plex\ Media\ Server.log 2>&1 & logger -t Plex\ Media\ Server Started fi;; stopping_svcs) if ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep; then kill `ps -ef | grep Plex | grep -v grep | awk '{print $2}'` logger -t Plex\ Media\ Server Stopped fi;; *) logger -t Event\ Script Incorrect\ Argument;; esac Notes: - I actually have more things in my script because I'm also running Squeezebox Server, though these are not shown here. - I've made some changes to the script so that it will work for your cache drive, rather than an additional drive like I have. - In later versions of Plex (not yet released ones) the 'stopping_svcs' section for Plex can be changed to: kill -s INT `ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep | awk '{print $2}'` because the Media Server will automatically close down all associated python scripts when it's issued the INT signal. The currently released version doesn't do this yet. - Permissions are not important if you've followed these instructions, as the Media Server is run as root, and can access all the required files anyway. I hope this helps!

Savestheday... You always seem to ask questions that are close to home for me; I hope I'm able to help you. chmod and chown are not really that complicated; if you do an ls -l on a directory, you'll see all the files with their associated permissions. For reference, I've included the ls -l of my Plex directory: root@unRAID:/apps/Plex# ls -l total 32170 drwxr-xr-x 5 root root 136 2011-07-17 12:09 Library/ -rwxr-xr-x 1 neil 1000 2186244 2011-07-14 19:49 Plex\ Media\ Scanner* -rwxr-xr-x 1 neil 1000 3752708 2011-07-14 19:49 Plex\ Media\ Server* drwxr-xr-x 5 neil 1000 648 2011-07-14 19:37 Resources/ -rwxr-xr-x 1 neil 1000 124367 2011-07-14 19:37 libass.so.4* -rwxr-xr-x 1 neil 1000 73205 2011-07-14 19:37 libavahi-client.so.3* -rwxr-xr-x 1 neil 1000 55429 2011-07-14 19:37 libavahi-common.so.3* -rwxr-xr-x 1 neil 1000 6080560 2011-07-14 19:37 libavcodec.so.52* -rwxr-xr-x 1 neil 1000 1040592 2011-07-14 19:37 libavformat.so.52* -rwxr-xr-x 1 neil 1000 116112 2011-07-14 19:37 libavutil.so.50* -rwxr-xr-x 1 neil 1000 141573 2011-07-14 19:37 libboost_filesystem.so.1.46.1* -rwxr-xr-x 1 neil 1000 263374 2011-07-14 19:37 libboost_iostreams.so.1.46.1* -rwxr-xr-x 1 neil 1000 433534 2011-07-14 19:37 libboost_program_options.so.1.46.1* -rwxr-xr-x 1 neil 1000 1079412 2011-07-14 19:37 libboost_regex.so.1.46.1* -rwxr-xr-x 1 neil 1000 98211 2011-07-14 19:37 libboost_signals.so.1.46.1* -rwxr-xr-x 1 neil 1000 16293 2011-07-14 19:37 libboost_system.so.1.46.1* -rwxr-xr-x 1 neil 1000 121430 2011-07-14 19:37 libboost_thread.so.1.46.1* -rwxr-xr-x 1 neil 1000 2413759 2011-07-14 19:37 libcurl.so.4* -rwxr-xr-x 1 neil 1000 341159 2011-07-14 19:37 libdbus-1.so.3* -rwxr-xr-x 1 neil 1000 23415 2011-07-14 19:37 libepeg.so.0* -rwxr-xr-x 1 neil 1000 209907 2011-07-14 19:37 libexpat.so.1* -rwxr-xr-x 1 neil 1000 99643 2011-07-14 19:37 libexslt.so.0* -rwxr-xr-x 1 neil 1000 89664 2011-07-14 19:37 libfaac.so.0* -rwxr-xr-x 1 neil 1000 245739 2011-07-14 19:37 libfontconfig.so.1* -rwxr-xr-x 1 neil 1000 3655228 2011-07-14 19:37 libfreeimage.so.3* -rwxr-xr-x 1 neil 1000 637624 2011-07-14 19:37 libfreetype.so.6* -rwxr-xr-x 1 neil 1000 92741 2011-07-14 19:37 libfribidi.so.0* -rwxr-xr-x 1 neil 1000 973644 2011-07-14 19:37 libiconv.so.2* -rwxr-xr-x 1 neil 1000 297847 2011-07-14 19:37 libjpeg.so.8* -rwxr-xr-x 1 neil 1000 33936 2011-07-14 19:37 libminiupnpc.so.5* -rwxr-xr-x 1 neil 1000 327522 2011-07-14 19:37 libmp3lame.so.0* -rwxr-xr-x 1 neil 1000 9188 2011-07-14 19:37 libnatpmp.so.1* -rwxr-xr-x 1 neil 1000 4425772 2011-07-14 19:37 libpython2.7.so.1.0* -rwxr-xr-x 1 neil 1000 299141 2011-07-14 19:37 libsoci_core-gcc-3_0-3.0.0.so* -rwxr-xr-x 1 neil 1000 108624 2011-07-14 19:37 libsoci_sqlite3-gcc-3_0-3.0.0.so* -rwxr-xr-x 1 neil 1000 693759 2011-07-14 19:37 libsqlite3.so.0* -rwxr-xr-x 1 neil 1000 252632 2011-07-14 19:37 libswscale.so.0* -rwxr-xr-x 1 neil 1000 1645425 2011-07-14 19:37 libxml2.so.2* -rwxr-xr-x 1 neil 1000 278879 2011-07-14 19:37 libxslt.so.1* -rwxr-xr-x 1 neil 1000 101724 2011-07-14 19:37 libz.so.1* -rwxr-xr-x 1 neil 1000 287 2011-07-15 09:22 start.sh* In this case, you can see the format is made up of: [permissions codes] [owner's username] [group name or id] [file size] [date and time] [filename] To focus on permission codes, as the rest is pretty self explanatory, this are broken up into: [type of file (d for directory, l for link, - for file)] [user permissions] [group permissions] [others permissions] And example from above is: -rwxr-xr-x 1 neil 1000 2186244 2011-07-14 19:49 Plex\ Media\ Scanner* This indicates that the owner is neil, the group id is 1000, and that 'neil' has Read, Write and Execute permissions, group 1000 has Read and Execute permissions, and everyone else has Read and Execute permissions as well. It's important to remember that the 'root' user has Write permissions as well, even though he isn't the owner or in the group. To change ownership, you use the command chown [user]:[group (optional)] filename To change permissions, you use the chmod [settings] filename The settings for chmod can be in the form of numbers to represent the permissions, or for simplicity, can be using letters. I won't bother to explain the number method here, there are plenty of resources available for that on the internet; the letter approach is far simpler: u = user, g = group, o = others + = set permission, - = remove permission r = read, w = write, x = execute Using these combinations, you can change permissions to anything you want. For example: chmod +x,+r [filename] will make the file readable and executable to user, group and others. chmod o-w [filename] will make the file not writable to others. chmod u+x,g-x,o-x [filename] will make the file readable and executable to user, but not executable by group and others. I'll create a new post about the Plex issues.

To do this with a go script, you could copy the AppleVolumes.default- file to somewhere on your flash drive, make you modifications to that file. In your go script, just add: cp /boot/custom/AppleVolumes.default- /etc/netatalk/AppleVolumes.default- That should do it!

Savestheday, In my system, as I've said, I run an additional drive. You could use the cache drive instead, though I'm not sure what happens when you stop the array to that drive; if it's unmounted at that point, when AFP starts up again, once the array is stopped, it won't be able to find the folder containing the CNID databases, and could have un-expected results. Having said that, the user shares won't be available either, so the afp daemons will likely not have anything to do, and may not notice that the CNID path location doesn't exist - In short, it would be a bit of a hack to put the CNID databases on the cache drive. Adding the nocnidcache option shouldn't be a problem at all, as it doesn't affect the location of the CNID databases. This will probably give you the biggest performance benefit anyway, so why not try that on it's own first. If you're willing to take the risk (which is not much of a risk really) then go right ahead; this is how it's done. Whenever Tom releases another beta build, I customise it by decompressing the bzroot file, make my changes, and then re-compressing it. I then put this bzroot file on my flash drive. This might sound complicated, but it really isn't; details in this old post from BubbaQ that I found in the wiki. If you don't want to go down the bzroot customisation path, you might be able to add something to the go script to do a similar job. In the /etc/netatalk/ folder, you'll see that there are two files called 'AppleVolumes.default'. One has a - on the end of the file name, and it's this one that you want to edit. (Each time AFP starts, unRAID copies this file to AppleVolumes.default, adds the shares that you've configured, and then starts the AFP daemons). Look in that file for a line at the bottom that by default says something like: :DEFAULT: cnidscheme:dbd options:upriv,usedots And change it to something like this: :DEFAULT: cnidscheme:dbd options:upriv,usedots,nocnidcache dbpath:/apps/dbd/$v My additional drive is mounted at /apps by the way. As you said, on the cache drive, you'll want to hide the dbd folder by prepending a dot to the name. The $v argument means that subfolders with the names of the shares (AFP 'V'olumes) will be created in the /apps/dbd folder. If you just want to test the theory, you could edit the AppleVolumes.default- file when booted, start and stop the array, and try it out. Please keep in mind my comments about putting it on the cache drive not being ideal; I'm not sure how this will work out for you.

Saves the day, Yes, that 'No such file or directory' message is normal, however... As I stated in my previous post... you don't necessarily want to delete all of your .AppleDouble folders; there might have been some important resource fork information in there. To be clear, I don't recommend deleting the .AppleDouble folders. Deleting .AppleDB folders is fine, because they only contain the netatalk CNID databases. I'll summarise the current status of AFP from my point of view, now that Tom has made several improvements. There used to be an issue that the inode numbers of files and folders in user shares changed every time the array was started, this caused the AFP databases to be invalid, requiring corrections, which took a while every array restart. This has now basically been fixed in beta10 (with some minor caveats that Tom mentions in a previous post). There used to be an issue that extended attributes were not possible in user shares, and Netatalk wanted to use them in it's default configuration. Tom has fixed this as well. Netatalk creates a database of file and folder locations (based on inode numbers), by default in a .AppleDB folder in the root of each share. From Netatalk 2.1 onwards, some of this location data is also cached in the .AppleDouble folders that have always been used for storing resource forks. When Netatalk daemons are stopped (because you stopped the array, or rebooted), the databases are closed down, and must be restarted when the daemons start again. In my testing, I have found that the process of caching this database data in the .AppleDouble folders takes an annoyingly long time, primarily because it's a lot of small reads and writes to the parity protected array. In my system I run an additional drive outside the array, which stores not critical data, and runs my the add on applications that I've selected (Plex and Squeezebox Server). To speed up the performance of these databases, I have chosen to modify the /etc/netatalk/AppleVolumes.default- file, by adding the nocnidcache option (which disables caching the database in .AppleDouble folders), and adding the dbpath: variable to move the .AppleDB folders onto my drive outside the array. This has improved initial browsing performance dramatically. The standard unRAID setup works fine, and there are no bugs. I wasn't happy with the browsing performance, so I made those changes. I'm putting it out there as an idea, rather than advising anyone to do it.

I'm getting loads of the following errors in the syslog, and I have no idea why. Jul 23 18:26:42 unRAID kernel: ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x4890000 action 0xe frozen Jul 23 18:26:42 unRAID kernel: ata3.00: irq_stat 0x08400040, interface fatal error, connection status changed Jul 23 18:26:42 unRAID kernel: ata3: SError: { PHYRdyChg 10B8B LinkSeq DevExch } Jul 23 18:26:42 unRAID kernel: ata3.00: failed command: READ DMA Jul 23 18:26:42 unRAID kernel: ata3.00: cmd c8/00:f8:90:36:03/00:00:00:00:00/e0 tag 0 dma 126976 in Jul 23 18:26:42 unRAID kernel: res 50/00:00:8f:36:03/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) Jul 23 18:26:42 unRAID kernel: ata3.00: status: { DRDY } Jul 23 18:26:42 unRAID kernel: ata3: hard resetting link Jul 23 18:26:42 unRAID kernel: ata4.00: exception Emask 0x10 SAct 0x0 SErr 0x4890000 action 0xe frozen Jul 23 18:26:42 unRAID kernel: ata4.00: irq_stat 0x08400040, interface fatal error, connection status changed Jul 23 18:26:42 unRAID kernel: ata4: SError: { PHYRdyChg 10B8B LinkSeq DevExch } Jul 23 18:26:42 unRAID kernel: ata4.00: failed command: READ DMA Jul 23 18:26:42 unRAID kernel: ata4.00: cmd c8/00:90:00:37:03/00:00:00:00:00/e0 tag 0 dma 73728 in Jul 23 18:26:42 unRAID kernel: res 50/00:00:ff:36:03/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) Jul 23 18:26:42 unRAID kernel: ata4.00: status: { DRDY } Jul 23 18:26:42 unRAID kernel: ata4: hard resetting link Jul 23 18:26:48 unRAID kernel: ata4: link is slow to respond, please be patient (ready=0) Jul 23 18:26:48 unRAID kernel: ata3: link is slow to respond, please be patient (ready=0) Jul 23 18:26:49 unRAID kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Jul 23 18:26:49 unRAID kernel: ata4.00: configured for UDMA/100 Jul 23 18:26:49 unRAID kernel: ata4: EH complete I've tried moving disks around, and it's always the same ata3 and ata4 errors. How can I find what these relate to? I have no idea how to find which drives I should be checking.

Madburg / Tom, I've not seen the Kernel Oops since playing with Beta10. Admittedly I've not started and stopped much, so I can't confirm for sure yet. I'll post again if I'm still having the problem.

Scrap that... you've fixed both the things I identified! Persistent inodes and extended attributes! Great job, thanks very very much!