Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[KINDA SOLVED] corrupt files taking down shares

Featured Replies

I have some files that seem to be corrupt. When I telnet in as root and try to do an ls on the directory or rm the whole thing recursively (or any other file operation on that directory) I just immediately get the message that "Transport endpoint is not connected" and all my shares are dropped. If I stop the array and reboot they come back up and work fine as long as I stay away from the corrupt data.

 

How can I remove the files if the share drops when I try to delete them? Is there another way to deal with this? I have transferred all good data off the drive and was planning to just do a preclear and start over with it (thankfully there wasn't much on it). But then I realized that the parity drive keeps the corrupt data around.

 

Any ideas?

 

UPDATE: My solution (working so far) was to remove the drive with the offending files and create a new config. I was without protection while the parity was rebuilding, so there was risk involved. I precleared the drive and added it back to the array and all is well for now. I guess this is really more of a work-around than a solution...

There are reiserfsck ie file system checks detailed in the unRAID wiki. Try running the check on that drive and post the results.

  • Author

Here's the result of reiserfsck - looks normal:

 

###########
reiserfsck --check started at Sun Mar 17 15:17:05 2013
###########
Replaying journal: Done.
Reiserfs journal '/dev/md3' in blocks [18..8211]: 0 transactions replayed
Checking internal tree.. finished                                
Comparing bitmaps..finished
Checking Semantic tree:
finished                                                                       
No corruptions found
There are on the filesystem:
Leaves 103898
Internal nodes 703
Directories 89339
Other files 387312
Data block pointers 4743264 (2427 of them are zero)
Safe links 0
###########
reiserfsck finished at Sun Mar 17 15:35:13 2013
###########

 

 

I'm attaching a copy of my syslog from restart to the time where I caused the failure by trying to rm the files. Any help would be greatly appreciated and like I said, if it means losing all the data on the drive I'm fine with that because I have everything I need off of that particular drive.

unraid_syslog.zip

  • Author

Does anyone have ideas on how to get rid of these files?

I am no expert on Linux but when a googled your (partial) error message, it appears (to me) that it is NOT a problem with the files themselves but rather with the logical connection between the OS and the physical drive.  So before you try to do anything with the files on that particular hard disk, wait for someone to back to you with an analysis of your syslog.  ( It has been downloaded twice.) 

  • Author

Thanks for the feedback Frank. I'm honestly not sure what to do at this point, so waiting for someone to get back to me is kind of my only option right now :)

 

The reason I say it's a problem with these specific files is because everything works fine otherwise and the problem is 100% repeatable when I try to delete these files. It's never happened with any other files on that drive.

If all else fails, you could unassign that drive, and set a new config with the remaining drives and rebuild parity without that drive. Then you could preclear it, and add it back. HOWEVER... doing that will make you vulnerable to drive failure while you are rebuilding parity. I'd do a non-correcting parity check and examine all the drives smart reports before proceeding.

  • Author

Thanks Jonathanm. I knew there had to be a way, but I'm new to unraid so I didn't even know that new config button was there. I know there's risk involved, but that may be my only solution.

  • Author

I don't really know what I'm looking for, but I don't see any obvious problems. Here are the results of those commands:

 

root@Bunker:~# lsmod
Module                  Size  Used by
md_mod                 47078  7 
xor                    11590  1 md_mod
sg                     13487  0 
sata_sil                5391  3 
i2c_i801                6466  0 
i2c_core               13360  1 i2c_i801
coretemp                4447  0 
hwmon                    890  1 coretemp
ahci                   17138  6 
libahci                14226  1 ahci
r8168                 258070  0 
root@Bunker:~# ethtool -i eth0
driver: r8168
version: 8.035.00-NAPI
firmware-version: 
bus-info: 0000:02:00.0
root@Bunker:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
root@Bunker:~# ifconfig
eth0      Link encap:Ethernet  HWaddr bc:5f:f4:56:2f:3b  
          inet addr:192.168.1.200  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6793149 errors:0 dropped:44 overruns:0 frame:0
          TX packets:9020961 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2179999548 (2.0 GiB)  TX bytes:599997589 (572.2 MiB)
          Interrupt:41 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:148058 errors:0 dropped:0 overruns:0 frame:0
          TX packets:148058 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:22889979 (21.8 MiB)  TX bytes:22889979 (21.8 MiB)

root@Bunker:~# ethtool -S eth0
NIC statistics:
     tx_packets: 9021221
     rx_packets: 6793423
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 6716468
     broadcast: 46238
     multicast: 30717
     tx_aborted: 0
     tx_underrun: 0

im not a linux expert but definitely not a noob either. there seem to be a myriad of "transport endpoint errors" in regards to unraid. just search and youll find numerous threads. havent heard of it happening when accessing specific files though. there are probably a number of causes. i myself have had the issue for months and it is driving me crazy. still haven found a fix, while others have.

  • Author

My solution (working so far) was to remove the drive with the offending files and create a new config. I was without protection while the parity was rebuilding, so there was risk involved. I precleared the drive and added it back to the array and all is well for now. I guess this is really more of a work-around than a solution...

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.