I have 6 disks set up an my array, as well as 4 shares. I don't have any user permissions set up. The array boots and runs without any problems for a while. Eventually someone will go to play a movie and it will fail. The shares are still visible, but the directory structures within them have all disapeared. The web interface page doesn't show any problems when it is refreshed, however, when I got to stop the array disks 2, 3, 4 and 5 all show as 'unformatted' I need to reboot the array in order to have it all working again. If a movie is already playing when it fails, the movie will continue to play without a problem. I have a very flat directory structure, which has share name at the top level (Movies), followed by directories for each movie, which in turn have the video_ts directory in them. I haven't managed to pick up this issue on any logs yet, and would be grateful of any suggestions as to the est way to do it.

This is 4.3-beta1 release?

Yes. Sorry, should have mentioned that. I did have this problem with 4.2 as well.

Just an update... I had the problem again, but this time I started the persistent log before stopping the array. The space in the log is the point where I hit 'stop' for the seond time

 

Tower login: root

Linux 2.6.24.3-unRAID.

root@Tower:~# tail -f /var/log/syslog

Mar 17 08:43:38 Tower kernel: [ 2439.239454] ReiserFS: md4: Using r5 hash to sor                                      t names

Mar 17 08:43:38 Tower kernel: [ 2439.239498] ReiserFS: md5: Using r5 hash to sor                                      t names

Mar 17 08:43:38 Tower kernel: [ 2439.390378] can't shrink filesystem on-line

Mar 17 08:43:38 Tower kernel: [ 2439.390673] can't shrink filesystem on-line

Mar 17 08:43:38 Tower kernel: [ 2439.400527] can't shrink filesystem on-line

Mar 17 08:43:38 Tower kernel: [ 2439.418407] can't shrink filesystem on-line

Mar 17 08:43:38 Tower kernel: [ 2439.420535] can't shrink filesystem on-line

Mar 17 08:43:38 Tower emhttp[2072]: shcmd (26): mkdir -m 700 /mnt/user

Mar 17 08:43:38 Tower emhttp[2072]: shcmd (27): /usr/local/sbin/shfs /mnt/user 0

Mar 17 08:43:39 Tower emhttp[2072]: shcmd (28): killall -HUP smbd

Mar 17 10:48:00 Tower emhttp[2072]: shcmd (29): killall -w smbd nmbd

Mar 17 10:48:01 Tower emhttp[2072]: shcmd (30): sync

Mar 17 10:48:09 Tower emhttp[2072]: shcmd (31): umount /mnt/user

Mar 17 10:48:09 Tower emhttp[2072]: shcmd (32): rmdir /mnt/user

Mar 17 10:48:09 Tower emhttp[9832]: shcmd (33): umount /mnt/disk1

Mar 17 10:48:09 Tower emhttp[9834]: shcmd (33): umount /mnt/disk2

Mar 17 10:48:09 Tower emhttp[9836]: shcmd (33): umount /mnt/disk3

Mar 17 10:48:09 Tower emhttp[9838]: shcmd (33): umount /mnt/disk4

Mar 17 10:48:09 Tower emhttp[9840]: shcmd (33): umount /mnt/disk5

Mar 17 10:48:09 Tower emhttp[9840]: shcmd (33): exit status: 1

Mar 17 10:48:09 Tower emhttp[9840]: shcmd (34): rmdir /mnt/disk5

Mar 17 10:48:09 Tower emhttp[9840]: shcmd (34): exit status: 1

Mar 17 10:48:10 Tower emhttp[9832]: shcmd (34): rmdir /mnt/disk1

Mar 17 10:48:10 Tower emhttp[9838]: shcmd (34): rmdir /mnt/disk4

Mar 17 10:48:10 Tower emhttp[9836]: shcmd (34): rmdir /mnt/disk3

Mar 17 10:48:10 Tower emhttp[9834]: shcmd (34): rmdir /mnt/disk2

Mar 17 10:48:10 Tower emhttp[2072]: driver cmd: stop

Mar 17 10:48:10 Tower kernel: [ 9899.442778] mdcmd (27): stop

Mar 17 10:48:10 Tower kernel: [ 9899.442783] md: 2 devices still in use.

Mar 17 10:48:10 Tower emhttp[2072]: list_user_shares: scandir: No such file or directory

Mar 17 10:48:10 Tower emhttp[2072]: shcmd (33): /usr/sbin/nmbd -D

Mar 17 10:48:10 Tower emhttp[2072]: shcmd (34): /usr/sbin/smbd -D

 

 

Mar 17 10:48:42 Tower emhttp[2072]: shcmd (35): killall -w smbd nmbd

Mar 17 10:48:44 Tower emhttp[2072]: shcmd (36): sync

Mar 17 10:48:46 Tower emhttp[2072]: shcmd (37): umount /mnt/user

Mar 17 10:48:46 Tower emhttp[2072]: shcmd (37): exit status: 1

Mar 17 10:48:46 Tower emhttp[2072]: shcmd (38): rmdir /mnt/user

Mar 17 10:48:46 Tower emhttp[2072]: shcmd (38): exit status: 1

Mar 17 10:48:46 Tower emhttp[9869]: shcmd (39): umount /mnt/disk5

Mar 17 10:48:46 Tower emhttp[9869]: shcmd (40): rmdir /mnt/disk5

Mar 17 10:48:46 Tower emhttp[2072]: driver cmd: stop

Mar 17 10:48:46 Tower kernel: [ 9935.899887] mdcmd (30): stop

Mar 17 10:48:46 Tower kernel: [ 9935.899893] md0: stopping

Mar 17 10:48:46 Tower kernel: [ 9935.899895] md1: stopping

Mar 17 10:48:46 Tower kernel: [ 9935.899947] md2: stopping

Mar 17 10:48:46 Tower kernel: [ 9935.899960] md3: stopping

Mar 17 10:48:46 Tower kernel: [ 9935.899971] md4: stopping

Mar 17 10:48:46 Tower kernel: [ 9935.899982] md5: stopping

Mar 17 10:48:46 Tower emhttp[2072]: shcmd (39): /usr/sbin/nmbd -D

Mar 17 10:48:46 Tower emhttp[2072]: shcmd (40): /usr/sbin/smbd -D

 

 

Do you have anything extra in your 'go' script?

After you have booted the server, are you doing anything via a telnet session or via the console?

 

Please try to start the "persistent log" before the problem happens.

If by the persistent log you mean this: "tail -f /var/log/syslog" the the log above was started before the problem. Having had a look at the 'go' script, the only extra thing is the "30% Read Perfomance Improvement Tweak" from the User Customizations forum. I put it in when I was having a whole bunch of performance issues (now fixed), and obviously fogot all about it. I have now removed that addition and will see what happens.

I experienced the exact same problem as Robertxc last night.  When updating cover art for approximately 30 mp3's failed, I was already viewing the directory in question via the user share but after moving up one level everything disappeared.  Browsing the directory from the data disk and then going back to the share seemed to restore the directory contents but they would disappear again in short order.

 

I am running 4.3-beta1 (updating to beta2 now) and my configuration appears to be identical to Robertxc's.  "very flat directory structure, which has share name at the top level (Movies), followed by directories for each movie, which in turn have the video_ts directory in them."  Music is similar with artist/album sub folders.  like Robertxc the only customization I have made to my go script is the "30% Read Performance Improvement Tweak". 

 

After trying to figure out what was going on I decided to stop the array and bounce the server at which time I noticed that I had a disc showing as unformatted.  I proceeded to stop and start the array and everything has been ok since then.  I happened to have a monitor plugged into my server and noticed the following output after all was said and done:

 

umount: /mnt/disk1: device is busy

umount: /mnt/disk1: device is busy

rmdir: /mnt/disk1: Device or resource is busy

umount: /mnt/user: not found

rmdir: /mnt/user: No such file or directory

 

Just wanted to say this does not appear to be an isolated incident.

 

I have seen the issue under 4.3-beta 1 as well. It clears up as soon as I stop/start the array. I am upgrading to beta 2 and I'll see if I can get a log when it happens again.

 

The only customization I have to the go script (or anything else) is  the "30% Read Performance Improvement Tweak".