snowboardjoe

Been running unRAID 5.0-rc16c for a few months now and going back to fix little quirks here and there. One of them was the root password. The GUI was not setting it. So, I did it manually and then later realized I needed to copy /etc/passwd and /etc/shadow to /boot/config to save and restore those files. OK, that's solved. I tried configuring my personal login by setting the password and recopying the files. I then tried to login via ssh or telnet and I soon as I login, the system immediately closes the connection. I get the feeling there is some security measure in place that does not like my local login. I can still login via ssh or telnet as root (after I modified sshd_config to PermitRootLogin). I could dig around more, but I feel like I'm fighting the system here and don't want to get too far away from the stock config. At the same time, it seems like a lot of standards were sort of missed here in running a system like this.

I had the exact problem two months ago. One of the 3TB drives I ordered was the 2TB model. It was in a box labeled (not by factory) as a 3TB drive. Had to do a quick exchange on that (they sent correct one immediately while they waited on the incorrect one to come back).

Your comments are well noted! This was my first unRAID box and was really going for the cheap side of the budget this time around. Will definitely consider the intel line in future systems.

My MOBO only takes AM3 and AM3+, so that limits me to those CPU's. Not ready to reinvest in a new MOBO, so Intel is out for now. Not expecting to need anything high performance here. I know I want multi-core to address several things running while allowing the core of unRAID to keep going unimpeded. At first I just looked at the dual-core and knew that would be an improvement. Using NewEgg, I narrowed it down to these choices: Current: AMD Sempron 145 Sargas 2.8GHz Socket AM3 45W Single-Core ($39, PassMark 833) Option 1: AMD Athlon II X2 270 Regor 3.4GHz Socket AM3 65W Dual-Core ($55, PassMark 1991) Option 2: AMD Athlon II X4 640 Propus 3.0GHz Socket AM3 95W Quad-Core ($79, PassMark 3365) Option 3: AMD FX-4100 Zambezi 3.6GHz Socket AM3+ 95W Quad-Core ($99, PassMark 4056) So many choices. Probably going with option 3, but 2 ain't bad either if I want to save another $20.

AFP and TM has been a pain in the butt for me too. I was trying to mix things up by having one share for all TM clients, but that failed miserably. I ended up having to keep them as separate shares. Otherwise, when one AFP client touched a TM share that was touched by another AFP client, AFP seized. Once is separated them all into their own shares things are good again (and I also adjust TM client to only run once/day (hourly is just silly). I will check my logs when I get home this evening to see if I'm seeing the same thing as you're seeing. I'm curious now. I may even just dump one of my 3TB drives onto my AirPort and let TM backups happen that way.

Yeah, something is not right there. To stream an MKV file to a Roku box is trivial. All Plex is doing is just passing it through the network. Sounds more like a bandwidth problem on your network, but that's purely a guess. You can check the performance of your Plex server during streaming, but you should see hardly any rise in CPU activity during streaming. May want to try just streaming it to a Plex client (on the same system as your Plex server and another system) and rule out any issues with getting the content from unRAID to Plex.

What's the content? AVI? MKV? This makes a huge difference on whether or not Plex needs to transcode on the fly. I just posted on another forum where I realized my dual-core MacMini could not keep up streaming an AVI to my Roku3 unless everything else was idle on the system.

I'm also looking to upgrade. My unRAID has only been setup for a few months now and was keeping it simple. I have Plex, SAB, SB and Transmission running on an old MacMini with a dual core 2GHz. When I want to play something that is an AVI and want to send it to my Roku3, the MacMini could not keep up unless everything else was completely idle on the host. That's when I realized I had to beef up the CPU significantly when I eventually migrate Plex, SAB, SB and Transmission to my unRAID server. Was looking at going with an AMD Athlon II X4 640 Propus 3.0GHz for $79. Figured that would be plenty of horsepower without going overboard (and only $20 more than the dual-core). I assumed 3GHz would be plenty for any transcoding I need to do. Most of my content is MP4 and MKV, so no transcoding needed for that content other than the system downscaling it for mobile devices to sync.

I tried sharing some alternate version of TM shares, but ran into trouble every single time. I guess it's something to do with the sharing of TM shares and multiple clients accessing it. Not sure who's getting upset (unRAID or the clients), but I gave up trying to get that to work. I created a separate TM share for each system and all of my problems have vanished. I have a little more testing to do, but looking good now.

Your TM client is already designated to just connect to one of these right? I could see this happening when you select a different "disk" for TM, but I would not expect it once it's already selected. Weird.

So, I setup a new TM share and it worked great and has been for the past 24 hours. I tried another system to back up to that same TM share and it's dead. So my theory is you can only have one TM share per TM client? I'll test that theory out tomorrow evening. I assumed since it created a separate directory for each system that the share could be..., well..., shared.

Would I just browse to the disk share via SMB and then tell TM to use that? I was under the impression that would not work because it must be AFP. Or, maybe I'm missing something here. I do have the existing share tied to a single disk. I will definitely try a few other things when I get home.

Just booted to rc16c. My AFP mount for TimeMachine is completely inaccessible now. This is on two different Macs. Just reports the following when I try to access them: "The operation can't be completed because the original item for 'TimeMachine' can't be found." Syslog records nothing. Tried to restart afpd and no luck...., oh, wait something just happened as I was typing this up... Jul 18 20:42:30 laffy afpd[6283]: dsi_stream_send: Broken pipe Jul 18 20:42:30 laffy afpd[6283]: dsi_cmdreply(6): Broken pipe Jul 18 20:42:30 laffy afpd[6332]: dsi_stream_send: Broken pipe Jul 18 20:42:30 laffy afpd[6332]: dsi_cmdreply(7): Broken pipe And I can see my share now... ziti:etc morris$ ls -l /unraid/TimeMachine total 0 drwxrwxrwx@ 1 morris wheel 264 Jul 6 17:36 Network Trash Folder drwxrwxrwx@ 1 morris wheel 264 Jul 6 17:36 Temporary Items drwxrwxrwx@ 1 morris wheel 264 Jul 9 00:55 jmorrseaosxl1.sparsebundle drwxrwxrwx@ 1 morris wheel 264 Jul 17 17:19 ziti.sparsebundle However, TM still can't access the share. It keeps throwing up the same error when I try to browse to it. Even though I have the AFP share setup in automounter and I can access it there, that is apparently not good enough for TM. Any other ideas on what the root cause may be here?

Currently running 5.0-rc15a and while things have been going pretty well, TimeMachine access continues to be a problem. I'm able to establish the AFP session and mount the filesystem most of the time. Other times it just gets stuck and won't respond. At the same time other AFP sessions are working. The only way I can get things moving along again is to kill AFP and restart it. Things start working again, but eventually the backups slow to a crawl. Any ideas what's going on here? No errors getting logged to syslog. As I understand from the other forums TimeMachine must use AFP, right? So far with my testing, NFS seems superior for speed a reliability so far.

From what I recall about temperature and hard drives (can't find that report) is that hard drives are pretty tolerant. To kill a hard drive quickly you have to go to extremes. Since hard drives last for many years typically, it's hard to judge what the the threshold is. There was a study completed a long time ago that determined hard drives are happiest between 20 and 30oC. Start going outside of that range and your rate of failure starts to increase long term. So, a few days of 30oC+ is likely not going to cause any impact to the life of the drive. 30oC+ all day every day is a different story. That one report of hitting +5oC? Ouch! That will definitely shorten the life of the drive as it's well outside of the comfort zone. People used to think that making a computer room 18oC helped increase the life of hardware, but it actually hurts them and a huge wast of energy in most climates. I would gather if the hard drive is spun down the effects of temperature on the life of the drive is minimal as well.

You can just install it and point it to your media on unraid, if you want to migrate all of your "watched" meta data then you can find how to do that in the Plex wiki. That is how I used to use my system but I recently moved plex to my unRaid server and bumped the CPU for transcoding. I'm planning on a move to Plex here. Was planning on using an old MacMini that's been collecting dust and dedicating that, but would like to run the Plex server directly on unRAID eventually. I have a simple CPU for now and assume that will need a bump in speed. What do you believe are the minimum CPU and RAM requirements for this? Is a cache drive needed for any Plex activity?

Found something even better: /usr/libexec/upsshutdown It's a built in OS shell script where you can list commands to be execute before a shutdown is sent to the OS. There's even a man page for it. So, I'll arrange for a script to be called that will also include an additional delay to allow the Mac to shutdown before unRAID shuts down.

Oh, yeah, I would make sure the unRAID was the last thing to be shutdown. At home I typically don't let any of my systems run for more than 5 minutes on UPS power. If the power is not back by then, then it won't be back for hours. Switch is on the same UPS too. The next complication is sorting out how apsupsd would run on the iMac. It already has built-in communication tools for UPS's, so I don't know how that would work together (in other words, I don't know how the Mac could be a master or slave at this point). I thought I could configure my Mac to send a command, but looking through the power management tools, but I'm not seeing that. Separate UPS is looking like a more likely solution especially as disk needs grow. I need to revaluate my UPS's at home and sort things out.

I may end up doing that--separate UPS. I've been moving away from APC due to some failures over the years and using CyberPower (not sure where I got Powerware from in my original post there). Does the UPS daemon/pkg only work with APC brand units or more of a generic package? Then, again, I could just get a new UPS for the iMac (CyberPower) and move the APC to the unRAID server.

Just getting my hands dirty with unRAID and finally have a basic system up and running for a few days now. One concern I had was regarding automatically shutting down unRAID during a power failure. I have a 1KVA APC UPS right now with the monitoring cable plugged into my iMac. What's the easiest way to have my unRAID server realize when on battery? My first thought was to configure a script on my Mac to send an SSH command to unRAID to tell it to shutdown. I'm still learning where all of the resources are to various things, so forgive me if I overlooked a document that already spells this out. I'm a 20 year UNIX SA, so hoping to contribute some Linux expertise to this project as well.