September 27, 20187 yr Hi, I'm getting since a couple of days an error when try to write on my Samba shares. The shares have a write access for the selected user. I've observed also that Docker service can't started due to the error: Sep 27 20:57:34 Tower root: mount: /var/lib/docker: wrong fs type, bad option, bad superblock on /dev/loop3, missing codepage or helper program, or other error. I've tried to recreate the ssd cache and re-format it. So I've tried to backup my appdata, isos ans system dirs using tar -czvf command but I have obtained an I/O error. tar -czvf Archives/cache.tar.gz appdata isos system tar (child): Archives/cache.tar.gz: Cannot open: Input/output error tar (child): Error is not recoverable: exiting now appdata/ appdata/kde/ appdata/kde/cache-14f538808b47 appdata/kde/tmp-14f538808b47 appdata/kde/socket-14f538808b47 appdata/kde/share/ appdata/kde/share/config/ appdata/kde/share/config/phonondevicesrc appdata/kde/share/config/drkonqirc appdata/kde/share/config/katerc appdata/kde/share/config/kcookiejarrc appdata/kde/share/config/kdedrc appdata/kde/share/config/kget_multisegkiofactory.rc appdata/kde/share/config/kgetrc tar: Archives/cache.tar.gz: Cannot write: Broken pipe tar: Child returned status 2 tar: Error is not recoverable: exiting now Please find as attachement the diagnostics file. Could you please give me any help? Regards, S. tower-diagnostics-20180927-2210.zip
September 27, 20187 yr Community Expert You don't need to reformat your cache, at least not for now, you need to delete and recreate the docker image, check the docker FAQ if you need help. There's also filesystem corruption on disk5, run a check: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui
September 27, 20187 yr Community Expert Also, you have a lot of array disks connected using USB, this is not recommended for a variety of reasons, USB is usually bad at error handling, SMART is not being monitored for those disks, and the identification string is changed, i.e., if one day you connect them using internal SATA ports or an HBA Unraid will complain that they are the wrong disks.
September 28, 20187 yr Author I did a check on Disk5 such as suggested in the link by running the check with repair (option -nd). Below the xfs_repair_status : Phase 1 - find and verify superblock... - block cache size set to 738272 entries Phase 2 - using internal log - zero log... zero_log: head block 16739 tail block 16733 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... Metadata CRC error detected at xfs_allocbt block 0x3a382260/0x1000 btree block 1/8 is suspect, error -74 bad magic # 0xaab40a7f in btbno block 1/8 Metadata CRC error detected at xfs_allocbt block 0x74704448/0x1000 btree block 2/1 is suspect, error -74 bad magic # 0xb763e301 in btbno block 2/1 Metadata CRC error detected at xfs_allocbt block 0x3a382250/0x1000 Metadata CRC error detected at xfs_allocbt block 0x74704450/0x1000 btree block 2/2 is suspect, error -74 btree block 1/6 is suspect, error -74 bad magic # 0xb5dea178 in btcnt block 2/2 bad magic # 0x4d06950 in btcnt block 1/6 agf_freeblks 121803650, counted 0 in ag 2 agf_freeblks 121971479, counted 0 in ag 1 agf_longest 113467576, counted 0 in ag 2 agf_longest 105317432, counted 0 in ag 1 Metadata CRC error detected at xfs_inobt block 0xaea86678/0x1000 agf_btreeblks 4, counted 0 in ag 1 btree block 3/3 is suspect, error -74 bad magic # 0x81c1838 in inobt block 3/3 Metadata CRC error detected at xfs_inobt block 0x74704458/0x1000 btree block 2/3 is suspect, error -74 bad magic # 0x55978c97 in inobt block 2/3 Metadata CRC error detected at xfs_inobt block 0x3a382238/0x1000 btree block 1/3 is suspect, error -74 bad magic # 0x4ce3550 in inobt block 1/3 inode chunk claims untracked block, finobt block - agno 2, bno 249252, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 249253, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 249254, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 249255, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 249256, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 249257, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 249258, inopb 8 inode chunk claims untracked block, finobt block - agno 1, bno 3996, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 249259, inopb 8 inode chunk claims untracked block, finobt block - agno 1, bno 3997, inopb 8 undiscovered finobt record, ino 2149477664 (2/1994016) inode chunk claims untracked block, finobt block - agno 1, bno 3998, inopb 8 inode chunk claims untracked block, finobt block - agno 1, bno 3999, inopb 8 inode chunk claims untracked block, finobt block - agno 1, bno 4000, inopb 8 inode chunk claims untracked block, finobt block - agno 1, bno 4001, inopb 8 inode chunk claims untracked block, finobt block - agno 1, bno 4002, inopb 8 inode chunk claims untracked block, finobt block - agno 1, bno 4003, inopb 8 agi_count 256, counted 0 in ag 2 agi_freecount 25, counted 0 in ag 2 undiscovered finobt record, ino 1073773792 (1/31968) agi_count 576, counted 0 in ag 1 agi_freecount 44, counted 0 in ag 1 sb_icount 896, counted 64 sb_ifree 127, counted 58 sb_fdblocks 975359350, counted 732565281 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... found inodes not in the inode allocation tree found inodes not in the inode allocation tree - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 4 entry "Audio 2018-08-23" in shortform directory 99 references non-existent inode 1073741920 - agno = 3 would have junked entry "Audio 2018-08-23" in directory inode 99 - agno = 5 - agno = 7 - agno = 6 entry "Audio 2018-09-02" in shortform directory 99 references non-existent inode 2149391456 would have junked entry "Audio 2018-09-02" in directory inode 99 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 Maximum metadata LSN (2130140933:-29345724) is ahead of log (1:16739). Would format log to cycle 2130140936. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Fri Sep 28 23:24:03 2018 Phase Start End Duration Phase 1: 09/28 23:24:03 09/28 23:24:03 Phase 2: 09/28 23:24:03 09/28 23:24:03 Phase 3: 09/28 23:24:03 09/28 23:24:03 Phase 4: 09/28 23:24:03 09/28 23:24:03 Phase 5: Skipped Phase 6: Skipped Phase 7: Skipped Total run time: I'm not sure that the problem was fixed.
September 28, 20187 yr Community Expert You need to remove the n flag if you want the repair to actually be carried out.
September 30, 20187 yr Author Thanks a lot! I've fixed my issues by following your comments : I/O Error and Docker issues. Last question, do you recommend to use eSata instead of USB3.0?
September 30, 20187 yr Community Expert 5 hours ago, Slamer said: Last question, do you recommend to use eSata instead of USB3.0? I would recommend SAS instead, but eSATA is better than USB, especially if you don't use it together with a port multiplier and keep the cables short, if used with a port multiplier you might get lucky, might not.
Archived
This topic is now archived and is closed to further replies.