Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

unRAID Server Release 5.0-beta11 Available

Featured Replies

Having issues stopping array.. Has done it twice in a row since installing latest beta. emhttp reporting bug, /mnt/user is showing as busy and won't unmount. Have to force shut down...

 

Anyone else having issues with this? Upgraded to -beta11 on a small test server last night and had this happen twice. At first I was convinced that I had left a telnet session open somewhere, but I'm fairly certain that was not the case. Had to force shutdown both times.

 

Having this issue on b10 now i've downgraded too.

  • Replies 178
  • Views 64.6k
  • Created
  • Last Reply

Hi

 

Issue with Slimserver-----

 

Installing  Squeezebox to /usr/local/slimserver looks OK I got following line Squeezebox Server is running and I can continue to config the server.

 

Changing to /mnt/cache/slimserver... it dont show the line Squeezebox Server is running when enabled it. ( i have rebooted severl times with this settings)

 

 

And When slimserver is running in the memory (/usr/local/slimserver) I can't start SABnzb, disable slimserver then I can start SABnzb

 

 

Anyone know why, cant see anything in my syslog, but attached the last line anyway...

 

 

Aug 17 20:08:14 Tower su[11275]: Successful su for nobody by root
Aug 17 20:08:14 Tower su[11275]: +  root:nobody
Aug 17 20:08:14 Tower su[11276]: Successful su for nobody by root
Aug 17 20:08:14 Tower su[11276]: +  root:nobody
Aug 17 20:08:15 Tower su[11319]: Successful su for nobody by root
Aug 17 20:08:15 Tower su[11319]: +  root:nobody
Aug 17 20:08:15 Tower su[11320]: Successful su for nobody by root
Aug 17 20:08:15 Tower su[11320]: +  root:nobody
Aug 17 20:08:15 Tower su[11322]: Successful su for nobody by root
Aug 17 20:08:15 Tower su[11322]: +  root:nobody
Aug 17 20:08:25 Tower su[11563]: Successful su for nobody by root
Aug 17 20:08:25 Tower su[11563]: +  root:nobody
Aug 17 20:09:04 Tower su[12120]: Successful su for nobody by root
Aug 17 20:09:04 Tower su[12120]: +  root:nobody
Aug 17 20:09:07 Tower su[12225]: Successful su for nobody by root
Aug 17 20:09:07 Tower su[12225]: +  root:nobody
Aug 17 20:11:58 Tower su[14335]: Successful su for nobody by root
Aug 17 20:11:58 Tower su[14335]: +  root:nobody
Aug 17 20:12:10 Tower sudo:     root : TTY=console ; PWD=/ ; USER=slimserver ; COMMAND=/usr/local/slimserver/slimserver.pl --daemon --pidfile /var/run/slimserver/slimserver.pid
Aug 17 20:12:17 Tower su[14854]: Successful su for nobody by root
Aug 17 20:12:17 Tower su[14854]: +  root:nobody

 

Best Regards

 

Peter

 

 

 

 

From Beta10:

 

- linux: use Realtek r8168 driver instead of linux r8169 driver

 

From Beta11:

 

- linux: restore linux r8169 driver

 

I'm guessing the Realtek 8111E is still causing problems?  Too bad if that's the case, since the majority of cheap socket 1155 motherboards use that NIC.

 

Just noticed that, so yes that is what is causing the issue.

 

A number of the AMD m-ATX boards also use that...

 

Any reason for putting it back in the first place!?

 

http://lime-technology.com/forum/index.php?topic=14158.msg134868#msg134868

 

Having the same problems with b11 as with b10.  Gone back to b9 (which has been very solid on my production machine).  I hope that this gets resolved before we go to a RC.

 

Y

Upgraded to B11 a few hours after release

 

So far nothing to report that is not "normal".

 

I am not using a cache drive atm.

 

The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg.

This panics the overheat scripts (if running) and puts your server in emergency shutdown.

I have tried 3 different models (Agility, Vertex and Solid3).

 

 

 

Wow thanks Tom.   I upgraded from 4.5 to 4.7 to 5 beta 11...  No problems what so ever with the upgrade.

 

SlimServer a HUGE plus too... wife will be very happy.

 

I ran into just a slight problem with the setup.  Installed SS as per your post, everything went fine.  When I go to set it up, it asks for a playlist directory.  So I created a new folder on my user share, within SS went to /mnt/Share/Storage and the folder is not listed.

 

I tried to stop/start SS, no go.

I stopped the array, rebooted.  No go the folder still does not appear...  Not a big deal, just selected an existing dir.

 

Here is the syslog from the gui..

 

Aug 17 22:51:43 Tower emhttp: Start array...
Aug 17 22:51:43 Tower kernel: mdcmd (41): start STOPPED
Aug 17 22:51:43 Tower kernel: unraid: allocating 43960K for 1280 stripes (8 disks)
Aug 17 22:51:43 Tower kernel: md1: running, size: 1465138552 blocks
Aug 17 22:51:43 Tower kernel: md2: running, size: 732574552 blocks
Aug 17 22:51:43 Tower kernel: md3: running, size: 732574552 blocks
Aug 17 22:51:43 Tower kernel: md4: running, size: 1465138552 blocks
Aug 17 22:51:43 Tower kernel: md5: running, size: 732574552 blocks
Aug 17 22:51:43 Tower kernel: md6: running, size: 1465138552 blocks
Aug 17 22:51:43 Tower kernel: md7: running, size: 732574552 blocks
Aug 17 22:51:44 Tower emhttp: shcmd (23): udevadm settle
Aug 17 22:51:44 Tower emhttp: shcmd (24): /usr/local/sbin/emhttp_event array_started
Aug 17 22:51:44 Tower emhttp_event: array_started
Aug 17 22:51:44 Tower emhttp: Mounting disks...
Aug 17 22:51:44 Tower emhttp: shcmd (25): mkdir /mnt/disk7
Aug 17 22:51:44 Tower emhttp: shcmd (26): mkdir /mnt/disk5
Aug 17 22:51:44 Tower emhttp: shcmd (28): mkdir /mnt/disk4
Aug 17 22:51:44 Tower emhttp: shcmd (27): mkdir /mnt/disk3
Aug 17 22:51:44 Tower emhttp: shcmd (29): mkdir /mnt/disk2
Aug 17 22:51:44 Tower emhttp: shcmd (30): mkdir /mnt/disk1
Aug 17 22:51:44 Tower kernel: mdcmd (42): check CORRECT
Aug 17 22:51:44 Tower kernel: md: recovery thread woken up ...
Aug 17 22:51:44 Tower emhttp: shcmd (31): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md7 /mnt/disk7 |& logger
Aug 17 22:51:44 Tower emhttp: shcmd (32): mkdir /mnt/disk6
Aug 17 22:51:44 Tower emhttp: shcmd (33): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md5 /mnt/disk5 |& logger
Aug 17 22:51:44 Tower emhttp: shcmd (34): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md3 /mnt/disk3 |& logger
Aug 17 22:51:44 Tower emhttp: shcmd (35): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger
Aug 17 22:51:44 Tower emhttp: shcmd (36): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md1 /mnt/disk1 |& logger
Aug 17 22:51:44 Tower emhttp: shcmd (37): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md4 /mnt/disk4 |& logger
Aug 17 22:51:44 Tower emhttp: shcmd (38): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md6 /mnt/disk6 |& logger
Aug 17 22:51:44 Tower kernel: md: recovery thread has nothing to resync
Aug 17 22:51:44 Tower kernel: REISERFS (device md7): found reiserfs format "3.6" with standard journal
Aug 17 22:51:44 Tower kernel: REISERFS (device md3): found reiserfs format "3.6" with standard journal
Aug 17 22:51:44 Tower kernel: REISERFS (device md7): using ordered data mode
Aug 17 22:51:44 Tower kernel: REISERFS (device md3): using ordered data mode
Aug 17 22:51:44 Tower kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal
Aug 17 22:51:44 Tower kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal
Aug 17 22:51:44 Tower kernel: REISERFS (device md2): using ordered data mode
Aug 17 22:51:44 Tower kernel: REISERFS (device md1): using ordered data mode
Aug 17 22:51:44 Tower kernel: REISERFS (device md4): found reiserfs format "3.6" with standard journal
Aug 17 22:51:44 Tower kernel: REISERFS (device md4): using ordered data mode
Aug 17 22:51:44 Tower kernel: REISERFS (device md5): found reiserfs format "3.6" with standard journal
Aug 17 22:51:44 Tower kernel: REISERFS (device md5): using ordered data mode
Aug 17 22:51:44 Tower kernel: REISERFS (device md6): found reiserfs format "3.6" with standard journal
Aug 17 22:51:44 Tower kernel: REISERFS (device md6): using ordered data mode
Aug 17 22:51:44 Tower kernel: REISERFS (device md7): journal params: device md7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug 17 22:51:44 Tower kernel: REISERFS (device md3): journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug 17 22:51:44 Tower kernel: REISERFS (device md7): checking transaction log (md7)
Aug 17 22:51:44 Tower kernel: REISERFS (device md3): checking transaction log (md3)
Aug 17 22:51:44 Tower kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug 17 22:51:44 Tower kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug 17 22:51:44 Tower kernel: REISERFS (device md2): checking transaction log (md2)
Aug 17 22:51:44 Tower kernel: REISERFS (device md1): checking transaction log (md1)
Aug 17 22:51:44 Tower kernel: REISERFS (device md4): journal params: device md4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug 17 22:51:44 Tower kernel: REISERFS (device md5): journal params: device md5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug 17 22:51:44 Tower kernel: REISERFS (device md4): checking transaction log (md4)
Aug 17 22:51:44 Tower kernel: REISERFS (device md5): checking transaction log (md5)
Aug 17 22:51:44 Tower kernel: REISERFS (device md6): journal params: device md6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug 17 22:51:44 Tower kernel: REISERFS (device md6): checking transaction log (md6)
Aug 17 22:51:44 Tower kernel: REISERFS (device md7): Using r5 hash to sort names
Aug 17 22:51:44 Tower kernel: REISERFS (device md5): Using r5 hash to sort names
Aug 17 22:51:44 Tower kernel: REISERFS (device md4): Using r5 hash to sort names
Aug 17 22:51:44 Tower kernel: REISERFS (device md6): Using r5 hash to sort names
Aug 17 22:51:44 Tower kernel: REISERFS (device md2): Using r5 hash to sort names
Aug 17 22:51:44 Tower kernel: REISERFS (device md1): Using r5 hash to sort names
Aug 17 22:51:44 Tower kernel: REISERFS (device md3): Using r5 hash to sort names
Aug 17 22:51:44 Tower emhttp: shcmd (39): chmod 770 '/mnt/disk6'
Aug 17 22:51:44 Tower emhttp: shcmd (40): chmod 770 '/mnt/disk7'
Aug 17 22:51:44 Tower emhttp: shcmd (41): chown nobody:users '/mnt/disk6'
Aug 17 22:51:44 Tower emhttp: shcmd (42): chown nobody:users '/mnt/disk7'
Aug 17 22:51:44 Tower emhttp: shcmd (43): chmod 770 '/mnt/disk5'
Aug 17 22:51:44 Tower emhttp: shcmd (44): chown nobody:users '/mnt/disk5'
Aug 17 22:51:44 Tower emhttp: shcmd (45): chmod 770 '/mnt/disk4'
Aug 17 22:51:44 Tower emhttp: shcmd (46): chown nobody:users '/mnt/disk4'
Aug 17 22:51:44 Tower emhttp: shcmd (47): chmod 770 '/mnt/disk2'
Aug 17 22:51:44 Tower emhttp: shcmd (48): chown nobody:users '/mnt/disk2'
Aug 17 22:51:44 Tower emhttp: shcmd (49): chmod 770 '/mnt/disk3'
Aug 17 22:51:44 Tower emhttp: shcmd (50): chown nobody:users '/mnt/disk3'
Aug 17 22:51:44 Tower emhttp: shcmd (51): chmod 770 '/mnt/disk1'
Aug 17 22:51:44 Tower emhttp: shcmd (52): chown nobody:users '/mnt/disk1'
Aug 17 22:51:44 Tower emhttp: shcmd (53): mkdir /mnt/user
Aug 17 22:51:44 Tower emhttp: shcmd (54): /usr/local/sbin/shfs /mnt/user -disks 254 -o noatime,big_writes,allow_other,default_permissions,use_ino 
Aug 17 22:51:44 Tower emhttp: shcmd (55): crontab -c /etc/cron.d -d &> /dev/null
Aug 17 22:51:44 Tower emhttp: shcmd (56): /usr/local/sbin/emhttp_event disks_mounted
Aug 17 22:51:44 Tower emhttp_event: disks_mounted
Aug 17 22:51:45 Tower emhttp: shcmd (57): :>/etc/samba/smb-shares.conf
Aug 17 22:51:45 Tower emhttp: Restart SMB...
Aug 17 22:51:45 Tower emhttp: shcmd (58): killall -HUP smbd
Aug 17 22:51:45 Tower emhttp: shcmd (59): ps axc | grep -q rpc.mountd
Aug 17 22:51:45 Tower emhttp: _shcmd: shcmd (59): exit status: 1
Aug 17 22:51:45 Tower emhttp: shcmd (60): /usr/local/sbin/emhttp_event svcs_restarted
Aug 17 22:51:45 Tower emhttp_event: svcs_restarted
Aug 17 22:52:15 Tower sudo:     root : TTY=console ; PWD=/ ; USER=slimserver ; COMMAND=/usr/local/slimserver/slimserver.pl --daemon --pidfile /var/run/slimserver/slimserver.pid

I exchanged a 1TB disk for a 3TB disk yesterday evening & started the rebuild. This morning the servers web control panel no longer is accessible, and whenever I mount anything (which takes minutes rather than seconds), I get:

 

"Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details. Switching to read-only mode".

 

I believe somebody has also had this problem a few posts back.

 

My question is, if it is rebuilding and I hard-reset it (As I conclude that it has become unresponsive), is there a chance of data loss?

Changelog:

- linux: restore linux r8169 driver

Thanks Tom - beta11 working very well with my Realtek r8169 NIC (PCI Tenda Gigabit TEL9901G) just like it did prior to beta10.

 

Uggh my AFP issues persist.  I shouldn't really say that since they got much better since setting up my AFP the way Nezil described in the beta 10 thread

 

http://lime-technology.com/forum/index.php?topic=14158.60

 

but I have done some testing on a new hackintosh I built.  The new hack doesn't have my credentials saved for the AFP share so it connects as guest.  When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares.  It's exactly what it should be like!

 

However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares.  I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't?  When I connect as 'redfive', I get a bunch of what's listed below in the syslog:

 

 

Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store
Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store
Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store
Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store
Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store
Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store
Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store
Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store
Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store
Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store
Aug 18 09:20:10 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/HD/.DS_Store
Aug 18 09:20:11 EchoBase shfs/user: duplicate object: /mnt/disk9/Movies/HD/.DS_Store
Aug 18 09:20:15 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store
Aug 18 09:20:15 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store
Aug 18 09:20:16 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store
Aug 18 09:20:16 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store

 

I don't see this connecting as guest.  It's getting to the point where I may just open up full access to the shares to everyone because it's quicker viewing them that way.  If I connect as 'redfive' on my hack, I'm back to waiting.  Maybe Nezil knows what's up with this?  :)

 

Btw this is not really a beta 11 issue, same thing happened in beta 10.  Just figured since Tom was able to get the final version of Netatalk that some of the issues might be solved. 

Those .DS_Store files are not the fault of netatalk.  It is something the Mac creates to keep track of Finder window position and settings.

 

There is an unMenu package that will delete these from the server via a cron task.  You can also do a google search to disable that creation on a network share permanently.

but I have done some testing on a new hackintosh I built.  The new hack doesn't have my credentials saved for the AFP share so it connects as guest.  When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares.  It's exactly what it should be like!

 

However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares.  I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't?  

 

What happens when you select the share in the Finder sidebar is that all the hard disks will spin up (maybe to check permissions, dunno..). As long as the drives are all spun up, access to the share will be instantaneous.

 

I'm not sure if Tom will be able to fix this, as the Netatalk daemon performs this check, not unRAID.

but I have done some testing on a new hackintosh I built.  The new hack doesn't have my credentials saved for the AFP share so it connects as guest.  When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares.  It's exactly what it should be like!

 

However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares.  I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't?  

 

What happens when you select the share in the Finder sidebar is that all the hard disks will spin up (maybe to check permissions, dunno..). As long as the drives are all spun up, access to the share will be instantaneous.

 

I'm not sure if Tom will be able to fix this, as the Netatalk daemon performs this check, not unRAID.

Have you tried Cache_Dirs on your unraid and see if this still holds true?

I'd hate to spin up 20 disks to find one file.

but I have done some testing on a new hackintosh I built.  The new hack doesn't have my credentials saved for the AFP share so it connects as guest.  When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares.  It's exactly what it should be like!

 

However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares.  I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't?  

 

What happens when you select the share in the Finder sidebar is that all the hard disks will spin up (maybe to check permissions, dunno..). As long as the drives are all spun up, access to the share will be instantaneous.

 

I'm not sure if Tom will be able to fix this, as the Netatalk daemon performs this check, not unRAID.

Have you tried Cache_Dirs on your unraid and see if this still holds true?

I'd hate to spin up 20 disks to find one file.

 

Yep, cache_dirs is running and works perfectly for Samba shares.

 

The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg.

This panics the overheat scripts (if running) and puts your server in emergency shutdown.

I have tried 3 different models (Agility, Vertex and Solid3).

 

This is also the case in windows. 

 

The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg.

This panics the overheat scripts (if running) and puts your server in emergency shutdown.

I have tried 3 different models (Agility, Vertex and Solid3).

 

This is also the case in windows. 

Thanks.

I never looked at that. Time to try another vendor then.

I exchanged a 1TB disk for a 3TB disk yesterday evening & started the rebuild. This morning the servers web control panel no longer is accessible, and whenever I mount anything (which takes minutes rather than seconds), I get:

 

"Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details. Switching to read-only mode".

 

I believe somebody has also had this problem a few posts back.

 

My question is, if it is rebuilding and I hard-reset it (As I conclude that it has become unresponsive), is there a chance of data loss?

 

No.

 

I just telnet in and manually delete the three .Apple files, then the problem is fixed!

 

The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg.

This panics the overheat scripts (if running) and puts your server in emergency shutdown.

I have tried 3 different models (Agility, Vertex and Solid3).

 

This is also the case in windows. 

Thanks.

I never looked at that. Time to try another vendor then.

 

Do the SSD's produce any unique identifiers that sets them aside from a standard hard drive?

 

The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg.

This panics the overheat scripts (if running) and puts your server in emergency shutdown.

I have tried 3 different models (Agility, Vertex and Solid3).

 

This is also the case in windows. 

Thanks.

I never looked at that. Time to try another vendor then.

 

Do the SSD's produce any unique identifiers that sets them aside from a standard hard drive?

Other then the vendor ID, I don't believe so. My Mushkin SSD's work fine. I just wanted to use the Cheaper/Faster OCZ Solid3.

 

The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg.

This panics the overheat scripts (if running) and puts your server in emergency shutdown.

I have tried 3 different models (Agility, Vertex and Solid3).

 

This is also the case in windows. 

Thanks.

I never looked at that. Time to try another vendor then.

 

Do the SSD's produce any unique identifiers that sets them aside from a standard hard drive?

Other then the vendor ID, I don't believe so. My Mushkin SSD's work fine. I just wanted to use the Cheaper/Faster OCZ Solid3.

 

The faster SSD won't help. The network is the bottleneck.

b11 seems to work fine with me, I am using pretty standard hardware such the SLAPS MV8 cards, and so far everything seems fine. All my disk spindown.

 

On another note I wrote SABnzbd-0.6.8 plg, if anyone want to overlook it that would be greatly appreciated. First script ever written, I am use to vb .net so google came in very handy.

 

Anyhow plg script is here:

 

http://pastebin.com/zvPTb8QE

 

I tested and it seems to work for the most part. I say for the most part, because you never know. I use the slimserver as the base.

Getting the kernel oops on array stop with my other unRAID server too. It appears to safely unmount all of the drives, but the user mount is what stops it.

I have stopped and started my array several times without an issue over the last few days.

 

I just hit the "stop array" button in unmenu and it froze up the sever and killed the web connections  to both default unraid web gui and unmenu. i had to hard reset with power switch

 

I never use that button so for all i know it is bugged in 5x.

Savestheday: same lag with displaying shares in Finder via AFP occurs for me too. I haven't tried with a guest account, but when I connect to the server via Samba, they load up instantly.

 

I will try spinning up the drives and see if they load instantly through AFP. Also, I'll try to "ls" on the mounted volumes through Terminal to see if it's strictly a Finder issue. Because even when the shares are mounted and displayed on my desktop, clicking under Shared on the left menu in Finder will act like it's connecting for the first time -- could just be a symptom of the comatose drives.

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.

Please if someone could help, this is my second try at rebuilding parity & expanding the array after replacing a 1TB drive with a 3 TB. It starts up, says it will take 700 minutes to complete, after two hours the web panel is still accessible, I leave it overnight, and in the morning the machine is non responsive. IF I reset it the whole rebuilding starts over.

Getting the kernel oops on array stop with my other unRAID server too. It appears to safely unmount all of the drives, but the user mount is what stops it.

 

I got the same problem and had to use button to shut down the server.

 

I have no syslog files  :-\

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.