I replaced a buggy Windows Vista installation with Ubuntu. All works fine except that the main HD where I had all my files are now inaccessible. Here is the error message I get:
Error mounting: mount exited with exit code 13: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read NTFS $Bitmap: Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details
Is it necessarily a hardware problem? If not, is there a way to repair the HD from Ubuntu?
muru
194k53 gold badges475 silver badges725 bronze badges
asked Oct 31, 2011 at 15:13
0
ntfsfix worked for me :
sudo ntfsfix /dev/sdb1
Provided in the ntfs-3g package.
jokerdino♦
41k24 gold badges132 silver badges201 bronze badges
answered Jun 27, 2012 at 21:32
Marc MMarc M
5411 gold badge4 silver badges2 bronze badges
2
chkdsk /R is a pretty important command when things get hairy with NTFS. Unfortunately I don’t know of a Linux tool that comes close to covering everything it does. In short, to run it, you’re going to need some sort of Windows recovery disk.
If you don’t have one to hand, there’s an ISO offered up in a thread on another set of support forums (see the first answer).
There are tools like ntfsfix (part of the ntfsprogs package) that can do surface checks on NTFS disks but they don’t tend to be able to fix the drives.
answered Oct 31, 2011 at 15:24
Oli♦Oli
290k117 gold badges680 silver badges837 bronze badges
2
NTFS is a closed source Microsoft file system, and you’ll need Windows to repair it, by running chkdsk /f, as suggested.
If the problem is hardware related, you’ll have to replace the hdd.
answered Oct 31, 2011 at 15:22
mikewhatevermikewhatever
32.3k10 gold badges87 silver badges99 bronze badges
1
i have encountered a similar situation once,then i kept the harddisk on windows,then a popup appeared asking to check the disk for errors.
if didn’t ask goto computer,right click on the drive and then click on properties,there would be a tab «tools»
select «check now»
this type of errors occur if you dont safely remove harddisks.
Braiam
67k31 gold badges177 silver badges265 bronze badges
answered Oct 31, 2011 at 16:23
saiki4116saiki4116
6492 gold badges8 silver badges22 bronze badges
Background:
So I was facing, more or less, the same issue. Around 12 files on the NTFS partition of my HD were inaccessible nor could they be deleted. Got to know about them through backintime’s error logs. Fired up my Window 7 on vmware, accessed that folder containing the files through shared folder and copied them to a new folder. But for some reason I was not able to delete those files (0 bytes) from Windows 7 either. No surprise there, the OS did not have low-level access to those files.
ntfsfix did not fix it, said nothing was wrong, and fsck said all’s cool with the the device. I could not chkdsk /R because the files were shared through network drive. And I didn’t have Window 7 installed on my physical machine.
Solution (steps for vmplayer, but could easily be followed for virtualbox):
- Add a new HD to your vm (had to start vmplayer as root)
- When prompted for the disk type choose physical disk
- Choose the correct device (for this reason vmplayer was started as root)
- Select «Use individual partitions»
- Select the partition containing the buggy files
- Finish adding
- Start the vm
For me Windows 7 detected the new partition and did a checkdisk on boot. It had a lot of (Index) cleaning to do. The buggy files were gone. And the problem solved.
answered Jun 6, 2015 at 21:13
Bleeding FingersBleeding Fingers
6602 gold badges10 silver badges27 bronze badges
1
I got this after newly fomratting an SD card as ntfs, all I had to do what umount it first.
sudo umount -l /dev/sdx1
then mount worked again
answered Jan 19, 2019 at 2:27
teknopaulteknopaul
1,98715 silver badges18 bronze badges
You must log in to answer this question.
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.
Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода. Неожиданная ошибка: Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода
Опишем окружение в котором возникла ошибка ввода/вывода:
- ОС: Linux совместно с Windows
- HDD: два диска, на одном Windows XP (далее ДИСК 1), на другом Linux Debian 7.x (далее ДИСК 2)
Каждый диск разбит на два раздела, — на диске с Windows XP два раздела с файловой системой NTFS, на втором диске с Linux Debian 7.x один раздел EXT4, на котором и установлен Linux, а на втором собственно NTFS. Окружением для рабочего стола Linux было выбрано Xfce, файловый менеджер по умолчанию Thunar 1.2.3 (Thunar это быстрый и простой в использовании файловый менеджер для рабочего окружения Xfce.), текстовый редактор gedit.
Ошибка ввода/вывода появилась на ДИСК 2 в разделе с файловой системой NTFS, который монтировался вручную после входа в уч. запись Linux.
Когда именно появилась Ошибка ввода/вывода на NTFS разделе сказать сложно, но предположительно после очередного переключения между ОС. На ДИСК 2 были расположены совместно редактируемые файлы, — т.е. эти фалы (Test.txt один из них) были открыты в текстовом редакторе notepad++ под ОС Windows XP и в текстовом редакторе gedit под Linux Debian 7.x. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.
Иногда выполнялась перезагрузка ОС Linux Debian 7.x, но ОС Windows XP всегда переводилась в спящий режим, при этом после перезагрузки Linux Debian 7.x восстанавливалась сессия запущенных на момент перезагрузки/выключения программ, в том числе и редактора gedit с совместно редактируемым Test.txt. Потому как раздел NTFS с ДИСК 2 монтировался вручную, то после перезагрузки в gedit был открыт Test.txt с сообщением об ошибке доступа, но после ручного монтирования NTFS раздела редактор gedit предлагал обновить файл по причине его изменения.
Не скажу, как и почему стала появляться Ошибка ввода/вывода, — возможно gedit попутал uid/gid (файловые/индексные дескрипторы) и при сохранении в Master File Table (MFT) прописал не то, не тем и не туда, но вот, что получилось после очередного переключения между ОС при совместном редактировании файлов:
Попытка открыть каталог «/media/SATA2/PROFILE/User/Рабочий стол» в Thunar:
Не удалось открыть папку: «Рабочий стол».
Ошибка при получении информации о файле «/media/SATA2/PROFILE/User/Рабочий \
стол/Test.txt»: Ошибка ввода/вывода.
Остальное содержимое каталога было не доступно для просмотра/редактирования
Попытка сохранить уже открытый в gedit текстовый файл Test.txt:
Не удалось сохранить файл /media/SATA2/PROFILE/Use…бочий стол/Test.txt.
Неожиданная ошибка: Ошибка при получении информации о файле «/media/SATA2/ \
PROFILE/User/Рабочий стол/Test.txt»: Ошибка ввода/вывода
При использовании файлового менеджера NAUTILUS удалось открыть каталог /media/SATA2/PROFILE/User/Рабочий стол и удалить «Test.txt«, но вот создать заново Test.txt или создать «Безымянный документ» и переименовать его в «Test.txt» не удалось:
Не удалось переименовать объект.
Не удалось переименовать объект «Безымянный документ» в «Test.txt»: Произошла \
ошибка при переименовании файла: Ошибка ввода/вывода
Следующий глюк сопутствовал Ошибкам ввода/вывода, но вот при каких условиях возник не припомню (вероятно при нескольких одновременных попытках монтирования):
Не удалось подключить «SATA2».
DBus error org.gtk.Private.RemoteVolumeMonitor.Failed: An operation is already \
pending.
Владелец и права на файл Test.txt не известны:
root@linux:/media/SATA2/PROFILE/User/Рабочий стол# ls -la ls: невозможно получить доступ к Test.txt: Ошибка ввода/вывода итого 4415 drwx------ 1 User User 12288 Сен 2 22:21 . drwx------ 1 User User 8192 Авг 18 07:48 .. -rw------- 1 User User 1830 Сен 2 11:56 Test_2.txt -rw------- 1 User User 3722 Сен 2 21:22 Test_3.txt -????????? ? ? ? ? ? Test.txt
В некоторых манах для лечения предлагалось использовать ntfsfix -b /dev/sdb5, предварительно отмонтировав его, — но проблема не решилась…
В среде Linux на ДИСК 2 были созданы текстовые файлы «Test_2.txt» и «Test_3.txt» и совершено переключение на Windows XP где эти файлы были не доступны даже для просмотра, хотя после перехода обратно в Linux их можно было просматривать и редактировать…
Проблему с косяком в NTFS разделе на ДИСК 2 удалось решить только с помощью стандартного средства проверки дисков входящего в ОС Windows XP в процессе перезагрузки:
CHKDSK is verifyng indexes (stage 2 of 5)
Deleting index entry .Trash-1000 in index $I30 of file 5
Deleting index entry Test.txt in index $I30 of file 702196
Deleting index entry Test_2.txt in index $I30 of file 702196
Deleting index entry Test_3.txt in index $I30 of file 702196
Увидев на экране Deleting index entry …
я зразу же понял, что этих файлов нам уже не видать как своих ушей, — разумеется, так и есть.
Вероятно (http://ru.wikipedia.org/wiki/NTFS#Linux) поддержка NTFS в Linux осуществляется при помощи ntfsmount (использующая FUSE), которая позволяет монтировать NTFS-разделы на запись, но с некоторыми ограничениями.
Существует также ещё один способ монтирования NTFS с возможностью чтения/записи, — это Проект NTFS-3G, который по заявлениям является более функциональным и стабильным вариантом (также использующий FUSE) дающий более широкие возможности по созданию/изменению/удалению/перемещению файлов (исключая сжатые и зашифрованные файлы) в файловой системе NTFS. В тоже время тесты показывают, что NTFS-3G не оптимизирован для производительности, а разработчики заявляют, что это связано с обеспечением повышенной надёжности и, что производительность является второстепенной задачей.
Никто не застрахован от возникновения каких-то ошибок на разделах с файловой системой NTFS или же вовсе полного краха таких разделов с необходимостью полного форматирования. Поэтому, при использовании Linux лучше вовсе не использовать NTFS разделов, или же использовать их как можно реже.
Основные причины ошибок ввода/вывода
- Значит это всё масонский заговор дядюшки Билла… На буржуйских веб-ресурсах бродит информация о том, что стандарт NTFS меняется в каждой новой версии Windows, что вполне предсказуемо, включая сервис-паки и промежуточные патчи. При этом, разумеется, изменения не придаются общественной огласке, а следовательно нет возможности в полной мере обеспечить стабильную работу с NTFS в свободных ОС таких как Linux.
- Отмечено также, что на разделах NTFS возможно изменение уже существующих файлов с незначительным изменением их размера, но при создании новых файлов или существенного изменения уже существующих может вызвать проблемы и даже «запороть» весь раздел.
- Проблемы с отображением созданных в Linux на NTFS разделе файлов, а также проблемы с ошибками ввода/вывода, могут возникнуть если на ПК установлено несколько ОС (ака Мультизагрузка, Multi-boot), — Windows vs Linux. Пик ошибок ввода/вывода отмечен когда Windows была переведена в спящий режим, а после очередного включения запущен Linux из-под которого на NTFS разделе создавались/редактировались файлы. Другими словами если мы хотим из-под ОС Linux, в условиях мультизагрузки (Multi-boot), относительно безопасно создавать/редактировать файлы на NTFS разделах совместно используемых обеими ОС, то перед запуском ОС Linux мы должны выполнить полную перезагрузку или остановку ОС Windows, но не в коем случае не переводить Windows в спящий режим!
- SRT-кэширование (Smart Response Technology) — ещё одна «фича», которая может стать причиной невидимости из-под Windows на NTFS разделах файлов, которые создавались в Linux. Предположительно Linux не поддерживает SRT-кэширование (касается только SSD дисков), которое поддерживает Windows, а значит при создании из-под Linux-а файлов на SSD дисках с активным SRT-кэширование кэш не обновляется и после загрузки Windows файлов не обнаруживается. Предлагается отключить SRT-кэширование для SSD диска.
Тема использования NTFS в Linux является довольно актуальной, требует более подробного изучения и дополнительных экспериментов. О появлении новых багов, в ходе использования NTFS разделов в Linux, и, способов их решения, — будем дописывать в этой же статье…
I replaced a buggy Windows Vista installation with Ubuntu. All works fine except that the main HD where I had all my files are now inaccessible. Here is the error message I get:
Error mounting: mount exited with exit code 13: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read NTFS $Bitmap: Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details
Is it necessarily a hardware problem? If not, is there a way to repair the HD from Ubuntu?
muru
194k53 gold badges475 silver badges725 bronze badges
asked Oct 31, 2011 at 15:13
0
ntfsfix worked for me :
sudo ntfsfix /dev/sdb1
Provided in the ntfs-3g package.
jokerdino♦
41k24 gold badges132 silver badges201 bronze badges
answered Jun 27, 2012 at 21:32
Marc MMarc M
5411 gold badge4 silver badges2 bronze badges
2
chkdsk /R is a pretty important command when things get hairy with NTFS. Unfortunately I don’t know of a Linux tool that comes close to covering everything it does. In short, to run it, you’re going to need some sort of Windows recovery disk.
If you don’t have one to hand, there’s an ISO offered up in a thread on another set of support forums (see the first answer).
There are tools like ntfsfix (part of the ntfsprogs package) that can do surface checks on NTFS disks but they don’t tend to be able to fix the drives.
answered Oct 31, 2011 at 15:24
Oli♦Oli
290k117 gold badges680 silver badges837 bronze badges
2
NTFS is a closed source Microsoft file system, and you’ll need Windows to repair it, by running chkdsk /f, as suggested.
If the problem is hardware related, you’ll have to replace the hdd.
answered Oct 31, 2011 at 15:22
mikewhatevermikewhatever
32.3k10 gold badges87 silver badges99 bronze badges
1
i have encountered a similar situation once,then i kept the harddisk on windows,then a popup appeared asking to check the disk for errors.
if didn’t ask goto computer,right click on the drive and then click on properties,there would be a tab «tools»
select «check now»
this type of errors occur if you dont safely remove harddisks.
Braiam
67k31 gold badges177 silver badges265 bronze badges
answered Oct 31, 2011 at 16:23
saiki4116saiki4116
6492 gold badges8 silver badges22 bronze badges
Background:
So I was facing, more or less, the same issue. Around 12 files on the NTFS partition of my HD were inaccessible nor could they be deleted. Got to know about them through backintime’s error logs. Fired up my Window 7 on vmware, accessed that folder containing the files through shared folder and copied them to a new folder. But for some reason I was not able to delete those files (0 bytes) from Windows 7 either. No surprise there, the OS did not have low-level access to those files.
ntfsfix did not fix it, said nothing was wrong, and fsck said all’s cool with the the device. I could not chkdsk /R because the files were shared through network drive. And I didn’t have Window 7 installed on my physical machine.
Solution (steps for vmplayer, but could easily be followed for virtualbox):
- Add a new HD to your vm (had to start vmplayer as root)
- When prompted for the disk type choose physical disk
- Choose the correct device (for this reason vmplayer was started as root)
- Select «Use individual partitions»
- Select the partition containing the buggy files
- Finish adding
- Start the vm
For me Windows 7 detected the new partition and did a checkdisk on boot. It had a lot of (Index) cleaning to do. The buggy files were gone. And the problem solved.
answered Jun 6, 2015 at 21:13
Bleeding FingersBleeding Fingers
6602 gold badges10 silver badges27 bronze badges
1
I got this after newly fomratting an SD card as ntfs, all I had to do what umount it first.
sudo umount -l /dev/sdx1
then mount worked again
answered Jan 19, 2019 at 2:27
teknopaulteknopaul
1,98715 silver badges18 bronze badges
You must log in to answer this question.
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.
I just wanted to share my experience: on FreeBSD 10.3, I mounted my external hard drive with
$ sudo ntfs-3g /dev/da0s1 /media
Inside the hard drive, I did a mkdir to create a directory and then moved some files to it, of course with mv command. Finally I did the following command:
$ sudo sync
Then I mounted the hard drive on a Linux machine with kernel 4.4.0-78-generic. Now When I list the contents of the hard drive, the directory created on FreeBSD, named Jeff, is shown like below:
$ ls -lhrtci
ls: cannot access 'Jeff': Input/output error
total 20K
? d????????? ? ? ? ? ? Jeff
Also, when trying to remove the Jeff directory, I receive the following error message:
$ sudo rm -f -R Jeff
rm: cannot remove 'Jeff': Input/output error
I couldn’t get rid of Jeff directory on Linux machine, therefore I used the FreeBSD machine and re-mounted the hard drive on FreeBSD again. But the ls, cd and rm commands on FreeBSD generate the same Input/output error. Looks like there has been a bug on FreeBSD ntfs-3g package.
UPDATE
I moved all my data from external hard drive to a Linux machine, of course the corrupt file Jeff couldn’t be moved due to I/O error. Then I reformatted the external hard drive with both zeroing of the volume and bad sector checking like this:
$ sudo mkfs.ntfs /dev/sdb1
And then moved all the data back to the external volume. This way, I lost the corrupt file named Jeff, however, my external hard drive is clean of any I/O error.
NTFS: Input/output error
I was experimenting with HDF5 installation from a permanently mounted NTFS data partition so lots of deletion etc. Now part of the folder (containing some codes etc.) is not deleting and showing the above error. I have already NTFS-3g etc. but only have windows on virtualbox (from which also can not delete).
Thanks for all the help!
I am on CentOS 7.
asked Jun 28, 2016 at 4:30
4
This means your filesystem is damaged, Input/Output errors during filesystem access attempts generally mean hardware issues.
Type dmesg and check for log. it might be because of connection to it is failing, it’ll be noted there.
is it mounting it via ntfs or ntfs-3g ? As I recall, the legacy ntfs driver had no stable write support and was largely abandoned when it turned out ntfs-3g was significantly more stable and secure.
answered Jun 28, 2016 at 4:38
AReddyAReddy
3,1225 gold badges35 silver badges75 bronze badges
3
I meet the same problem,too.Some topics tell me that I should mount this disk on Win and rm it and clean the trash.I tried but failed.
But,I rm this files parent folder (on Linux rm -rf xxx ),and solved this problem.
U can try this way but remember to copy the import files or folders in parent folder.
answered Apr 14 at 6:21
Read about mount / umount (man pages)
In my case directory had be to unmount first, to be eligible to be deleted itself or its subdirectories/files
sudo umount -f /media/sami/OS\somewindows_folder
Then simply sudo rm -rf /media/sami/OS\somewindows_folder worked for me
answered Jul 21, 2022 at 13:53
SamiSami
1074 bronze badges
1
You must log in to answer this question.
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.