November 21, 20187 yr I have been trying to solve this myself for a month or two. Basically, the docker becomes read-only and shuts down all my dockers. Here is what I have looked at / tried. Logging when it happens: Nov 21 04:00:54 BBB CA Backup/Restore: Deleting /mnt/user/appdatabackup/[email protected] Nov 21 04:00:57 BBB CA Backup/Restore: Backup / Restore Completed Nov 21 04:40:01 BBB root: Fix Common Problems Version 2018.11.03 Nov 21 04:40:20 BBB root: Fix Common Problems: Error: Unable to write to Docker Image Nov 21 04:40:36 BBB root: Fix Common Problems: Other Warning: CPU possibly will not throttle down frequency at idle ** Ignored Nov 21 04:40:36 BBB root: Fix Common Problems: Warning: Multiple registration keys found ** Ignored Nov 21 05:00:01 BBB Plugin Auto Update: Checking for available plugin updates Nov 21 05:00:01 BBB Docker Auto Update: Community Applications Docker Autoupdate running Nov 21 05:00:01 BBB Docker Auto Update: Checking for available updates Nov 21 05:00:06 BBB Plugin Auto Update: Auto Updating unassigned.devices.plg Nov 21 05:00:06 BBB root: plugin: running: anonymous Nov 21 05:00:06 BBB root: plugin: running: anonymous DOCKER VOLUME INFO: DOCKER CONTAINERS: Docker Container log: USER SHARES To Docker Mappings: /mnt/user/downloads/ Use cache disk: NO /mnt/user/appdata/ User Cache disk: Prefer /mnt/user/appdatabackup/ Use Cache disk:NO /mnt/user/Movies/ Use Cache disk :NO /mnt/user/TV/ Use Cache disk :NO I know this is usually a case of something downloading into the cache drive and filling it. However, I have tried to look everywhere I can think of to find something doing this and have run out of ideas. So I am turning to you guys for some thoughts or suggestions thanks! Diagnostic information attached bbb-diagnostics-20181121-1159.zip
November 21, 20187 yr You have a corrupt docker.img that's mounted read-only. You can delete it and re-create it easily: Edited November 21, 20187 yr by John_M Added how to fix
November 21, 20187 yr Author 14 minutes ago, John_M said: You have a corrupt docker.img that's mounted read-only. You can delete it and re-create it easily: Yea. So I seem to need to do that every couple of days. Re-creating or expanding the docker image works for a few days then the same thing happens.
November 21, 20187 yr Just now, tacobelldog52 said: So I seem to need to do that every couple of days. Perhaps it would have been worth mentioning that in your OP. OK. Looking closer I see problems with your PNY SSD (sdc). I'd check the power and SATA cables in the first instance.
November 21, 20187 yr Author Just now, John_M said: Perhaps it would have been worth mentioning that in your OP. OK. Looking closer I see problems with your PNY SSD (sdc). I'd check the power and SATA cables in the first instance. Yeah sorry, I should have. Had it written down in my notes to mention.... Then didn't my bad. I'll shut it down and check the cables.
November 21, 20187 yr Author 5 minutes ago, John_M said: Perhaps it would have been worth mentioning that in your OP. OK. Looking closer I see problems with your PNY SSD (sdc). I'd check the power and SATA cables in the first instance. Reseated the drive cage for the SSDs. Compressed air the cables and reseated on both sides. Think it would benefit to run like pre-clear on the SSDs to check for errors before re-creating the docker?
November 21, 20187 yr No problem. This is the error regarding sdc from your syslog so you can look out for it in future: Nov 20 00:00:52 BBB kernel: sd 1:0:1:0: [sdc] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Nov 20 00:00:52 BBB kernel: sd 1:0:1:0: [sdc] tag#2 Sense Key : 0x5 [current] Nov 20 00:00:52 BBB kernel: sd 1:0:1:0: [sdc] tag#2 ASC=0x21 ASCQ=0x0 Nov 20 00:00:52 BBB kernel: sd 1:0:1:0: [sdc] tag#2 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00 Nov 20 00:00:52 BBB kernel: print_req_error: critical target error, dev sdc, sector 234441536 There are CRC errors in sdc's SMART report. I'm not as familiar with SMART reports from SSDs (and I've never owned a PNY one) as from HDDs but it looks as though it confirms a cable problem. Yes, you could unassign it from the cache pool, clear it and add it back to the cache pool.
November 21, 20187 yr I just noticed this timewarp: May 30 19:06:53 BBB kernel: XFS (md5): Mounting V5 Filesystem May 30 19:06:53 BBB kernel: XFS (md5): Starting recovery (logdev: internal) Nov 16 17:37:47 BBB kernel: XFS (md5): Ending recovery (logdev: internal) Nov 16 17:37:47 BBB emhttpd: shcmd (81): xfs_growfs /mnt/disk5 Did you reset the clock?
November 21, 20187 yr Author Just now, John_M said: I just noticed this timewarp: May 30 19:06:53 BBB kernel: XFS (md5): Mounting V5 Filesystem May 30 19:06:53 BBB kernel: XFS (md5): Starting recovery (logdev: internal) Nov 16 17:37:47 BBB kernel: XFS (md5): Ending recovery (logdev: internal) Nov 16 17:37:47 BBB emhttpd: shcmd (81): xfs_growfs /mnt/disk5 Did you reset the clock? No that's odd...
November 21, 20187 yr Author 49 minutes ago, John_M said: I just noticed this timewarp: May 30 19:06:53 BBB kernel: XFS (md5): Mounting V5 Filesystem May 30 19:06:53 BBB kernel: XFS (md5): Starting recovery (logdev: internal) Nov 16 17:37:47 BBB kernel: XFS (md5): Ending recovery (logdev: internal) Nov 16 17:37:47 BBB emhttpd: shcmd (81): xfs_growfs /mnt/disk5 Did you reset the clock? ############################################################################################################################ # # # unRAID Server Preclear of disk PNY05162166770200E12 # # Cycle 1 of 1, partition start on sector 64. # # # # # # Step 1 of 5 - Pre-read verification: [0:04:15 @ 474 MB/s] SUCCESS # # Step 2 of 5 - Zeroing the disk: [0:30:12 @ 66 MB/s] SUCCESS # # Step 3 of 5 - Writing unRAID's Preclear signature: SUCCESS # # Step 4 of 5 - Verifying unRAID's Preclear signature: SUCCESS # # Step 5 of 5 - Post-Read verification: [0:05:28 @ 367 MB/s] SUCCESS # # # # # # # # # # # # # # # ############################################################################################################################ # Cycle elapsed time: 0:39:58 | Total elapsed time: 0:39:58 # ############################################################################################################################ cat: /tmp/.preclear/sdc/smart_error: No such file or directory --> RESULT: Preclear Finished Successfully!.
November 21, 20187 yr Now reassign it to the cache pool and let BTRFS re-balance. Then recreate your docker.img and keep an eye on the syslog.
November 21, 20187 yr Author 2 minutes ago, John_M said: Now reassign it to the cache pool and let BTRFS re-balance. Then recreate your docker.img and keep an eye on the syslog. Yep that is what I am doing now
November 22, 20187 yr I'm having the same problem and it doesn't make sense. It was working. My cache got full as usual and then moved to the raid like usual and after a day. My docker image was readonly. I just recreate it yesterday and today I'm getting the same error. I'm also using the latest 6.6.5 would that be the issue?
November 22, 20187 yr 9 minutes ago, gacpac said: I'm also using the latest 6.6.5 would that be the issue? No. Start a new thread and attach your diagnostics.
Archived
This topic is now archived and is closed to further replies.