unRAID Server Release 6.0-beta3-x86_64 Available


limetech

Recommended Posts

Please, do not run the Plex 64-bit server plugin. Its a Frankenstein of packages not even remotely official from the guys at Plex. It has been brought to their attention but they are waiting until unRAID 6.0 is in RC status before they release a official, tested package.

 

Sent from my LG-VS980 using Tapatalk

 

All true statements. However Plex 64bit has been running perfectly for myself and many others. What I have been seeing on this thread are issues related to individual configurations and not Plex itself. That being said it is a Frankenstein of a package but it has been stable for many people and I am personally greatly enjoying the vast benefits I have been receiving from 64bit.

 

What are the vast benefits of running 64 bit?

Link to comment
  • Replies 661
  • Created
  • Last Reply

Top Posters In This Topic

Please, do not run the Plex 64-bit server plugin. Its a Frankenstein of packages not even remotely official from the guys at Plex. It has been brought to their attention but they are waiting until unRAID 6.0 is in RC status before they release a official, tested package.

 

Sent from my LG-VS980 using Tapatalk

 

All true statements. However Plex 64bit has been running perfectly for myself and many others. What I have been seeing on this thread are issues related to individual configurations and not Plex itself. That being said it is a Frankenstein of a package but it has been stable for many people and I am personally greatly enjoying the vast benefits I have been receiving from 64bit.

 

What are the vast benefits of running 64 bit?

And you should still be able to run them 64bit in a VM with a few % drop like iconicbadger has posted.
Link to comment

I just have to chime in here for an FYI effect :-)

 

Just an FYI, but keep in mind that you might not need to pass usb "controller" at all in at least 99% of cases.  just usb device.

 

when UnRaid is run as VM , the only reason to pass USB controller was/is so license verification code can read the GUID from the device(flash stick).

somehow when you pass only the device into VM, the GUID read is not working it might be a controller function that are not available in VM.

 

so try to evaluate if you actually need to pass the whole controller or can simply pass only the device attached to it.

 

I might not be the best use case for this example, but I have yet to find but one case where I need to pass usb controller to VM other than to unraid flash drive use.

 

Thanks for that, but that's exactly what I'm attempting to do as USB controller passthrough is proving unreliable.

 

However, without 'lsusb', I cannot enumerate my usb devices, unless there's another way?

 

Thanks

 

Peter

 

Link to comment

Please, do not run the Plex 64-bit server plugin. Its a Frankenstein of packages not even remotely official from the guys at Plex. It has been brought to their attention but they are waiting until unRAID 6.0 is in RC status before they release a official, tested package.

 

Sent from my LG-VS980 using Tapatalk

 

All true statements. However Plex 64bit has been running perfectly for myself and many others. What I have been seeing on this thread are issues related to individual configurations and not Plex itself. That being said it is a Frankenstein of a package but it has been stable for many people and I am personally greatly enjoying the vast benefits I have been receiving from 64bit.

 

Ditto.  I also just self-upgraded to a frankensteined plexpass version last night.  running non-xen boot option.  I'll give it a few days and we'll see how it fairs.

 

And in case this sounds too OT, the idea I believe is still valid that their might be something going on with how the Xen bits are interacting.  Sure the ideal is to run something like Plex in a VM (that is my eventual goal), however that doesn't mean Plex on the host isn't exposing an issue worth dealing with especially when it comes to memory leaks.

 

Or it could be plex not playing well.  That is the point of betas.

Link to comment

And you should still be able to run them 64bit in a VM with a few % drop like iconicbadger has posted.

 

Does any one have any benchmarks to back up the claim of Plex performance bare metal vs VM?

Just what Grumpy and badger have posted.  No evidence either way personally since I have not started using unRAID 6.0 yet.  I know in ESXi I don't see much decrease in speed in my VMs on FFMPEG encodes (SageTV transcoder) - don't use plex so can't really say for sure there.  And by all accounts ESXi is suppose to be SLOWER than Xen.
Link to comment

Thanks for that, but that's exactly what I'm attempting to do as USB controller passthrough is proving unreliable.

 

However, without 'lsusb', I cannot enumerate my usb devices, unless there's another way?

 

Here you go...

 

wget http://ftp.lip6.fr/pub/linux/distributions/slackware/slackware64-14.1/slackware64/a/usbutils-007-x86_64-1.txz

installpkg usbutils-007-x86_64-1.txz

Link to comment

If you are booted into Xen mode, then if you look at the syslinux.cfg file you will see that Dom_0 is set to use only 2GB of memory which may explain why you are running out.  You should either run Plex in a VM or alternatively try editing syslinux.cfg to allow more RAM for Dom_0.

 

It might be helpful if when people post about issues with 6.0-beta, they also include the details of their syslinux.cfg file (whether it is stock with the 2GB mem limit, no CPU limit) or their custom changes.

 

I noticed issues right away when I first started using 6.0-beta with the 2GB limit, and started installing 64-bit versions of the plugins I was using with unRaid 5.0.  I removed the memory limit, and have had no issues since.  Once I begin to migrate my plugins to VMs, I will then re-evaluate the memory and CPU resources I assign to Dom0 unRaid.

Link to comment

Does any one have any benchmarks to back up the claim of Plex performance bare metal vs VM?

 

We aren't reinventing the wheel or blazing new trails in Virtualization.

 

Businesses / Enterprises have been virtualizing MILLIONs of Servers which run very complex multi-million apps like ERP, Video Conferencing, etc. for over a decade.

 

There are PLENTY of users here in the unRAID forum who use Plexx in a VM in either XenServer or ESXi. Not to mention the MILLIONS of home users who run ESXi / XenServer with Plex in a VM (who don't use unRAID and posts in other forums).

 

Simply put... You won't notice any difference with your Plex App running in a VM with Paravirtualized Drivers compared to bare metal.

Link to comment

Thanks for that, but that's exactly what I'm attempting to do as USB controller passthrough is proving unreliable.

 

However, without 'lsusb', I cannot enumerate my usb devices, unless there's another way?

 

Here you go...

 

wget http://ftp.lip6.fr/pub/linux/distributions/slackware/slackware64-14.1/slackware64/a/usbutils-007-x86_64-1.txz

installpkg usbutils-007-x86_64-1.txz

 

Super, thanks.

Link to comment

london - from the console or telnet just type the 'sync' command - it may or may not come back - no matter.  Wait about 90 seconds and then reset your server.  Yes RESET that thing.  When server reboots it will start a parity check.  You can let this finish or cancel it.  As long as I/O quiesced before the reset there should be no parity errors.  This is a test server right?

 

Hi I completed the resync successfully however the shares were still not shown. so I stopped the array, this time successfully, then I created a new share "series" which existed before. Under /mnt/disk1 I can see the directories

 

 

root@Tower:/mnt/user# ls

series/

root@Tower:/mnt/user# cd series/

root@Tower:/mnt/user/series# ls

root@Tower:/mnt/user/series# cd .

root@Tower:/mnt/user/series# cd ../..

root@Tower:/mnt# cd disk1

root@Tower:/mnt/disk1# ls

backup/  ebooks/  misc/  movies/  music/  series/  software/  training/

root@Tower:/mnt/disk1# cd series

root@Tower:/mnt/disk1/series# ls

Heroes\ Unmasked/

History\ Channel\ Documentaries/

Hotel\ Babylon/

House/

How\ I\ met\ your\ mother/

How\ the\ Earth\ was\ made/

How\ to\ make\ it\ in\ America/

Human\ Planet/

Hung/

Hustle/

Impact/

In\ Plain\ Sight/

It's\ Always\ Sunny\ In\ Philadelphia/

Jack\ &\ Bobby/

Jeremiah/

Jericho\ (2006)/

John\ Adams/

Lark\ Rise\ to\ Candleford/

Legend\ of\ the\ Seeker/

Leverage/

Lie\ to\ me/

Lost\ Girl/

The\ Lion\ Man/

The\ Listener/

The\ Lost\ Room/

The\ Mentalist/

The\ Net/

The\ No\ \ 1\ Ladies\ Detective\ Agency/

The\ Oprah\ Winfrey\ Show/

The\ Pacific/

The\ Penguins\ of\ Madagascar/

The\ Phantom/

The\ Pillars\ of\ the\ Earth/

The\ Practice/

The\ Prisoner/

The\ Prisoner\ (2009)/

The\ Promise/

The\ Secret\ Life\ of\ the\ American\ Teenager/

The\ Walking\ Dead/

root@Tower:/mnt/disk1/series#

 

so any other suggestions how I get access to my data again?

syslog_10022014.txt

Link to comment

Running Plex in a VM is going to work better than running it bare metal on unRAID.

 

It seems many people think a VM is going to slow them down. I advise them to try it, sit back and watch. It works, perfectly. You take only a couple % overall performance hit in a Xen VM, that's the whole point!

 

Someone said earlier it's like herding cats, I feel like I've said the above dozens of times already! Argh!

 

Time to go for a lie down.

 

Did we mention? BETA?

 

For what it's worth, my intent of running Plex on bare metal was not concern over performance degradation in a VM, but more to give it the maximum available resources, rather than constraining it within a VM. In hindsight this wasn't smart when using the default Xen config where the host is constrained to 2GB memory.

 

Additionally, the library I have is substantial, so there seemed to be a good reason to provide the entire cache disk to play with. Since then, someone has posted how to create 100GB data disks, which I will try in the future.

 

You need to recognize that people are looking at things from different perspectives, and may have different reasons for running certain configurations. You may feel that you are 'herding cats', but virtualization (while great) isn't necessarily the answer for everything, and it's only through testing and experimentation that people are going to arrive at the solution that best fits their requirements.

Link to comment

It might be helpful if when people post about issues with 6.0-beta, they also include the details of their syslinux.cfg file (whether it is stock with the 2GB mem limit, no CPU limit) or their custom changes.

 

I noticed issues right away when I first started using 6.0-beta with the 2GB limit, and started installing 64-bit versions of the plugins I was using with unRaid 5.0.  I removed the memory limit, and have had no issues since.  Once I begin to migrate my plugins to VMs, I will then re-evaluate the memory and CPU resources I assign to Dom0 unRaid.

 

I suggested the following and Tom has said they are going into the next release:

 

1. Do not assign a set amount of memory to Dom0 and make syslinux.cfg look like this:

 

label Xen 4.3.1 / unRAID OS
  kernel /syslinux/mboot.c32
  append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot
label Xen 4.3.1 / unRAID OS Safe Mode (no plugins)
  kernel /syslinux/mboot.c32
  append /xen  --- /bzimage --- /bzroot unraidsafemode

 

Since a lot of people use a Cache Directories (a memory hog), let Dom0 get assigned all the memory. That way if memory runs low, the VM has the issues / crash (as a previous user a few posts up experienced) and not unRAID.

 

Even with all the memory assigned to Dom0 (unRAID), the VMs can still use / grab it but unRAID has the priority and will take back what it needs.

 

Note - By default, this how most Linux Distros handle it.

 

2. You will probably want to dedicate at least one CPU to Dom0 by default.

 

label Xen 4.3.1 / unRAID OS
  kernel /syslinux/mboot.c32
  append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot
label Xen 4.3.1 / unRAID OS Safe Mode (no plugins)
  kernel /syslinux/mboot.c32
  append /xen --- /bzimage --- /bzroot unraidsafemode

 

  a) Dedicating a CPU core only for dom0 makes sure dom0 always has free CPU time to process the IO requests for the domUs.

 

  b) When dom0 has a dedicated core there are less CPU context switches to do, giving better performance.

 

  c) Assigning more than one isn't going to make Dom0, write files faster to unRAID or make the VMs run any faster.

 

Link to comment

is anyone having permissions issues?  I have a temp dir that has downloads folder from all the computers redirected to. I cant run an exe from there unless change the permissions on it. ran the new permissions on the gui no change have to manually change it.

Yes this is a known difference in behavior in samba4 (what's in unRaid 6) vs. samba3 (what's in unRaid 5).  I will eventually investigate this further but the workaround is to mark your executables as "executable".

Link to comment

london - from the console or telnet just type the 'sync' command - it may or may not come back - no matter.  Wait about 90 seconds and then reset your server.  Yes RESET that thing.  When server reboots it will start a parity check.  You can let this finish or cancel it.  As long as I/O quiesced before the reset there should be no parity errors.  This is a test server right?

 

Hi I completed the resync successfully however the shares were still not shown. so I stopped the array, this time successfully, then I created a new share "series" which existed before. Under /mnt/disk1 I can see the directories

 

 

root@Tower:/mnt/user# ls

series/

root@Tower:/mnt/user# cd series/

 

When you login via telnet/ssh/console you are user 'root'.  Any file/directory you create will be owned by 'root' in group 'root'.  The unRaid security model has all shares owned by user 'nobody' in group 'users'.  Restricting access according to Public/Secure/Private security modes is done via the protocol components (Samba, netatalk, etc).  Any dirs in a group other than 'users' will not be visible on the network.  You need to be aware of this when working on the command line.

 

There are two ways to solve the current situation.  One is to execute a 'chown nobody:users' on the affected files/directories.  The other is to run the 'New Permissions' utility via the webGui.

 

To prevent this from happening in the future there is a 'user' alias built into the root .bash_profile script that you can use like this:

 

user nobody

<all files/dirs you create will be owned by 'nobody:users'>

exit  <return control to 'root'>

 

If any of the above sounds like a foreign language, you probably should not be using the command line  ;D

Link to comment

london - from the console or telnet just type the 'sync' command - it may or may not come back - no matter.  Wait about 90 seconds and then reset your server.  Yes RESET that thing.  When server reboots it will start a parity check.  You can let this finish or cancel it.  As long as I/O quiesced before the reset there should be no parity errors.  This is a test server right?

 

Hi I completed the resync successfully however the shares were still not shown. so I stopped the array, this time successfully, then I created a new share "series" which existed before. Under /mnt/disk1 I can see the directories

 

 

root@Tower:/mnt/user# ls

series/

root@Tower:/mnt/user# cd series/

 

When you login via telnet/ssh/console you are user 'root'.  Any file/directory you create will be owned by 'root' in group 'root'.  The unRaid security model has all shares owned by user 'nobody' in group 'users'.  Restricting access according to Public/Secure/Private security modes is done via the protocol components (Samba, netatalk, etc).  Any dirs in a group other than 'users' will not be visible on the network.  You need to be aware of this when working on the command line.

 

There are two ways to solve the current situation.  One is to execute a 'chown nobody:users' on the affected files/directories.  The other is to run the 'New Permissions' utility via the webGui.

 

To prevent this from happening in the future there is a 'user' alias built into the root .bash_profile script that you can use like this:

 

user nobody

<all files/dirs you create will be owned by 'nobody:users'>

exit  <return control to 'root'>

 

If any of the above sounds like a foreign language, you probably should not be using the command line  ;D

 

done that but I still cannot see my data in the directory

 

 

drwxrwxrwx  3 root  root    0 Feb 10 16:32 user/

drwxrwxrwx  1 nobody users 272 Jan 19 13:50 user0/

root@Tower:/mnt# cd user

root@Tower:/mnt/user# chown nobody:users

chown: missing operand after ‘nobody:users’

Try 'chown --help' for more information.

root@Tower:/mnt/user# cd ..

root@Tower:/mnt# chown nobody:users user

root@Tower:/mnt# ls -l

total 0

drwxrwxrwx  6 nobody users 136 Feb  7 17:25 cache/

drwxrwxrwx 12 nobody users 272 Jul 28  2011 disk1/

drwxrwxrwx  5 nobody users 104 Oct  6 17:37 disk10/

drwxrwxrwx  6 nobody users 128 Jul 15  2011 disk11/

drwxrwxrwx 10 nobody users 232 Aug  6  2011 disk12/

drwxrwxrwx  6 nobody users 128 Sep 11  2011 disk13/

drwxrwxrwx 10 nobody users 224 Mar 27  2013 disk14/

drwxrwxrwx 13 nobody users 296 Jan 19 13:50 disk15/

drwxrwxrwx 10 nobody users 224 Apr 13  2013 disk16/

drwxrwxrwx  9 nobody users 200 Jun 18  2013 disk17/

drwxrwxrwx  9 nobody users 200 Nov 11 21:25 disk18/

drwxrwxrwx 10 nobody users 224 Jun 29  2013 disk2/

drwxrwxrwx  8 nobody users 176 Jun 29  2013 disk3/

drwxrwxrwx  8 nobody users 176 Jun 26  2011 disk4/

drwxrwxrwx  8 nobody users 176 Jan  5  2013 disk5/

drwxrwxrwx 10 nobody users 232 Jun  1  2013 disk6/

drwxrwxrwx  6 nobody users 128 Jul  9  2011 disk7/

drwxrwxrwx  6 nobody users 128 Jul 23  2011 disk8/

drwxrwxrwx  7 nobody users 160 Jul 25  2011 disk9/

drwxrwxrwx  3 nobody users  0 Feb 10 16:32 user/

drwxrwxrwx  1 nobody users 272 Jan 19 13:50 user0/

root@Tower:/mnt# cd user

root@Tower:/mnt/user# ls

series/

root@Tower:/mnt/user# cd series

root@Tower:/mnt/user/series# cd ..

root@Tower:/mnt/user# ls -l

total 0

drwxrwxrwx 2 nobody users 0 Feb 10 16:32 series/

root@Tower:/mnt/user# cd series

root@Tower:/mnt/user/series# ls -l

total 0

root@Tower:/mnt/user/series# cd ..

root@Tower:/mnt/user# ls -l

total 0

drwxrwxrwx 2 nobody users 0 Feb 10 17:19 movies/

drwxrwxrwx 2 nobody users 0 Feb 10 16:32 series/

root@Tower:/mnt/user# cd movies/

root@Tower:/mnt/user/movies# ls -l

total 0

root@Tower:/mnt/user/movies#

 

I will now run the permissions script

Link to comment

We aren't reinventing the wheel or blazing new trails in Virtualization.

Businesses / Enterprises have been virtualizing MILLIONs of Servers which run very complex multi-million apps like ERP, Video Conferencing, etc. for over a decade.

 

Correct. I work for one such businesses and manage a very large VMWare farm that is primarily utilized for web based applications. (Apache and JBoss).

 

However when it comes to CPU intensive items the general industry consensus is to not virtualize. That is why you rarely if ever see database servers virtualized.

 

I count Plex as very CPU intensive. And I will grant you I may be very very much overthinking it. I am looking forward to running my own tests once I have a better way to access my unRAID disks from a VM that does not require NFS/Samba. Something I am actively researching. And my bias against NFS is my own.

Link to comment

will the new permission also set the permission on the usb key which holds the shares configuration?

 

I can see the following:

 

 

root@Tower:/boot/config# ls -l

total 48

-rwxrwxrwx 1 root root  256 Apr  9  2013 Pro1.key*

-rwxrwxrwx 1 root root 8264 Feb  7 17:22 disk.cfg*

-rwxrwxrwx 1 root root  71 Jan 31 18:55 go*

-rwxrwxrwx 1 root root  320 Feb  6 21:39 ident.cfg*

-rwxrwxrwx 1 root root  267 Feb  6 21:45 network.cfg*

drwxrwxrwx 3 root root 4096 Jan 31 18:55 plugins/

-rwxrwxrwx 1 root root  495 Feb 10 17:20 share.cfg*

drwxrwxrwx 2 root root 4096 Feb  7 22:00 shares/

drwxrwxrwx 2 root root 4096 Feb  9 14:40 ssh/

-rwxrwxrwx 1 root root 4096 Feb 10 16:31 super.dat*

 

 

-rwxrwxrwx 1 root root 447 Feb  4 21:53 appdata.cfg.bak*

-rwxrwxrwx 1 root root 493 Apr 13  2013 apps.cfg*

-rwxrwxrwx 1 root root 423 Jul  2  2011 backup.cfg*

-rwxrwxrwx 1 root root 504 Feb  6 21:43 cache_only.cfg.bak*

-rwxrwxrwx 1 root root 422 Jul  3  2011 downloads.cfg*

-rwxrwxrwx 1 root root 447 May 22  2011 ebooks.cfg*

-rwxrwxrwx 1 root root 444 Apr 13  2013 misc.cfg*

-rwxrwxrwx 1 root root 446 Feb 10 17:20 movies.cfg*

-rwxrwxrwx 1 root root 445 Feb  6 22:48 movies.cfg.bak*

-rwxrwxrwx 1 root root 472 Jul 30  2011 music.cfg*

-rwxrwxrwx 1 root root 445 Feb  6 22:49 music.cfg.bak*

-rwxrwxrwx 1 root root 444 Aug  6  2011 photos.cfg*

-rwxrwxrwx 1 root root 446 Feb 10 16:32 series.cfg*

-rwxrwxrwx 1 root root 445 Feb  7 21:54 series.cfg.bak*

-rwxrwxrwx 1 root root 446 Jul 30  2011 software.cfg*

-rwxrwxrwx 1 root root 444 Aug  6  2011 timemachine.cfg*

-rwxrwxrwx 1 root root 447 May 22  2011 training.cfg*

-rwxrwxrwx 1 root root 443 Jan 19 13:50 vincent.cfg*

-rwxrwxrwx 1 root root 455 Jun 18  2013 xbmc.cfg*

 

all are owned by root, is that meant to be the case?

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.