syncing: delete dir: lstat Screenshots: input/output error

SyncK · January 22, 2024, 6:40am

first, i rename and delete Screenshots folder on Android(MIUI14); then sync to computer(mint21), and igot this error.

how should i fix it, current i cant open this sync folder, and cant delete Screenshots on computer.

here’s the logs:

2024-01-22 12:49:36 TCP listener ([::]:22000) starting
2024-01-22 12:49:36 QUIC listener ([::]:22000) starting
2024-01-22 12:49:36 GUI and API listening on 127.0.0.1:8384
2024-01-22 12:49:36 Access the GUI via the following URL: http://127.0.0.1:8384/
2024-01-22 12:49:36 My name is "feng-GE5S"
2024-01-22 12:49:36 Device XBT3ILA-AJFUV2T-7Y3PTKW-AXNJEAY-FZY6JFY-XRFQ6GL-XEF6ELV-LJ6RFQJ is "Good" at [dynamic]
2024-01-22 12:49:36 Device 4TWGK2E-DMTHO75-IULDJPQ-2WBNPLE-WO7JFKK-DXEAGGD-WXIEEAH-HCV4XA2 is "mi12T" at [dynamic]
2024-01-22 12:49:36 Ready to synchronize "oBsync" (60nqd-v6jpd) (sendreceive)
2024-01-22 12:49:39 Joined relay relay://218.81.160.38:22067
2024-01-22 12:49:46 quic://0.0.0.0:22000 detected NAT type: Symmetric NAT
2024-01-22 12:49:57 Detected 1 NAT service
2024-01-22 12:50:08 Completed initial scan of sendreceive folder "oBsync" (60nqd-v6jpd)
2024-01-22 12:52:44 Established secure connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCI90979TV3M3OFK41M9KHSES
2024-01-22 12:52:44 Device 4TWGK2E client is "syncthing v1.27.2-preview.1" named "23049RAD8C" at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCI90979TV3M3OFK41M9KHSES
2024-01-22 12:54:36 Scanner (folder "oBsync" (60nqd-v6jpd), item "Screenshots"): scan: lstat /media/ddocs/Document/Obsync/Screenshots: input/output error
2024-01-22 13:25:55 Lost primary connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCI90979TV3M3OFK41M9KHSES: reading length: read tcp 192.168.2.10:22000->192.168.2.5:22000: read: connection reset by peer (0 remain)
2024-01-22 13:25:55 Connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCI90979TV3M3OFK41M9KHSES closed: reading length: read tcp 192.168.2.10:22000->192.168.2.5:22000: read: connection reset by peer
2024-01-22 13:31:11 Established secure connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCIHCR0M8DTQIICG15PQT1H2C
2024-01-22 13:31:11 Device 4TWGK2E client is "syncthing v1.27.2-preview.1" named "23049RAD8C" at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCIHCR0M8DTQIICG15PQT1H2C
2024-01-22 13:31:26 Lost primary connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCIHCR0M8DTQIICG15PQT1H2C: reading length: read tcp 192.168.2.10:22000->192.168.2.5:22000: read: connection reset by peer (0 remain)
2024-01-22 13:31:26 Connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCIHCR0M8DTQIICG15PQT1H2C closed: reading length: read tcp 192.168.2.10:22000->192.168.2.5:22000: read: connection reset by peer
2024-01-22 13:35:18 Established secure connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCII9KKAN3FUOE6JV2L3CRLGK
2024-01-22 13:35:18 Device 4TWGK2E client is "syncthing v1.27.2-preview.1" named "23049RAD8C" at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCII9KKAN3FUOE6JV2L3CRLGK
2024-01-22 13:39:04 Lost primary connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCII9KKAN3FUOE6JV2L3CRLGK: reading length: read tcp 192.168.2.10:22000->192.168.2.5:22000: read: connection reset by peer (0 remain)
2024-01-22 13:39:04 Connection to 4TWGK2E at 192.168.2.10:22000-192.168.2.5:22000/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TCII9KKAN3FUOE6JV2L3CRLGK closed: reading length: read tcp 192.168.2.10:22000->192.168.2.5:22000: read: connection reset by peer
2024-01-22 13:39:37 Scanner (folder "oBsync" (60nqd-v6jpd), item "Screenshots"): scan: lstat /media/ddocs/Document/Obsync/Screenshots: input/output error
2024-01-22 13:40:08 Scanner (folder "oBsync" (60nqd-v6jpd), item "Screenshots"): scan: lstat /media/ddocs/Document/Obsync/Screenshots: input/output error

bt90 · January 22, 2024, 6:54am

Looks like a broken filesystem/disk.

SyncK · January 22, 2024, 6:57am

Thanks for the reply, but before I deleted it, I had normal access to the contents of the Screenshots folder on my computer. I don’t think that’s the reason.

and dmesg |grep error didn’t get any error

and Disks check filesystem is ok too.

gadget · January 22, 2024, 8:11am

Based on the model number shown in the screenshot, the NTFS format, and being used with a Linux system, I’m guessing it might be a portable USB drive.

Unfortunately, dmesg |grep error will miss a lot of disk errors. And the NTFS repair tools for Linux (as good as they are) are all reverse-engineered, so they don’t cover all the possible filesystem errors. First paragraph from the ntfsfix manpage:

ntfsfix is a utility that fixes some common NTFS problems. ntfsfix is NOT a Linux version of chkdsk. It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows.

I wouldn’t be surprised if the “Screenshots” directory just happened to be sitting on a flaky spot on a disk platter. NTFS has a tendency to fragment files pretty easily, so as you create/add/delete stuff they don’t necessarily end up in the same spot on the disk again.

If you don’t already have it installed, install the “smartmontools” package (e.g. apt install smartmontools) or a GUI wrapper that uses it. Then run a long self-test with the following command syntax:

smartctl -t long /dev/sdx

Substitute the correct device for /dev/sdx (use the lsblk command or GUI tool look it up if needed). A long self-test might take a few hours for a 1 TB HDD.

The progress and final results can be checked like so:

smartctl -a /dev/sdx

There are plenty of online guides/articles about the various codes (there are some commonly shared codes, but there are also lots of vendor-specific codes). Or post it on this forum and I’m certain there are plenty of folks who can easily interpret the results.

After the self-test, it’d also be worth doing a bad block scan:

badblocks -s /dev/sdx

Default is read-only. A multi-pass read/write is ideal because a drive can be fine for reads while failing writes.

SyncK · January 23, 2024, 7:17am

yes, iam using win-mint double-system, the sync folder is in ntfs partition.

yestoday i restart computer and login win system, it automatically did a disk check, after i restarted and login mint system, it no longer had this error.

thanks for your kind help agin ^.^

system · February 22, 2024, 7:17am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.