October 21, 20169 yr If you are having problems browsing shares using NFS with unRAID OS 6.2.x or 6.3.x please post here. Known players that exhibit this problem (as reported): Mede8er
October 22, 20169 yr I have a Mede8er MED600X3D and was one of those who reported NFS issues going from 6.1.9 to the 6.2 series. Tom provided a version called "6.2.1-nfs-issue-testing" which returned NFS functionality however 6.2.2 broke it again; when accessing folders and subfolders via the Mede8er, they are either empty or missing entirely. I have not tried the 6.3 RC's yet, will give them a try later today or tomorrow and report back. Y
October 22, 20169 yr Author The Mede8er in use is a MED600X3D, f/w version v4.0.2 on unRAID Server, set up a 'Movies' share exported via NFS with "Public" security. Started with unRAID 6.1.9 - browse to NFS network on Mede8r, select Share(IP-address), select movie, both "Browse Disc" and "Play Disc" worked fine. Can browse directories and see all files. Upgraded to 6.2.1 - same thing, everything works fine. One thing I did notice odd with the Mede8r is that at one time there was another server on network with NFS exports that I connected to. That sever is long gone off the network, but it's IP address still shows up in the list of shares under NFS. Selecting it of course results in 'Failed' on the Mede8r. Somewhere, then the Mede8r is caching at least this information. The only difference in the "6.2.1-nfs-issue-testing" release is a certain option not being passed to FUSE when shfs is mounted (use_ino). What this option does is affect the contents of the "st_inode" field of a 'stat' structure on a file or directory. This should not have any effect on NFS, but it's possible that a NFS client could 'cache' this value and use it to determine if a subsequent reference to the file is "stale". For example: - client opens 'movies' directory on server, server returns a file handle - client stats the file handle, caches it's st_inode value somewhere. later... - client stats the file handle again, but this time since unRAID release updated the st_inode value is different - client doesn't know how to cope with this so it doesn't do anything If above scenario is happening it should solve the issue either by "hard resetting" the Mede8er, or by changing the IP address of the server (so Mede8er is thinking he's talking to a completely different server). Neither of these actions seem to solve the issue for the users I have communicated with via email. That's where it stands. If I can't reproduce it, I can't fix it.
October 22, 20169 yr Just tested here with 6.2.2 and 6.3 rc2 with a freshly installed 4.0.2 firmware on the Mede8er MED600X3D and folders are still blank. Edit: Don't know if this helps, but here is the mount options used on the mede8er: rw, relatime, vers=3, rsize=32768, wsize=32768, namelen=255, hard, nolock, proto=udp, port=65535, timeo=7, retrans=3, sec=sys, mountport=65535, mountproto=, addr=192.168.1.4 Mountproto= is empty, so no typo. If you want to check this yourselves, go into the NFS share and push the F1 button, and a line should appear on top of the screen.
October 22, 20169 yr Author Just tested here with 6.2.2 and 6.3 rc2 with a freshly installed 4.0.2 firmware on the Mede8er MED600X3D and folders are still blank. Edit: Don't know if this helps, but here is the mount options used on the mede8er: rw, relatime, vers=3, rsize=32768, wsize=32768, namelen=255, hard, nolock, proto=udp, port=65535, timeo=7, retrans=3, sec=sys, mountport=65535, mountproto=, addr=192.168.1.4 Mountproto= is empty, so no typo. If you want to check this yourselves, go into the NFS share and push the F1 button, and a line should appear on top of the screen. When I do that, the line reads: rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=256,hard,nolock,proX5?[b](funny chars)[/b] Yes that bit at the end is right: by (funny chars) I mean it looks like a couple Chinese characters. Nothing more on the line beyond that.
October 22, 20169 yr Author The 'factory reset' doesn't really fully reset. For example under NFS it still shows the old server IP address which is no longer on the network. Also the funny chars that appear in hitting F1 are still there. I can't make this damn thing fail, which is interesting, right?
October 22, 20169 yr Just tested here with 6.2.2 and 6.3 rc2 with a freshly installed 4.0.2 firmware on the Mede8er MED600X3D and folders are still blank. Edit: Don't know if this helps, but here is the mount options used on the mede8er: rw, relatime, vers=3, rsize=32768, wsize=32768, namelen=255, hard, nolock, proto=udp, port=65535, timeo=7, retrans=3, sec=sys, mountport=65535, mountproto=, addr=192.168.1.4 Mountproto= is empty, so no typo. If you want to check this yourselves, go into the NFS share and push the F1 button, and a line should appear on top of the screen. When I do that, the line reads: rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=256,hard,nolock,proX5?[b](funny chars)[/b] Yes that bit at the end is right: by (funny chars) I mean it looks like a couple Chinese characters. Nothing more on the line beyond that. Interesting. I wonder why we don't have the same mount options running the same device and firmware. Did you use the V4.0.2_6April2016 or V4.0.2_7Nov2015 firmware? Did you reboot it after resetting? It states in the manual that it rescans NFS on reboot. I saw the the same behaviour with caching old shares when I first started the mede8er today. It still had a shar I tested a long time ago. If you press the menu button, you can delete the shares. Not sure if that deletes it completely though.
October 22, 20169 yr Author Just tested here with 6.2.2 and 6.3 rc2 with a freshly installed 4.0.2 firmware on the Mede8er MED600X3D and folders are still blank. Edit: Don't know if this helps, but here is the mount options used on the mede8er: rw, relatime, vers=3, rsize=32768, wsize=32768, namelen=255, hard, nolock, proto=udp, port=65535, timeo=7, retrans=3, sec=sys, mountport=65535, mountproto=, addr=192.168.1.4 Mountproto= is empty, so no typo. If you want to check this yourselves, go into the NFS share and push the F1 button, and a line should appear on top of the screen. When I do that, the line reads: rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=256,hard,nolock,proX5?[b](funny chars)[/b] Yes that bit at the end is right: by (funny chars) I mean it looks like a couple Chinese characters. Nothing more on the line beyond that. Interesting. I wonder why we don't have the same mount options running the same device and firmware. Did you use the V4.0.2_6April2016 or V4.0.2_7Nov2015 firmware? Did you reboot it after resetting? It states in the manual that it rescans NFS on reboot. I saw the the same behaviour with caching old shares when I first started the mede8er today. It still had a shar I tested a long time ago. If you press the menu button, you can delete the shares. Not sure if that deletes it completely though. Probably they are the same mount options, there's just something clobbered in the string. It's the April f/w. By reboot you mean, yank power, power up, turn it on? Yes Pressing Menu I was able to clear the old server IP, so what I did was clear both server IP's. Rebooted and navigated to NFS and it did re-probe, and it did work correctly. BTW all this did not fix the mount option string - still shows up corrupted. This has to be a first: normally I'm always trying to help people get things working, here I am trying to make something break
October 22, 20169 yr Just tested here with 6.2.2 and 6.3 rc2 with a freshly installed 4.0.2 firmware on the Mede8er MED600X3D and folders are still blank. Edit: Don't know if this helps, but here is the mount options used on the mede8er: rw, relatime, vers=3, rsize=32768, wsize=32768, namelen=255, hard, nolock, proto=udp, port=65535, timeo=7, retrans=3, sec=sys, mountport=65535, mountproto=, addr=192.168.1.4 Mountproto= is empty, so no typo. If you want to check this yourselves, go into the NFS share and push the F1 button, and a line should appear on top of the screen. When I do that, the line reads: rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=256,hard,nolock,proX5?[b](funny chars)[/b] Yes that bit at the end is right: by (funny chars) I mean it looks like a couple Chinese characters. Nothing more on the line beyond that. Interesting. I wonder why we don't have the same mount options running the same device and firmware. Did you use the V4.0.2_6April2016 or V4.0.2_7Nov2015 firmware? Did you reboot it after resetting? It states in the manual that it rescans NFS on reboot. I saw the the same behaviour with caching old shares when I first started the mede8er today. It still had a shar I tested a long time ago. If you press the menu button, you can delete the shares. Not sure if that deletes it completely though. Probably they are the same mount options, there's just something clobbered in the string. It's the April f/w. By reboot you mean, yank power, power up, turn it on? Yes Pressing Menu I was able to clear the old server IP, so what I did was clear both server IP's. Rebooted and navigated to NFS and it did re-probe, and it did work correctly. BTW all this did not fix the mount option string - still shows up corrupted. This has to be a first: normally I'm always trying to help people get things working, here I am trying to make something break Sometimes it's good to try to break stuff I meant power off, power on with reboot. But not sure what they mean with reboot in the manual. You are still testing on 6.2.1?
October 22, 20169 yr I'm pretty adept at breaking/deleting stuff generally... Tom should invite you over
October 22, 20169 yr You are still testing on 6.2.1? 6.2.2 now, but doesn't matter. Tom, any chance you can whip up a 6.2.2 release with the nfs testing changes? So we can have the security fixes?
October 23, 20169 yr Author You are still testing on 6.2.1? 6.2.2 now, but doesn't matter. Tom, any chance you can whip up a 6.2.2 release with the nfs testing changes? So we can have the security fixes? What client are you seeing this issue with?
October 23, 20169 yr You are still testing on 6.2.1? 6.2.2 now, but doesn't matter. Tom, any chance you can whip up a 6.2.2 release with the nfs testing changes? So we can have the security fixes? What client are you seeing this issue with? this is dave, we have been emailing, i am the one that sent you the mede8er for testing
October 23, 20169 yr unRaid server 6.2.1. NFS share settings: *(ro,insecure) OPPO BDP-103: Only sees 1 out of 2 top level folders over NFS. Doesn't see any folders under at all. Popcorn Hour A-500: No issues, works.
October 23, 20169 yr Author Eureka! Finally figured this out. Fundamentally it is a bug with the Mede8er NFS client. NFSv3 permits 64-bit fileid's but if the Mede8er NFS client sees a fileid where any of the upper 32 bits are set, it will refuse to process that object. In linux, a file or directory inode number is mapped directly to NFS fileid. In the current file systems used by unRAID (reiserfs, xfs, btrfs), these inode numbers are less than 32 bits in size. (But it is possible, if the file system is large enough, or the storage device is large enough, inode numbers, especially for xfs, due to how xfs generates inode numbers, that some day an inode number can get larger than 32 bits.) So why did 6.2 break this? It's because of how hard link support was implemented in user share file system. The inode number field of a file/directory accessed via user share is encoded with additional information that could cause the inode number to exceed 32 bits. This is dependent on the underlying file system. For example, in my testing all my files exported via NFS were on ReiserFS volumes, which won't typically cause user share inode number to exceed 32 bits, thus I did not see this issue. Probably btrfs would be ok too but I didn't test it. But because of how xfs defined the inode numbers, combined with the extra encoding added by user share file system, the inode numbers do exceed 32 bits and I was able to reproduce the problem. A fix for unRAID will come in the next 6.3.0-rc release. As mentioned earlier though, this is a bug in Mede8er. For those who care about this player, I suggest you try and contact the developers there and let them know about this problem. Tell them to feel free to contact us with details if necessary. I want to especially thank user spl147 for his generous lending of a Mede8er for us to test with and for his patience with helping debug this issue. P.S. afaik Mede8er is itself based on an older 2.6 linux kernel and probably uses older NFS client code. If you google "NFS 64-bit fileid problem" you will come across other references to this. In particular: https://bugzilla.redhat.com/show_bug.cgi?id=241348 There are probably other players that have this same issue. tldr: found the problem, fix will come in next 6.3-rc release.
October 23, 20169 yr I have tested again here with a disk share and that works. A normal share is still a no go. Now I also moved to China I tested booting into safe mode, just to be sure no plugins affected NFS. I assume you tested it with a user share, and not a disk share, Tom? I got a reply from mede8er regarding logging and what the problem could be. We don’t have any experience with the unRAID NAS software and the only time that NFS gives the symptoms you describe is when you set the NFS mount to the actual folder. So in summery you always need a sub folder under the NFS mount folder. Example Share1 ---- Movies ---- Hard Target 2 (2016) ---- The Sea of Trees (2015) Etc So in above example ‘Share1’ will be the export or mount point and you should see the sub folder ‘Movies’ and be able to Browse it or make a Favourite Link from it. Sorry but Mede8er does not store any log files.
October 23, 20169 yr Eureka! Finally figured this out. Fundamentally it is a bug with the Mede8er NFS client. NFSv3 permits 64-bit fileid's but if the Mede8er NFS client sees a fileid where any of the upper 32 bits are set, it will refuse to process that object. In linux, a file or directory inode number is mapped directly to NFS fileid. In the current file systems used by unRAID (reiserfs, xfs, btrfs), these inode numbers are less than 32 bits in size. (But it is possible, if the file system is large enough, or the storage device is large enough, inode numbers, especially for xfs, due to how xfs generates inode numbers, that some day an inode number can get larger than 32 bits.) So why did 6.2 break this? It's because of how hard link support was implemented in user share file system. The inode number field of a file/directory accessed via user share is encoded with additional information that could cause the inode number to exceed 32 bits. This is dependent on the underlying file system. For example, in my testing all my files exported via NFS were on ReiserFS volumes, which won't typically cause user share inode number to exceed 32 bits, thus I did not see this issue. Probably btrfs would be ok too but I didn't test it. But because of how xfs defined the inode numbers, combined with the extra encoding added by user share file system, the inode numbers do exceed 32 bits and I was able to reproduce the problem. A fix for unRAID will come in the next 6.3.0-rc release. As mentioned earlier though, this is a bug in Mede8er. For those who care about this player, I suggest you try and contact the developers there and let them know about this problem. Tell them to feel free to contact us with details if necessary. I want to especially thank user spl147 for his generous lending of a Mede8er for us to test with and for his patience with helping debug this issue. P.S. afaik Mede8er is itself based on an older 2.6 linux kernel and probably uses older NFS client code. If you google "NFS 64-bit fileid problem" you will come across other references to this. In particular: https://bugzilla.redhat.com/show_bug.cgi?id=241348 There are probably other players that have this same issue. tldr: found the problem, fix will come in next 6.3-rc release. That is a great job Tom! I'll forward your reply here to them since I have them on the line.
October 23, 20169 yr Tom/limetech, first, a very big thank you for spending the time to figure this one out. Even if there was no resolution, I'm just grateful for the time you put into it; there's probably only a small group of us using Mede8ers or similar devices but you put the effort into it, speaks volumes about you and Lime Tech. Kudos! Secondly, looking forward to what Saarg will report from Mede8er but I'm not optimistic they'll be able to do much. Per Mede8er forum thread, started by spl147 himself, the mod states: "NFS is a realtek library in their SDK. The 1186 SDK has not changed in three years. Realtek have moved on to newer chips. Mede8er have been squeezing what they can out of that SDK since they started the X3D. They can't change it." Looking forward to trying out the new RC. Thanks, Y
October 23, 20169 yr Eureka! Finally figured this out. Fundamentally it is a bug with the Mede8er NFS client. NFSv3 permits 64-bit fileid's but if the Mede8er NFS client sees a fileid where any of the upper 32 bits are set, it will refuse to process that object. In linux, a file or directory inode number is mapped directly to NFS fileid. In the current file systems used by unRAID (reiserfs, xfs, btrfs), these inode numbers are less than 32 bits in size. (But it is possible, if the file system is large enough, or the storage device is large enough, inode numbers, especially for xfs, due to how xfs generates inode numbers, that some day an inode number can get larger than 32 bits.) So why did 6.2 break this? It's because of how hard link support was implemented in user share file system. The inode number field of a file/directory accessed via user share is encoded with additional information that could cause the inode number to exceed 32 bits. This is dependent on the underlying file system. For example, in my testing all my files exported via NFS were on ReiserFS volumes, which won't typically cause user share inode number to exceed 32 bits, thus I did not see this issue. Probably btrfs would be ok too but I didn't test it. But because of how xfs defined the inode numbers, combined with the extra encoding added by user share file system, the inode numbers do exceed 32 bits and I was able to reproduce the problem. A fix for unRAID will come in the next 6.3.0-rc release. As mentioned earlier though, this is a bug in Mede8er. For those who care about this player, I suggest you try and contact the developers there and let them know about this problem. Tell them to feel free to contact us with details if necessary. I want to especially thank user spl147 for his generous lending of a Mede8er for us to test with and for his patience with helping debug this issue. P.S. afaik Mede8er is itself based on an older 2.6 linux kernel and probably uses older NFS client code. If you google "NFS 64-bit fileid problem" you will come across other references to this. In particular: https://bugzilla.redhat.com/show_bug.cgi?id=241348 There are probably other players that have this same issue. tldr: found the problem, fix will come in next 6.3-rc release. Thats fantastic tom! So glad i was able to help out... i spoke with the mede8er team when this first started, they pretty much said the SDK from realtek has been abandoned and is very old, so it is where it is. They said they can only update what is updated in the SDK. Im trying to get ahold of the new dune hd solo lite to see if it works (not available in the US yet) Looking through the SDK for the realtek chip they use most packages are very old
October 24, 20169 yr ... Im trying to get ahold of the new dune hd solo lite to see if it works (not available in the US yet) I bought a Dune Solo Lite couple weeks ago and can confirm NFS is working.
October 24, 20169 yr ... Im trying to get ahold of the new dune hd solo lite to see if it works (not available in the US yet) I bought a Dune Solo Lite couple weeks ago and can confirm NFS is working. Are you in the US?
October 24, 20169 yr ... Im trying to get ahold of the new dune hd solo lite to see if it works (not available in the US yet) I bought a Dune Solo Lite couple weeks ago and can confirm NFS is working. Are you in the US? Netherlands
Archived
This topic is now archived and is closed to further replies.