marcusone Posted March 12, 2012 Share Posted March 12, 2012 BUG: not sure if this has been reported, but i'm not searching through 100's of posts. When creating a new folder/file on a user share that is marked for Public access, the files are created as the user I am connected as (not the 'nobody' global/public user). So that folder/file is not really Public. A big pain to log into the console to chown it. Quote Link to comment
Zeron Posted March 12, 2012 Share Posted March 12, 2012 BUG: not sure if this has been reported, but i'm not searching through 100's of posts. When creating a new folder/file on a user share that is marked for Public access, the files are created as the user I am connected as (not the 'nobody' global/public user). So that folder/file is not really Public. A big pain to log into the console to chown it. I have seen the same when I mount the share when logged in a root on another system. Having force user force group force create mode and force directory mode set in the samba configuration for public shares would avoid this issue. Quote Link to comment
1gr8ftoy Posted March 13, 2012 Share Posted March 13, 2012 I had the same problem on Samba Quote Link to comment
Dimtar Posted March 14, 2012 Share Posted March 14, 2012 BUG: not sure if this has been reported, but i'm not searching through 100's of posts. When creating a new folder/file on a user share that is marked for Public access, the files are created as the user I am connected as (not the 'nobody' global/public user). So that folder/file is not really Public. A big pain to log into the console to chown it. I have seen the same when I mount the share when logged in a root on another system. Having force user force group force create mode and force directory mode set in the samba configuration for public shares would avoid this issue. Since this probably explains the issues I am having right now would you mind expanding on that please? Quote Link to comment
mejutty Posted March 16, 2012 Share Posted March 16, 2012 Looking for some help. I have a HP Microserver with 6 3Tb hds and up until i got to just over 50% used capacity I was able to transfer large files no problems by large I mean 40Gb iso files. What happens is when I start the transfer windows just times out with "the network share is no longer available" what I see in unraid via the uumenu in open files is the file I am trying to transfer being allocated it's storage and counting up in it's file size but the before the file reaches the size it needs to be windows times out and there has been no actual file transfer take place. Hope that makes sence. Any help is greatly appreciated. Quote Link to comment
Ostrich Posted March 20, 2012 Share Posted March 20, 2012 mejutty, I experienced the same issue, usually once the drives start to fill up. I posted same issue on other forum, which someone posted some recommendations on how to potentially fix, see posts here: http://lime-technology.com/forum/index.php?topic=4500.msg85277#msg85277 Maybe they will work for you? Didnt for me, but given its only really every now and then, and doesnt appear to create a hole in my parity i keep going as normal. It usually only occurs the first time i write to that particular drive as well ie if i have shares spanning multiple drives, first write to one drive may fail then work, then next write to another drive will fail then work. Once it fails once, every subsequent write to that drive works fine. If you figure out a solution i would be keen to hear. Quote Link to comment
madburg Posted March 20, 2012 Share Posted March 20, 2012 This is all great, we're are we in movement with unRAID 5? Quote Link to comment
thica Posted March 22, 2012 Share Posted March 22, 2012 Unraid 5 Beta 2 is from August 10, 2010, 09:32:21 That is the longest beta for a commercial product I have ever seen..... Quote Link to comment
Auggie Posted March 22, 2012 Share Posted March 22, 2012 Unraid 5 Beta 2 is from August 10, 2010, 09:32:21 That is the longest beta for a commercial product I have ever seen..... Uh, Duke Nukem Forever? Or was that just the longest development ever... Quote Link to comment
BRiT Posted March 22, 2012 Share Posted March 22, 2012 Unraid 5 Beta 2 is from August 10, 2010, 09:32:21 That is the longest beta for a commercial product I have ever seen..... You haven't been around much then. Quote Link to comment
Ice_Black Posted March 22, 2012 Share Posted March 22, 2012 Tom: Please give us an update! Quote Link to comment
cj0r Posted March 22, 2012 Share Posted March 22, 2012 Do you know what I do when the child keeps asking me if we're there yet? I ignore them because we get there when we get there. There's been plenty of requests for an update, I'm sure he will give one when he's ready. I've been running beta 12a without issue for the past 6 months. If beta 14 is no good for you, experiment with the others to find one that is. Quote Link to comment
subwars Posted March 23, 2012 Share Posted March 23, 2012 Unraid 5 Beta 2 is from August 10, 2010, 09:32:21 That is the longest beta for a commercial product I have ever seen..... You haven't been around much then. i donno how long that took... but how about diablo 3. Quote Link to comment
WeeboTech Posted March 23, 2012 Share Posted March 23, 2012 Folks, I'm not fond of doing this, but let me take a moment to remind everyone this is a topic for 5.0-beta14 subject matter. I mention this so that bugs on the beta can be monitored and discussed without wading through other conversations. While I get a kick out of some conversations, some of it is more a subject for the lounge. Feel free to discuss it there. Quote Link to comment
Garani Posted March 30, 2012 Share Posted March 30, 2012 I am just the new kid here, having just started on unraid. Still I am experiencing the nfs stale file handler issue. Running b14 at the moment. Other then that I haven't seen other issues. Quote Link to comment
peter_sm Posted March 31, 2012 Share Posted March 31, 2012 I'm running a updated version with kernel 3.2.9 and samba 3.6.3 feel free to test -> http://www.filefactory.com/file/c35c621/n/bzroot_3.2.9-samba3.6.3.rar I.m running beta 14 with kernel 3.3, if anyone want to try this, feel free -> http://www.filefactory.com/file/2qlr5qxok92v/n/bzimage_rar Including samba 3.6.3- //Peter Quote Link to comment
Frank1940 Posted March 31, 2012 Share Posted March 31, 2012 I'm running a updated version with kernel 3.2.9 and samba 3.6.3 feel free to test -> http://www.filefactory.com/file/c35c621/n/bzroot_3.2.9-samba3.6.3.rar I.m running beta 14 with kernel 3.3, if anyone want to try this, feel free -> http://www.filefactory.com/file/2qlr5qxok92v/n/bzimage_rar Including samba 3.6.3- //Peter Thanks, Peter. I have upgrade my test bed server to use the new kernel. I have read both Blu-ray and standard DVD iso's using both Samba and NFS with my Netgear NTV-550. I have also copied files to it using Samba from Win7. Everything is working as it should. However, I must point out that I had no problems with the earlier kernels on this very old hardware. Quote Link to comment
BRiT Posted March 31, 2012 Share Posted March 31, 2012 I'm waiting for someone with a LSI Controller and a dev/test array to give it a try before moving on from Beta 12. I'm rather enjoying my stable system now with an uptime of 144 days. Quote Link to comment
Ambrotos Posted March 31, 2012 Share Posted March 31, 2012 I'm waiting for someone with a LSI Controller and a dev/test array to give it a try before moving on from Beta 12. I'm rather enjoying my stable system now with an uptime of 144 days. I'm running beta14 on a LSI 9690SA with 5 drives. It's not dev/test because I wasn't aware of any issues with LSI controllers until I started reading this thread. All of my drives are configured to spin down, and I've never seen a single error on any of them. I realize this isn't what most people are reporting. I'm not sure what the difference could be. Anyway, there you go: someone who's successfully run beta14 on an LSI controller -A Quote Link to comment
peter_sm Posted March 31, 2012 Share Posted March 31, 2012 According the new kernel, there are still the same issues for NFS. Quote Link to comment
Garani Posted March 31, 2012 Share Posted March 31, 2012 According the new kernel, there are still the same issues for NFS. Unluckily I can confirm that, after upgrading to kernel 3.3.0 posted by you, I still get the "Stale NFS file handle" on clients. Quote Link to comment
BRiT Posted March 31, 2012 Share Posted March 31, 2012 I'm running beta14 on a LSI 9690SA with 5 drives. It's not dev/test because I wasn't aware of any issues with LSI controllers until I started reading this thread. All of my drives are configured to spin down, and I've never seen a single error on any of them. I realize this isn't what most people are reporting. I'm not sure what the difference could be. Anyway, there you go: someone who's successfully run beta14 on an LSI controller Would you mind doing a series of spin-down and spin-up drive cycles? Everyone else who has run beta13 and beta14 on LSI hardware gets false RED-Balled drives and thousands of read issues. Quote Link to comment
Ambrotos Posted March 31, 2012 Share Posted March 31, 2012 Would you mind doing a series of spin-down and spin-up drive cycles? Everyone else who has run beta13 and beta14 on LSI hardware gets false RED-Balled drives and thousands of read issues. I did 5 spin down/up cycles each at 1 minute intervals. Still don't see any errors. -A Quote Link to comment
BRiT Posted March 31, 2012 Share Posted March 31, 2012 Whats the specs of the rest of your system (cpu/ram/motherboard) ? Quote Link to comment
JM2005 Posted April 1, 2012 Share Posted April 1, 2012 I'm waiting for someone with a LSI Controller and a dev/test array to give it a try before moving on from Beta 12. I'm rather enjoying my stable system now with an uptime of 144 days. I too would like to see if it works with LSI Controllers. Quote Link to comment
Recommended Posts
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.