I never did see the point dragging a Windows ntfs formatted drive to a Linux party. Asking for trouble. Windows users find it difficult to “cut the chord”.
Well, maybe because most people use windows, at home & at work, Linux desktop has a market share of less than 1,5%.
Well, maybe because most people use windows, at home & at work, Linux desktop has a market share of less than 1,5%.
Indeed but using Linux based board points to Linux based file system. I’m amazed the amount of RPI users who look to Windows tools to solve Linux problems.
Maybe if you haven’t already done so list the full details of your setup and how you have it configured. It may help others. Pointless in users posting “not working for me” and not helping in the troubleshooting process.
Someone swapping their drives from NTFS to EXT4 would at least eliminate or confirm the issue is related to NTFS; if the problem goes away it's something in the in-kernel filesystem driver. If it occurs with EXT4 then it's something else.
I will probably set up another Pi this weekend with LE 11.0.1 on SSD and 8x4TB WD Red, if that works ok i'll hook up another 8x4TB WD Red. All disks will be NTFS.
I will probably set up another Pi this weekend with LE 11.0.1 on SSD and 8x4TB WD Red, if that works ok i'll hook up another 8x4TB WD Red. All disks will be NTFS.
Are you running a data centre 😂
I'm doing this just as a test.
Someone swapping their drives from NTFS to EXT4 would at least eliminate or confirm the issue is related to NTFS; if the problem goes away it's something in the in-kernel filesystem driver. If it occurs with EXT4 then it's something else.
i did this . . . all ok. drive appeared and was able to write to it. still need some help on getting old files on new drive so if someone can suggest something for post #36, i would appreciate it.
My test have been up for just over 24 hrs now with several on/off & reboots, right now im deleting & moving files to & from the 8 drives from other windows pc's trying to provoke any failures, no luck so far...
On my other Pi4 with 4x6TB i have occasional messages on boot as i boot from an ssd connected to one of the USB2-ports and LE probably assumes the bootdisk should be attached to a USB3-port but it just delays the boot for a few seconds, otherwise no problems.
16x4TB (+ SSD) mounted on a Pi4 4GB.
I was bulk renaming files from windows file explorer through samba on a raspberry pi 4 (LE 11.0.1), on a usb portable drive formatted ntfs. I've seen that some files are simply dissapear from the explorer, and not just the ones renamed.
With a two day work on this problem, I checked if the problem is not on my windows computer, set different versions of samba protocol, change power supply of the raspberry pi, installed different versions of LE, use different usb drives or sata with usb adapter, even try with the same drive connected to a router that have samba sharing, and finally formatted the usb drive to ext4.
What I can say, is that with LE 10.95.0 and above, the problem can be reproduced. I read above at mglae that LE11 changed the ntfs driver from user space ntfs-3g to in kernel ntfs3. For sure there is something wrong there.
The problem is not samba, because renaming of the files by ssh-ing the Rpi give the same problem, neither the drive or usb, because with the same drive formatted ext4 the problem disappear. Looks like some cache of the file names in the folder, not commited at the right time.
The drives seems to be "recoverable" by chkdsk /f, it said something on step 3 that some files are not indexed and will be reconnected with the folder that belongs.
I advise those that said they have no problems, to try to rename 20-30 files in a folder on a session and you might find this issue. If you just play the files from the drive you'll have no problem, I'm not sure that when writing files you can lose data, but for sure when renaming there is a big problem.
All my NTFS-disks still mounts and works flawless.
I can confirm what sorinv reported. Had the exact same issue. Bulk renaming files on ntfs filesystem causes the folder to become corrupt. First symptom will be files or folders disappearing. Checking the disk on windows does fix the problem.
I also came to the same conclusion that it has something to do with the switch to the new ntfs3 kernel driver after reading all these reports on the forums with ntfs drive corruptions.
I experienced the same problem as sorinv and karagian a few times, with two different external HDDs on my Raspberry Pi 4. I had to run everytime chkdsk on Windows to fix them. No other solution than to move those HDDs to my NAS as a temporary solution.
It would be nice to fix this issue, I never had this problem with LibreELEC 10. Using a Linux filsystem on my external HDDs is unfortunately not an option for me for a few particular reasons.
Hello,
I use Pi 4 8GB Libreelec 10.0.04 with 2 USB drive NTFS and not problem the system see the 2 HD
I change the SD mem with librelec to 11.0.3 and i do not see any more the 2 hd
I put back the SD mem 10.0.04 and i see the 2 hd
Any idee ?
You need to do a chkdsk under windows. The ntfs drivers are different between LE10/11 and some would say “more pedantic”
You need to do a chkdsk under windows. The ntfs drivers are different between LE10/11 and some would say “more pedantic”
Yes, this solves the problem for the moment but as soon as you are renaming files or folders on the HDD, the folder to become corrupt again and the HDD is not seen anymore by Pi. This is a problem on the LE11 side which should be fixed. As you said, this issue is not present on LE10.
Hi racko - not exactly - we use the standard upstream kernel - which ntfs3 is part of. If you can pinpoint a how to get the failure - then log it with the upstream ntfs3 filesystem kernel - once a fix is in upstream - the LE will pick it up.
Note: I have production ntfs3 and exfat file systems and have not been able to reproduce what is reported. (I have had other ntfs3 issues which I have worked with the kernel and fs developers - but not the “unable to mount” - I do write to this disk.)
Note2: ntfs3 in kernel 6.2-6.5 has had a number patches (some are backported to 6.1 which is used be LE11.) these updated kernels are in the LE12 nightlies - it would be best to test the “reproducible issue” on the current 6.5 kernel before reporting upstream.
