unRAID Server Release 5.0-rc13 Available

[Ford Prefect]

 

....don't have unRAID running since a long time ;-)

 

 

What do you use then?

 

ZFS on a Solaris 11 box...I left unRAID because I needed FullDiskEncryption (Where I am limited to LUKS or Solaris for external compliance reasons)

[johnodon]

Intrigued by these reports of rc13 not stopping, I just tried it on my server.  No problems stopping, full of plugins, and some unmenu packages - if anything it is quicker to stop than with earlier releases.

 

I have not seen this issue either but I am not running any plugins.

 

John

[johnodon]

As a matter of interest, by this morning, the Movies share can be accessed without problems - I guess that something had performed an automatic umount in the meantime.

What's the final status then?  Now working?

Probably the sequence that needs to happen is something like this:

1. un-mount all NFS shares on each client machine

2. create the extra.cfg file with the line shfsExtra="-o noforget"

3. stop/start array for step 2 to take effect

4. re-connect (re-mount) shares on client machines.

 

Now as long as server is not reset, shutdown, or array stop/started, NFS should not get stale file handles.  But if server is reset/shutdown/stopped, then you should also un-mount/re-mount shares on client side as well.  Probably should use 'soft' mount option on clients as well.

 

I am still confused if this addresses the issue I have seen here:  http://lime-technology.com/forum/index.php?topic=27720.msg244928#msg244928

 

If so, I leave my OpenELEC system on 24/7.  Every time I restart unRAID, that means that my OpenELEC machines will no longer be able to reach my media shares unless I unmounts/remount the NFS shares???

 

I hope this is not the case.  I really don't want phone calls from my wife saying that she is unable to put a movie on for my two young boys who are driving here bonkers. 

 

John

[Cessquill]

Just thought I'd try a restart after some of the comments on here.  I'd successfully updated from 12a to 13 and run a parity check, but not transferred any data.  I stopped the array and hit reboot and everything went down OK.

 

It didn't come back up again though.  No web interface, no ping on its IP address.  It's a headless unit, so I couldn't see a screen.  I waited for 30 minutes, then tapped the power button.  It appeared to shut down gracefully, then I powered up again.

 

This time it came back up fine.  It didn't automatically start a parity check, so I assume the system thinks all is well.  I captured a system log from the web interface after this clean boot, but I assume it won't contain anything useful, since - well - it's of a clean boot.

 

Hopefully this is just a glitch, but I thought I'd post in case anybody else is having reboot issues.  I only really encountered problems with 12a when I was copying a lot of data all at once, or if I'd put a lot on the cache drive.  I suspect that's an out of memory issue, but the machine would just disappear off the network.  My box is a couple of years old now, and I really need to get together the spec and put it in my signature.

syslog.txt.txt

[PeterB]

If so, I leave my OpenELEC system on 24/7.  Every time I restart unRAID, that means that my OpenELEC machines will no longer be able to reach my media shares unless I unmounts/remount the NFS shares???

 

If you reboot the server while a client has shares open, it's almost bound to cause a problem.  I wouldn't consider your experience to be unexpected behaviour, and certainly not a fault.

 

I'm wondering why you would want to restart the server frequently.  In any case, if the server has been restarted, can your wife not reboot the OpenELEC machines too?

[Frank1940]

I also tested the 'array stop' and 'reboot' without any problems in my test bed server. 

 

I have SF, unMENU and apcupsd (ver 3.14.10) installed...

[johnodon]

If so, I leave my OpenELEC system on 24/7.  Every time I restart unRAID, that means that my OpenELEC machines will no longer be able to reach my media shares unless I unmounts/remount the NFS shares???

 

If you reboot the server while a client has shares open, it's almost bound to cause a problem.  I wouldn't consider your experience to be unexpected behaviour, and certainly not a fault.

 

I'm wondering why you would want to restart the server frequently.  In any case, if the server has been restarted, can your wife not reboot the OpenELEC machines too?

 

Since unRAID is running on ESXi and I patch ESXi monthly, unRAID is shutdown at least once a month.

 

So Peter, let me ask you since I know we do things kinda the same way...

 

Since upgrading to RC13, your OpenELEC systems can access your NFS shares without issue (after applying the "fix"?)?

 

I have a vanilla unRAID RC13 running with no changes to my OpenELEC clients and they cannot access my NFS shares.  When I try to watch a movie, OpenELEC tells me that the file is not longer avaialble and if I would like to remove it from the library.  And this is after a fresh boot on OpenELEC which I assume would effectively unmount/remount the share.

 

If I then shutdown unRAID and roll back to RC12a (leaving the OpenELEC system on the entire time), I can start the same movie without issue.

 

John

 

[PeterB]

Since unRAID is running on ESXi and I patch ESXi monthly, unRAID is shutdown at least once a month.

 

Okay - well I think that you will have to get into the habit of rebooting your OpenELEC media players every time you reboot the server.  With the frequency of power cuts here, this has never been a problem for me.

 

So Peter, let me ask you since I know we do things kinda the same way...

 

Since upgrading to RC13, your OpenELEC systems can access your NFS shares without issue (after applying the "fix"?)?

 

I have a vanilla unRAID RC13 running with no changes to my OpenELEC clients and they cannot access my NFS shares.  When I try to watch a movie, OpenELEC tells me that the file is not longer avaialble and if I would like to remove it from the library.  And this is after a fresh boot on OpenELEC which I assume would effectively unmount/remount the share.

 

Wow, you're right - I'd not tried OpenELEC since installing rc13.  The Movies share isn't accessible, nor my xbmc share, which is where all my thumbnails are held.  The pxe boot is working fine, as are the 'storage' directories (direct share from the cache drive) - else my custom settings wouldn't load, and the sql database is working too, but no media files are found (on user shares).

 

I can see all the mount requests in the unRAID syslog:

Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 PXE(eth0) c8:60:00:bd:ea:53 proxy
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 tags: eth0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 bootfile name: pxelinux.0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  1 option: 53:message-type  02
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  4 option: 54:server-identifier  10.2.0.100
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  9 option: 60:vendor-class  50:58:45:43:6c:69:65:6e:74
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 17 option: 97:client-machine-id  00:00:36:8d:33:40:b8:dc:11:a4:06:c8:60...
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 52 option: 43:vendor-encap  06:01:03:08:07:80:00:01:0a:02:00:64:09...
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 PXE(eth0) 10.2.1.23 c8:60:00:bd:ea:53 pxelinux.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 tags: eth0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 bootfile name: pxelinux.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 next server: 10.2.0.100
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  1 option: 53:message-type  05
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  4 option: 54:server-identifier  10.2.0.100
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  9 option: 60:vendor-class  50:58:45:43:6c:69:65:6e:74
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 17 option: 97:client-machine-id  00:00:36:8d:33:40:b8:dc:11:a4:06:c8:60...
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 28 option: 43:vendor-encap  47:04:80:00:00:00:0a:13:00:50:72:65:73...
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: error 0 TFTP Aborted received from 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: failed sending /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: file /mnt/cache/dnsmasq/pxelinux.cfg/00368d33-40b8-dc11-a406-c86000bdea53 not found
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.cfg/01-c8-60-00-bd-ea-53 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/openelec/KERNEL to 10.2.1.23
Jun  5 20:57:20 Tower dnsmasq-dhcp[6720]: 859716585 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:21 Tower dnsmasq-dhcp[6720]: 859716585 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:21 Tower mountd[5504]: authenticated mount request from 10.2.1.23:687 for /mnt/cache/dnsmasq/openelec (/mnt/cache)
Jun  5 20:57:22 Tower mountd[5504]: authenticated mount request from 10.2.1.23:693 for /mnt/cache/dnsmasq/openelec/storage (/mnt/cache)
Jun  5 20:57:22 Tower mountd[5504]: authenticated mount request from 10.2.1.23:697 for /mnt/cache/dnsmasq/openelec/storage/c86000bdea53 (/mnt/cache)
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 client provides name: XBMC_Sala
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 client provides name: XBMC_Sala
Jun  5 20:57:43 Tower mountd[5504]: authenticated mount request from 10.2.1.23:708 for /mnt/user/xbmc (/mnt/user/xbmc)
Jun  5 21:00:38 Tower fan_speed.sh: Highest disk drive temp is: 38C
Jun  5 21:00:38 Tower fan_speed.sh: Changing disk drive fan speed from: [72 (28% @ 847 rpm) ] to: [108 (42% @ 1256 rpm) ]
Jun  5 21:00:47 Tower mountd[5504]: authenticated mount request from 10.2.1.23:724 for /mnt/user/Movies (/mnt/user/Movies)
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Vendor class: dhcpcd 4.0.15
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Vendor class: dhcpcd 4.0.15

The disk shares are accessible to OpenELEC, but the user shares aren't.

 

This is a dead loss ... back to rc10 for me.

 

However, I have to say that I don't believe that any of this is directly related to the stale file handle problem.

[optiman]

I now have a problem with AFP.  In short, after a clean reboot, I cannot connect to my unraid server from my imac via AFP.  This worked fine in the past.  I have found that if I disable AFP and then enable again, it starts working and I can connect.  It seems to work until I reboot, where I have to disable and then enable again.

 

I don't have time to grab the syslog right now, but wanted to see if anyone else has this same problem.

[johnodon]

Since unRAID is running on ESXi and I patch ESXi monthly, unRAID is shutdown at least once a month.

 

Okay - well I think that you will have to get into the habit of rebooting your OpenELEC media players every time you reboot the server.  With the frequency of power cuts here, this has never been a problem for me.

 

So Peter, let me ask you since I know we do things kinda the same way...

 

Since upgrading to RC13, your OpenELEC systems can access your NFS shares without issue (after applying the "fix"?)?

 

I have a vanilla unRAID RC13 running with no changes to my OpenELEC clients and they cannot access my NFS shares.  When I try to watch a movie, OpenELEC tells me that the file is not longer avaialble and if I would like to remove it from the library.  And this is after a fresh boot on OpenELEC which I assume would effectively unmount/remount the share.

 

Wow, you're right - I'd not tried OpenELEC since installing rc13.  The Movies share isn't accessible, nor my xbmc share, which is where all my thumbnails are held.  The pxe boot is working fine, as are the 'storage' directories (direct share from the cache drive) - else my custom settings wouldn't load, and the sql database is working too, but no media files are found (on user shares).

 

I can see all the mount requests in the unRAID syslog:

Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 PXE(eth0) c8:60:00:bd:ea:53 proxy
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 tags: eth0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 bootfile name: pxelinux.0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  1 option: 53:message-type  02
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  4 option: 54:server-identifier  10.2.0.100
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  9 option: 60:vendor-class  50:58:45:43:6c:69:65:6e:74
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 17 option: 97:client-machine-id  00:00:36:8d:33:40:b8:dc:11:a4:06:c8:60...
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 52 option: 43:vendor-encap  06:01:03:08:07:80:00:01:0a:02:00:64:09...
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 PXE(eth0) 10.2.1.23 c8:60:00:bd:ea:53 pxelinux.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 tags: eth0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 bootfile name: pxelinux.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 next server: 10.2.0.100
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  1 option: 53:message-type  05
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  4 option: 54:server-identifier  10.2.0.100
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  9 option: 60:vendor-class  50:58:45:43:6c:69:65:6e:74
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 17 option: 97:client-machine-id  00:00:36:8d:33:40:b8:dc:11:a4:06:c8:60...
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 28 option: 43:vendor-encap  47:04:80:00:00:00:0a:13:00:50:72:65:73...
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: error 0 TFTP Aborted received from 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: failed sending /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: file /mnt/cache/dnsmasq/pxelinux.cfg/00368d33-40b8-dc11-a406-c86000bdea53 not found
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.cfg/01-c8-60-00-bd-ea-53 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/openelec/KERNEL to 10.2.1.23
Jun  5 20:57:20 Tower dnsmasq-dhcp[6720]: 859716585 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:21 Tower dnsmasq-dhcp[6720]: 859716585 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:21 Tower mountd[5504]: authenticated mount request from 10.2.1.23:687 for /mnt/cache/dnsmasq/openelec (/mnt/cache)
Jun  5 20:57:22 Tower mountd[5504]: authenticated mount request from 10.2.1.23:693 for /mnt/cache/dnsmasq/openelec/storage (/mnt/cache)
Jun  5 20:57:22 Tower mountd[5504]: authenticated mount request from 10.2.1.23:697 for /mnt/cache/dnsmasq/openelec/storage/c86000bdea53 (/mnt/cache)
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 client provides name: XBMC_Sala
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 client provides name: XBMC_Sala
Jun  5 20:57:43 Tower mountd[5504]: authenticated mount request from 10.2.1.23:708 for /mnt/user/xbmc (/mnt/user/xbmc)
Jun  5 21:00:38 Tower fan_speed.sh: Highest disk drive temp is: 38C
Jun  5 21:00:38 Tower fan_speed.sh: Changing disk drive fan speed from: [72 (28% @ 847 rpm) ] to: [108 (42% @ 1256 rpm) ]
Jun  5 21:00:47 Tower mountd[5504]: authenticated mount request from 10.2.1.23:724 for /mnt/user/Movies (/mnt/user/Movies)
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Vendor class: dhcpcd 4.0.15
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Vendor class: dhcpcd 4.0.15

The disk shares are accessible to OpenELEC, but the user shares aren't.

 

This is a dead loss ... back to rc10 for me.

 

However, I have to say that I don't believe that any of this is directly related to the stale file handle problem.

 

Whew!  Not that I am glad RC13 broke XBMC for you also Peter...but I am glad that it's not just me. 

 

I see the same...authenticated mount request but the shares are still not accessible.

 

John

[Rich]

I'm getting higher than normal processor activity (jumping to 10-20% every other second) when the server is 'idling' and there seems to be higher than normal writes to my cache drive too... 10.695 after rebooting the server 27 mins ago and increasing by roughly 5 every 2-3 seconds (thats after a reboot and doing nothing else other than auto initialising PLEX, Sab, CP and SickBeard).

 

I know its not a 'stock' test, but its something that defiantly wasn't happening with rc12, so i just wanted to mention it (its not causing me any visible problems).

 

Rich

[nars]

I'm getting higher than normal processor activity (10-20% every other second) when the server is idling and there seems to be higher than normal writes to my cache drive... 10.695 after rebooting the server 27 mins ago and increasing by roughly 5 ever 2-3 seconds (thats after a reboot and doing nothing else other than auto initialising PLEX, Sab, CP and SickBeard).

 

I know its not a 'stock' test, but its something that defiantly wasn't happening with rc12, so i just wanted to mention it (its not causing me any visible problems).

 

Rich

 

only cache drive writes increasing? I wonder if not related to sync issue... but that one seems to increase on all disks...

[Rich]

I'm getting higher than normal processor activity (10-20% every other second) when the server is idling and there seems to be higher than normal writes to my cache drive... 10.695 after rebooting the server 27 mins ago and increasing by roughly 5 ever 2-3 seconds (thats after a reboot and doing nothing else other than auto initialising PLEX, Sab, CP and SickBeard).

 

I know its not a 'stock' test, but its something that defiantly wasn't happening with rc12, so i just wanted to mention it (its not causing me any visible problems).

 

Rich

 

only cache drive writes increasing? I wonder if not related to sync issue... but that one seems to increase on all disks...

[Rich]

... and as a comparison

[Interstellar]

Unfortunately I've got a regression of performance!!! AFP is for some reason, utterly terrible.

 

Tests to the cache drive.

 

Restarted, then run the tests 3 times (as to confirm results from screenshots!) via AFP then 3 times via SMB. Stock install.

 

12a AFP

 

 

12a SMB

 

 

13 AFP

 

 

13 SMB

[limetech]

As a matter of interest, by this morning, the Movies share can be accessed without problems - I guess that something had performed an automatic umount in the meantime.

What's the final status then?  Now working?

Probably the sequence that needs to happen is something like this:

1. un-mount all NFS shares on each client machine

2. create the extra.cfg file with the line shfsExtra="-o noforget"

3. stop/start array for step 2 to take effect

4. re-connect (re-mount) shares on client machines.

 

Now as long as server is not reset, shutdown, or array stop/started, NFS should not get stale file handles.  But if server is reset/shutdown/stopped, then you should also un-mount/re-mount shares on client side as well.  Probably should use 'soft' mount option on clients as well.

 

I am still confused if this addresses the issue I have seen here:  http://lime-technology.com/forum/index.php?topic=27720.msg244928#msg244928

 

If so, I leave my OpenELEC system on 24/7.  Every time I restart unRAID, that means that my OpenELEC machines will no longer be able to reach my media shares unless I unmounts/remount the NFS shares???

 

I hope this is not the case.  I really don't want phone calls from my wife saying that she is unable to put a movie on for my two young boys who are driving here bonkers. 

 

John

 

I think we are going to need to start a separate discussion about NFS...

 

What I'm going to have to do is disable NFS access for user shares (but not disk shares).  In a nutshell the issue is that NFS requires a persistent "handle" associated with every file system object that is unique and doesn't change as long as that object exists, and is never re-used once the object is deleted, and persists across server resets.

 

The 'noforget' option talked about meets these requirements, at cost of incrementally increasing memory footprint, with the exception of "persistence across server resets", which is a killer, unfortunately.

 

PeterB I know you are going to ask, "why does it work with -rc10"?  The answer is, "by accident".  Eventually it won't work, or worse (meaning client tries to read fileA and gets contents of fileB instead).

 

How to workaround?  Use SMB instead of NFS for user share access.  SMB (actually SMB2, soon SMB3) is pretty good these days, so I would ask, why use NFS with OpenELEC?  I use SMB for all media clients, including OpenELEC, without any issues. [Actually for OpenELEC and XBMC you could associate all your disk shares with Movies or TV, etc if you're really keen on NFS.]

 

Can this issue be fixed? Of course all issues can be fixed and all features can be implemented - it's just a matter of time and resources.  For example, look at AFP.  AFP is very similar to NFS at the protocol level.  Instead of "file handles", AFP uses "cnid's", but it's the exact same concept (actually it's even far more restrictive than NFS handles).  How does netatalk solve this?  By using a full-blown database to store cnid-to-filename mappings.  Can I do this with user shares to support NFS?  Sure, but does it make sense for me to put off all other development to implement this feature?  Hard to justify it.

 

There are a couple other possible solutions:

a) use NFSv4 which has concept of "volatile" file handle.  Read about it here:

http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html

 

b) use a user-space NFS server.  There are a few user-space NFS server projects out there, without a lot of traction though.

 

Here's what I ask.  After reading this, go outside and kick something and then let's talk about this in an objective manner.  Probably the solution is to use NFSv4.

[axeman]

Since unRAID is running on ESXi and I patch ESXi monthly, unRAID is shutdown at least once a month.

 

Okay - well I think that you will have to get into the habit of rebooting your OpenELEC media players every time you reboot the server.  With the frequency of power cuts here, this has never been a problem for me.

 

So Peter, let me ask you since I know we do things kinda the same way...

 

Since upgrading to RC13, your OpenELEC systems can access your NFS shares without issue (after applying the "fix"?)?

 

I have a vanilla unRAID RC13 running with no changes to my OpenELEC clients and they cannot access my NFS shares.  When I try to watch a movie, OpenELEC tells me that the file is not longer avaialble and if I would like to remove it from the library.  And this is after a fresh boot on OpenELEC which I assume would effectively unmount/remount the share.

 

Wow, you're right - I'd not tried OpenELEC since installing rc13.  The Movies share isn't accessible, nor my xbmc share, which is where all my thumbnails are held.  The pxe boot is working fine, as are the 'storage' directories (direct share from the cache drive) - else my custom settings wouldn't load, and the sql database is working too, but no media files are found (on user shares).

 

I can see all the mount requests in the unRAID syslog:

Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 PXE(eth0) c8:60:00:bd:ea:53 proxy
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 tags: eth0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 bootfile name: pxelinux.0
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  1 option: 53:message-type  02
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  4 option: 54:server-identifier  10.2.0.100
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  9 option: 60:vendor-class  50:58:45:43:6c:69:65:6e:74
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 17 option: 97:client-machine-id  00:00:36:8d:33:40:b8:dc:11:a4:06:c8:60...
Jun  5 20:57:06 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 52 option: 43:vendor-encap  06:01:03:08:07:80:00:01:0a:02:00:64:09...
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 Vendor class: PXEClient:Arch:00000:UNDI:002001
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 PXE(eth0) 10.2.1.23 c8:60:00:bd:ea:53 pxelinux.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 tags: eth0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 bootfile name: pxelinux.0
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 next server: 10.2.0.100
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  1 option: 53:message-type  05
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  4 option: 54:server-identifier  10.2.0.100
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size:  9 option: 60:vendor-class  50:58:45:43:6c:69:65:6e:74
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 17 option: 97:client-machine-id  00:00:36:8d:33:40:b8:dc:11:a4:06:c8:60...
Jun  5 20:57:10 Tower dnsmasq-dhcp[6720]: 29223507 sent size: 28 option: 43:vendor-encap  47:04:80:00:00:00:0a:13:00:50:72:65:73...
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: error 0 TFTP Aborted received from 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: failed sending /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.0 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: file /mnt/cache/dnsmasq/pxelinux.cfg/00368d33-40b8-dc11-a406-c86000bdea53 not found
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/pxelinux.cfg/01-c8-60-00-bd-ea-53 to 10.2.1.23
Jun  5 20:57:11 Tower dnsmasq-tftp[6720]: sent /mnt/cache/dnsmasq/openelec/KERNEL to 10.2.1.23
Jun  5 20:57:20 Tower dnsmasq-dhcp[6720]: 859716585 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:21 Tower dnsmasq-dhcp[6720]: 859716585 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:21 Tower mountd[5504]: authenticated mount request from 10.2.1.23:687 for /mnt/cache/dnsmasq/openelec (/mnt/cache)
Jun  5 20:57:22 Tower mountd[5504]: authenticated mount request from 10.2.1.23:693 for /mnt/cache/dnsmasq/openelec/storage (/mnt/cache)
Jun  5 20:57:22 Tower mountd[5504]: authenticated mount request from 10.2.1.23:697 for /mnt/cache/dnsmasq/openelec/storage/c86000bdea53 (/mnt/cache)
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 client provides name: XBMC_Sala
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 20:57:25 Tower dnsmasq-dhcp[6720]: 764130360 client provides name: XBMC_Sala
Jun  5 20:57:43 Tower mountd[5504]: authenticated mount request from 10.2.1.23:708 for /mnt/user/xbmc (/mnt/user/xbmc)
Jun  5 21:00:38 Tower fan_speed.sh: Highest disk drive temp is: 38C
Jun  5 21:00:38 Tower fan_speed.sh: Changing disk drive fan speed from: [72 (28% @ 847 rpm) ] to: [108 (42% @ 1256 rpm) ]
Jun  5 21:00:47 Tower mountd[5504]: authenticated mount request from 10.2.1.23:724 for /mnt/user/Movies (/mnt/user/Movies)
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Vendor class: dhcpcd 4.0.15
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Available DHCP subnet: 10.2.0.255/255.255.0.0
Jun  5 21:07:04 Tower dnsmasq-dhcp[6720]: 1581430154 Vendor class: dhcpcd 4.0.15

The disk shares are accessible to OpenELEC, but the user shares aren't.

 

This is a dead loss ... back to rc10 for me.

 

However, I have to say that I don't believe that any of this is directly related to the stale file handle problem.

 

are the VMDKs for your VMs stored on the UnRaid array? Not sure if it's related, but every so often, one of my machines, the disks get non-responsive. Can't say for sure if it's related to the NFS issue or not...

[AndroidCat]

 

I think we are going to need to start a separate discussion about NFS...

 

What I'm going to have to do is disable NFS access for user shares (but not disk shares).  In a nutshell the issue is that NFS requires a persistent "handle" associated with every file system object that is unique and doesn't change as long as that object exists, and is never re-used once the object is deleted, and persists across server resets.

 

The 'noforget' option talked about meets these requirements, at cost of incrementally increasing memory footprint, with the exception of "persistence across server resets", which is a killer, unfortunately.

 

PeterB I know you are going to ask, "why does it work with -rc10"?  The answer is, "by accident".  Eventually it won't work, or worse (meaning client tries to read fileA and gets contents of fileB instead).

 

How to workaround?  Use SMB instead of NFS for user share access.  SMB (actually SMB2, soon SMB3) is pretty good these days, so I would ask, why use NFS with OpenELEC?  I use SMB for all media clients, including OpenELEC, without any issues. [Actually for OpenELEC and XBMC you could associate all your disk shares with Movies or TV, etc if you're really keen on NFS.]

 

Can this issue be fixed? Of course all issues can be fixed and all features can be implemented - it's just a matter of time and resources.  For example, look at AFP.  AFP is very similar to NFS at the protocol level.  Instead of "file handles", AFP uses "cnid's", but it's the exact same concept (actually it's even far more restrictive than NFS handles).  How does netatalk solve this?  By using a full-blown database to store cnid-to-filename mappings.  Can I do this with user shares to support NFS?  Sure, but does it make sense for me to put off all other development to implement this feature?  Hard to justify it.

 

There are a couple other possible solutions:

a) use NFSv4 which has concept of "volatile" file handle.  Read about it here:

http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html

 

b) use a user-space NFS server.  There are a few user-space NFS server projects out there, without a lot of traction though.

 

Here's what I ask.  After reading this, go outside and kick something and then let's talk about this in an objective manner.  Probably the solution is to use NFSv4.

 

How does RC13 and the above remarks relate to the problem reported some time ago, where a few media players/receivers can't see any content within NFS shares?

[WeeboTech]

SMB (actually SMB2, soon SMB3) is pretty good these days, so I would ask, why use NFS with OpenELEC?

 

I would like to answer this question in my context. I use NFS because of strict permissions. users,groups along with automount with a number of unix hosts/vm's.  I mostly use exported disks at the current time. It answers the question, why use NFS rather then SMB. When I explored the use of SMB, it did not take into account the strict permission control I required. I won't go into details of the whys, it's just that the whole world rwx thing is not something I use.

[garycase]

... I know you are going to ask, "why does it work with -rc10"?  The answer is, "by accident".

 

A great quote !!  8)

 

[freekie]

Similar problem as  hawihoney - When issuing  a stop command the array just hangs and the web interface locks up.

 

syslog attached

syslog2 - from telnet as the stop command was issued

screen.jpg - photo from attached monitor

 

I don't believe that I have any plugins on the system.

 

All was fine on 5-0 beta 12a

 

Syslog shows that there was an unclean shutdown previously, with the added issue that the flash drive file system appears to be corrupt.  Take it to another machine where you can run Check Disk on it.  As others have said, it is best to have a clean shut down, before upgrading.

 

The previous unclean shutdown was due to the previous boot of rc13 failing to stop the array as well. That was the reason that I had prepared as full a syslog as I could achieve. The initial rc13 update was after clean shut down from rc12a.

 

I ran the flash drive through a chkdsk, but no errors were found.

 

Anyway after a couple more failed array stops. The problem appears to have sorted itself out,and rc13 stops and shuts down correctly. Maybe my flash drive is on it's way out or something.

 

Anyway thanks for your time looking

[aaronwt]

I got hit with this shutdown issue with rc13 this morning. My unRAID server had been up all night copying content. I usually push the power button on front of the machine to shutdown, but I did it from the browser this morning. It started the process but that was it. I could not access it after that. I had to manually force a shutdown on the machine by holding the power button. When I booted it back up the array was stopped. When I started the array it started a parity check. So I won't be able to mess with it again until the parity check is finished.

 

I am not running any add Ons on this unRAID.

[ixnu]

 

Here's what I ask.  After reading this, go outside and kick something and then let's talk about this in an objective manner.  Probably the solution is to use NFSv4.

 

Timely, content-rich, and includes a workaround  .

 

Update of the year. Thanks!

[Dephcon]

Not that i care about NFS, but what about pNFS?  We've been looking at it on NetApp gear at work and I think the idea is to move to that from NFSv3 and skip v4.

[axeman]

There are a couple other possible solutions:

a) use NFSv4 which has concept of "volatile" file handle.  Read about it here:

http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html

 

b) use a user-space NFS server.  There are a few user-space NFS server projects out there, without a lot of traction though.

 

Here's what I ask.  After reading this, go outside and kick something and then let's talk about this in an objective manner.  Probably the solution is to use NFSv4.

 

I would love an Option C... drop nfs, add iSCSI, natively :-D