OH!

Since you have Dynamix installed, look on the tab:  UTILS / "DEVELOPMENT UTILITIES" and click on 'System Log'.

Copy and paste that out...It *should* be different from what you've been posting.

OH!

Since you have Dynamix installed, look on the tab:  UTILS / "DEVELOPMENT UTILITIES" and click on 'System Log'.

Copy and paste that out...It *should* be different from what you've been posting.

 

I get:

 

cat: /var/log/syslog: No such file or directory

 

Was hopeful there for a while 

 

The file isn't there since unRAID hasn't created a new one after I deleted it, as described in previous posts.

 

Also, "cat: /var/log/syslog" is the same exact command I used to view the syslog previously, so I can't see how it would show any different syslog than I shared above.

The file isn't there since unRAID hasn't created a new one after I deleted it, as described in previous posts.

And won't be, since unraid hasn't been rebooted. It won't recreate the info we need until you shutdown, and restart the system.

What you need to do is restart, then copy data until you get the error. Then you need to extract the syslog, zip it up, and post it here.

The file isn't there since unRAID hasn't created a new one after I deleted it, as described in previous posts.

And won't be, since unraid hasn't been rebooted. It won't recreate the info we need until you shutdown, and restart the system.

What you need to do is restart, then copy data until you get the error. Then you need to extract the syslog, zip it up, and post it here.

 

Ok, now it worked, after boot there are 500+ lines! Lot of repeated warnings below.

 

Jan 23 18:25:41 TheMonolith logger: 
Jan 23 18:25:41 TheMonolith logger: Warning: simplexml_load_file():                                                                                ^ in /usr/local/sbin/installplg on line 13
Jan 23 18:25:41 TheMonolith logger: 
Jan 23 18:25:41 TheMonolith logger: Warning: simplexml_load_file(): /boot/config/plugins/transmission_unplugged.plg:1213: parser error : Entity 'nbsp' not defined in /usr/local/sbin/installplg on line 13

 

I'm currently copying stuff to disk3 again to determine if the issue re-occurs.

 

In the meanwhile, full file attached.

 

syslog.zip

The log has 30,000 lines of this repeating error:

Warning: simplexml_load_file(): /boot/config/plugins/transmission_unplugged.plg

You should remove that Transmission plugin.  Check the forums to see if there's an update and/or if it works with unRAID 5.0.4

 

Lines 185-200 appear to be setting up RAID 6.

I don't know how that works with unRAID.

I defer to the smart folks here on the forums.

 

Going back to your original question: "...the write operation stops part way through..."

When the 'write' stops post the entire log again.

 

Clear the browser cache.

The log has 30,000 lines of this repeating error:

Warning: simplexml_load_file(): /boot/config/plugins/transmission_unplugged.plg

You should remove that Transmission plugin.  Check the forums to see if there's an update and/or if it works with unRAID 5.0.4

 

Ok, I'll try to figure out how to un-install the plugin.

 

Lines 185-200 appear to be setting up RAID 6.

I don't know how that works with unRAID.

I defer to the smart folks here on the forums.

 

I've never set up RAID 6, or any other RAID system besides unRAID. Perhaps that is related to the AOC SATA card?

 

Going back to your original question: "...the write operation stops part way through..."

When the 'write' stops post the entire log again.

 

It stopped again, but the stupid logfile reverted back to the version which doesn't tell anything, and has only an entry once every few hours

 

edit: And I just noticed it happened on another drive, disk5 this time. /end edit

 

Below everything it has reported today. syslogd (whatever that is) restarted at 4:40am, while I was asleep. Perhaps that's causing the syslog becoming a simple version? There is a file called syslog.1 which stops about an hour before that.

 

This is really frustrating.

 

Jan 24 04:40:01 TheMonolith syslogd 1.4.1: restart.
Jan 24 07:40:24 TheMonolith kernel:  sde: sde1
Jan 24 09:13:15 TheMonolith dhcpcd[1087]: eth0: renewing lease of 192.168.1.177
Jan 24 09:13:15 TheMonolith dhcpcd[1087]: eth0: acknowledged 192.168.1.177 from 192.168.1.1
Jan 24 09:13:15 TheMonolith dhcpcd[1087]: eth0: leased 192.168.1.177 for 43200 seconds
Jan 24 14:30:33 TheMonolith dhcpcd[1087]: eth0: renewing lease of 192.168.1.177
Jan 24 14:30:33 TheMonolith dhcpcd[1087]: eth0: acknowledged 192.168.1.177 from 192.168.1.1
Jan 24 14:30:33 TheMonolith dhcpcd[1087]: eth0: leased 192.168.1.177 for 43200 seconds
Jan 24 15:54:47 TheMonolith in.telnetd[29494]: connect from 192.168.1.165 (192.168.1.165)
Jan 24 15:54:53 TheMonolith login[29495]: ROOT LOGIN  on '/dev/pts/1' from 'SpacemanSpiff.lan'

 

edit: after deleting the Transmission package from the flash and rebooting, the thousands of error messages are now gone. Let's see if that sorted things out. I'll report back in a few days when I have more data.

It happened yet again: copying timed out after just 65.5KB. And as previously, there is no syslog entry for hours before the copying attempt, or during it.

 

Just like earlier, copying the same data to another share on the same drive works just fine. This has happened on two separate disks, so I doubt it is due to a disk error.

 

Since my syslog doesn't reveal anything and no one seems to know how to get it working, I'm out of ideas how to fix this, or even how to diagnose it. My suspicion is that one or both issues are caused by a plugin, working or one of the ones I tried to install but couldn't get to work.

 

Is there a way to get to a clean unRAID install without risking losing data on the array?

simplexml_load_file() errors are typically caused by an incorrect download of the plugin. Right-click, save as from the link will save an HTML file (intended for viewing the contents) instead of the plugin XML. Follow the link and then right-click RAW, save as.

Ok, I reverted to stock using the steps in dgaschk's sig. Currently running a parity check, and hoping things are back to normal.

 

I'll report back in a few days if everything is working.

Parity check found no errors. Now with a stock system, the issue is back. Copying to ShareNotWorking on disk5 or disk3 times out after a few kilos or megabytes.

 

I found a work-around: I can copy files to ShareWorking on the same disk, then move them over to ShareNotWorking on the same disk just fine.

 

Nevertheless, this is a rather serious bug, undermining one of the killer features of unRAID. I will contact Lime Tech directly to find a solution to this, and the syslog issue.