NI Linux Real-Time Discussions

Showing results for 
Search instead for 
Did you mean: 

NTFS Partial Support

Go to solution

So I know documentation-wise NTFS is not supported on the Linux-RT controller.  But I had an NTFS USB drive so I plugged it in and started logging to it just fine so I figured it was supported since I didn't read the documentation first.  But once the log file became greater than 4GB the file generated ended up not being valid.  I happened to be logging to TDMS and I'm not sure how it became bad but it did. 


So is there plans to support NTFS?  Is there a way to disable NTFS if it doesn't fully work?  For me the only real requirement is that I have a file system that is on this drive that Linux RT can log to, and Windows can recognize.  It seems the only file system that meets that need is FAT32, and that means files can't be over 4GB.  Oh and the 128GB drive limitation isn't a big deal yet, but the largest USB drive I have is 128GB, any larger and we'll have more issues.


cDAQ-9136 LabVIEW 2018 32-bit.

0 Kudos
Message 1 of 12

I didn't try to recreate your error, but I do have a potential solution.


From what I have found online, NTFS is partially supported in the Linux kernel.  The ntfs-3g driver is a more full featured driver for NTFS on Linux or Mac.  You can install it by typing 

opkg install ntfs-3g


Then, Linux should automatically mount your NTFS drive with the new driver.  You can check it by running 

mount -l




cat /proc/mounts

It should now have a type of "fuseblk" instead of "ntfs".  (Note: if you are not sure which device you are looking for, running "lsblk" can be helpful.)


mount -lmount -l


I am using a 128GB SD card in a cRIO-9039 (which has NIRIO18.0 installed with 6.0.0f1 firmware).  I have formatted the SD card as NTFS.  I created a 6.5 GB text file for testing, without any problems.  I then used the SD card on a Windows 7 machine and was able to read it without any corruption issues.


A few recommendations:

  • I haven't worked with TDMS files a lot, but I highly advise keeping your log files less than 100MB (I typically use 20MB).  Many programs can't open large files.  Smaller files have a lower risk of loosing all of your data if you do get a corrupt file.  In an embedded environment, smaller files also make it easy to write code to throw away the oldest data if your disk space gets full.
  • I would avoid FAT32 as it is notorious for corruption issues.  I recommend either putting NTFS drivers on Linux or EXT3/4 drivers on Windows.  You might also try exFAT.


Best of luck.

Jonathan Reynolds
Message 2 of 12

Wow absolutely fantastic, I don't know how I can only give you one kudo.  So yes after connecting to the internet and doing and opkg update and then installing the package you mentioned, my USB drive that is NTFS appears to work properly.  Just for reference here is the VI I use to generate a 4.6GB TDMS file.

Create Large TDMS_BD.pngAfter I unplugged my drive, and plugged it into Windows, the normal TDMS Open and Close worked without any error, and the TDMS Viewer could read all 4,800,000,000 values (just not at once for obvious reasons).


Can NI chime in on how likely this will work in the future?  I'm not asking NI to say "This is fully supported." I'm just looking for someone at NI with technical knowledge to say "I can't think of a reason this will break."  Or "I wouldn't trust this to work".


As for the other file system options.  Formatting my drive to EXT2 and EXT3 required Ext2Fsd.  I used the command line call to mke2fs.exe and it appeared in Windows and could be written to.  I plugged it into my controller and the file was there and could be read.  But trying to write to it resulted in Error 6 Generic file I/O error, in LabVIEW on the TDMS Open.  This was for both EXT2 and EXT3.  exFAT didn't work for me on my controller, the drive wasn't enumerated.


Also I'd like to mention one other positive side effect of your package installation suggestion.  Recently I replied to a thread where users notice that drives that are taken out of the controller, and plugged into Windows, get a dialog from Windows saying the drive might be corrupt and needs to be scanned.  Most of the time there is no issue but once in a while issues are found.  This corruption dialog is seen even if all references are closed and cleaned up.  Well I noticed that after your package install, my NTFS drives no longer say they are corrupt when plugged into Windows.  If I format my drive back to FAT32, run the same VI (the one above but with only 2000 cycles) then unplug, and plug back into Windows that familiar corrupt dialog is there.  I'm guessing there is a problem with the FAT32 file system, and without the installed packages you mentioned, NTFS was treated as FAT32.

0 Kudos
Message 3 of 12
Accepted by topic author Hooovahh

Hi Hooovahh,


We do not have any plans to officially support NTFS in the future.


It sounds like the suggestion to use ntfs-3g will meet your needs. I am in the category of "I can't think of a reason for this to break". We added support for FUSE in the kernel in 2016 which is what allows ntfs-3g to be installed and used. BRadM had a comment about this when discussing exFAT here.





Message 4 of 12


Are you able to quickly detail the steps involved in "doing and opkg update and then installing the package you mentioned".

I cannot access the internet directly from my cRIO because of company policy but I thought I could manually copy the files down and do it that way.

My problem is that having found what looks like the correct files I don't know which of them to use.













0 Kudos
Message 5 of 12

Hi idc12,


I believe the ntfs-3g 2017.3.23-r0 will be the top-level package. However there will be a number of dependencies that you will need. 


I ran a quick opkg install for ntfs-3g to see which packages are dependencies for a cRIO that had 2018. I would expect similar dependencies in 2017. Hopefully this list helps. 


opkg install ntfs-3g
Installing libntfs-3g88 (2017.3.23) on root
Installing libfuse2 (2.9.4) on root
Removing any system startup links for fuse ...
Installing fuse-utils (2.9.4) on root
Installing kernel-image-bzimage-4.9.47-rt37 (4.9+git6+9fd7fe9f26) on root
Installing libulockmgr1 (2.9.4) on root
Installing ntfs-3g (2017.3.23) on root
Installing kernel-image-4.9.47-rt37 (4.9+git6+9fd7fe9f26) on root
Installing kernel-4.9.47-rt37 (4.9+git6+9fd7fe9f26) on root
Installing kernel-module-fuse-4.9.47-rt37 (4.9+git6+9fd7fe9f26) on root

0 Kudos
Message 6 of 12

So for me I have a cDAQ-9136 which is an x86 based Linux RT platform.  I went to the package repository on a computer with the internet which is here:


I then went into the newest which at the moment is 2018.5, and then x64 (since my controller is Intel based and not ARM), and then the core2-64 folder.


From here I searched for the 3 packages I found I needed.  libntfs-3g, ntfs-3g, and libfuse2.


Download those 3 packages and save them to a FAT32 USB drive and plug it into the controller.


Then SSH into the controller using Putty.  You may need to enable SSH in MAX and reboot the controller.  Once logged in go to the folder on the USB drive where the packages are installed using the change directory command (cd).  The USB drive will be in the media folder on the root.  Once there execute the following 3 commands:



opkg install libfuse2_2.9.4-r0.287_core2-64.ipk
opkg install libntfs-3g88_2017.3.23-r0.15_core2-64.ipk
opkg install ntfs-3g_2017.3.23-r0.15_core2-64.ipk

Obviously the file name needs to be replace with the actual name of your files if there are newer ones named differently.  Now reboot your controller (optionally turn off SSH if you don't want it first) and now plugging in NTFS formatted drives should show up in the media folder just like the FAT32 ones.


EDIT: I see the answer by tic.not.tock has more packages listed.  It is possible that my controller already had some of these but so far I've been successful with just the 3 I listed.  It might be a good idea to use all the ones they listed.

Message 7 of 12

Thanks Hooovahh and tic.not.tock for the responses. I would not have known which packages to pick.

I downloaded all the files that tic.not.tock suggested but then experimented to see if it would work with just the three files suggested by Hooovahh. And yes it does!

Really appreciate the support.Thanks again.

Message 8 of 12

Perhaps a simple question, but we're looking to access a networked NTFS folder from our cRIO. Does this mean we need the locally installed NTFS driver support mentioned in this thread?


Also, the networked location requires a Windows account + password to gain access. On our laptops we can map a network drive letter to the folder URI and provide Windows with the user account details - simple. On the cRIO we want to programmatically push files up to the same NTFS location, is this possible? If so, how do we go about it? 

Thoric (CLA, CLED, CTD and LabVIEW Champion)

0 Kudos
Message 9 of 12

@Thoric, Samba is the established tool for communicating between Linux and Windows file systems. It can be installed through OPKG. 

Message 10 of 12