The NTFS hotplug and automount support is highly distribution specific regarding the used technologies and the preferred mount configuration. This is what should happen on a higher level:

1. Detect storage hardware.
2. Detect NTFS on the hardware.
3. Start the NTFS-3G driver with the user and distribution preferred mount options.
4. Mount the NTFS volume.

The NTFS-3G file system developers are working only on item 4. This is a huge and very complex task itself. The distribution and other developers are working on item 1, 2, and 3, which solutions are vastly different depending on all kind of preferences.

Solution: If you would like to have this feature in your distribution then please ask your distribution vendor or developers to support this feature.

Workarounds: Either of the following could help.

• Creating a symbolic link, as shown below, is reported to solve automount on many distributions. ln -s /sbin/mount.ntfs-3g /sbin/mount.ntfs
• If you use KDE and get the “TODO: have to rethink extra options” error message then open `media:/’ in Konqueror, choose `Storage Media’, right click the removable device, select‘Properties’, select the ‘Mounting’ tab then unselect the ‘Mount as user’ option.
• There is a great utility, called ntfs-config, which is reported to work fine on at least Ubuntu.

Status: Not NTFS-3G problem

If the top directory is completely empty then it’s very probably that the NTFS volume is not mounted. If only some files are missing then please upgrade to at least NTFS-3G 2009.1.1 which has full, built-in Unicode UTF-8 conversion support.

If you use Mac OS X or FreeBSD and have at least one very long filename with national characters and the filename length translates into more than 255 UTF-8 bytes (higher chance with Korean and Greek languages) then Mac OS X and FreeBSD will not show any files in the directory.

If you are double-booting with Windows 8, you may have enabled its fast restarting feature. This may cause Windows 8 to ignore changes done by another OS on any internal partition. A safe way to avoid loss of data is to disable the fast restarting by issuing as a Windows Administrator the command :

powercfg /h off

If your computer has a SSD plugged in, it might be used by Windows as a cache controlled either by the hardware (“Intel Fast Response Technology”) or by software (“Expresscache”, “ReadyCache”, etc.). This feature is generally not compatible with both Windows and Linux and you may have to disable it.

Why are some filenames garbled? or
What does “Invalid or incomplete multibyte or wide character” mean?

Please make sure your terminal, terminal emulator or file manager is Unicode capable and set it to UTF-8 handling.

No open source NTFS checker is known to have been developed, so there is no point in requesting such a check.

Until such a checker is available, do not enable the check at boot time and set the last (sixth) field of NTFS entries in /etc/fstab to zero. Use a proprietary checker, such as chkdsk on Windows, when a check or fix is wanted, typically after an unsafe unmount (power disruption, etc.).

When Windows 8 (or subsequent versions) is restarted using its fast restarting feature, part of the metadata of all mounted partitions on internal disks are restored to the state they were at the previous closing down. As a consequence, changes made on Linux may be lost. This can happen on any NTFS partition on an internal disk when leaving Windows by selecting “Shut down” or “Hibernate”. Leaving Windows by selecting “Restart” is apparently safe.

To avoid any loss of data, be sure the fast restarting of Windows is disabled. This can be achieved by issuing as an administrator the command :
powercfg /h off

Both the MBR and the partition table are outside of the NTFS disk area. This means that those disk areas are not visible and not accessible to the driver. Moreover NTFS-3G doesn’t need either information to function. It doesn’t read, write or modify any of them. In fact, the operating system doesn’t even let NTFS-3G to access those disk areas.The MBR and the partition table are typically modified (corrupted) by boot managers, partitioners, security software, recovery software, viruses and other malwares, or some hardware fault.

The message means that you have an old and unsafe Linux kernel which is prone to data loss.

Solution: Please ask your distribution developers to fix the Linux kernel problem. The Linux kernel must be upgraded either to at least version 2.6.20, or the FUSE kernel driver must be upgraded to a safe version which is also included in the FUSE package for Linux kernel version 2.6.9 and later.

Status: Not NTFS-3G problem.

By default files on NTFS are owned by root with full access to everyone. To get standard per-file protection you should mount with the “permissions” option. Moreover, if you want the permissions to be interoperable with a specific Windows configuration, you have to map the users.

Why can’t unprivileged users mount block devices? or

Why do I get “fusermount: option blkdev is privileged” error?

Unprivileged block device mounts work only if all the below requirements are met:

1. ntfs-3g is compiled with integrated FUSE support
2. the ntfs-3g binary is at least version 1.2506
3. the ntfs-3g binary is set to setuid-root
4. the user has access right to the volume
5. the user has access right to the mount point

The root user can make an ntfs-3g binary setuid-root as shown below
chown root $(which ntfs-3g)   chmod 4755 $(which ntfs-3g)
In such case the driver will also be able

• to fix common FUSE kernel module loading problems
• to create the required but sometimes incorrectly removed or missing FUSE device file

Please note that using setuid-root can result unforeseen privilege escalation and its usage is discouraged. Only the absolutely trusted users must be granted such access. Below is an example how this can be done for users in the ntfsuser group to be able to mount any NTFS volume if they have also the needed volume access rights.
addgroup ntfsuser   chown root:ntfsuser $(which ntfs-3g)   chmod 4750 $(which ntfs-3g)   usermod -aG ntfsuser allowed-user
The setuid-root ntfs-3g driver applies the principle of least privilege during its lifetime as a safety measure.

The ‘mount’ command doesn’t invoke the ntfs-3g binary with the needed privilege after it has checked and approved the user is entitled to mount a given device on a specified mount point, hereby the user can’t open the device he got the approval in /etc/fstab. This is a problem in the ‘mount’ utility.

Solution: Use at least NTFS-3G 1.2506 with setuid-root set and make sure the user has access rights to the volume and mount point.

NTFS supports several filename namespaces at the same time: DOS, Win32 and POSIX. While the NTFS-3G driver handles all of them, it always creates new files in the POSIX namespace for maximum portability and interoperability reasons. This means that filenames are case sensitive and all characters are allowed except ‘/’ and ‘\0’.

As Windows uses more restrictive naming rules, you can prevent ntfs-3g from creating new files which do not meet Windows file naming rules by using the option windows_names.

When mounting with the lowntfs-3g variant, you can get case insensitive access to files by using the option ignore_case. Doing so, all files will be shown with lower case letters in directory listings. In some situations, a directory busy error may occur, you can fix it on recent kernels by applying a patch to the fuse kernel module.

Alternately, to get case insensitivity handling and/or restriction on special characters, you may export the NTFS volume via Samba which supports this functionality the same way as it does for other POSIX file systems. Another solution for case insensitivity support is using ciopfs which mounts a normal directory on a regular file system in case insensitive fashion.

Status: Not NTFS-3G problem.

If the locale environment is not setup correctly before mount then glibc can’t convert some filenames, so they are not visible and the directory is indeed not empty.

Solution: Please see here.

Status: Not NTFS-3G problem.

The latest driver has solved this issue, please upgrade

The latest driver has solved this issue, please upgrade

NTFS uses a “reparse point” feature to trigger advanced features. The most common ones are junctions and symlinks which ntfs-3g translates to Posix style symlinks. A few other reparse point types can be interpreted by ntfs-3g provided a specific plugin is installed. Currently these are files deduplicated by Windows Server 2012 and compressed system files used by Windows 10, which can both be read since ntfs-3g-2016.2.22AR.1

When ntfs-3g provides no support for some reparse point type, it is displayed as a symlink to “unsupported reparse point”.

NTFS supports built-in, transparent compression and encryption of files and directories on the file system level. Reading and writing transparently compressed files are fully supported, but reading or writing encrypted files are not supported at the moment. Please note that compressed files, like .zip, .gz, .rar, etc, can be freely modified because they are compressed on the file, not on the file system level.

Workaround: Decrypt the needed files on Windows.

In most cases it does, except for the following scenarios:

• In some desktop configurations files are not deleted for real but moved into a ‘Trash’ or ‘.Trash-username’ directory in the root of the partition. When these directories are emptied then the disk space is reclaimed.
• By design, Linux and Unixes free the disk space of the deleted files permanently only if no software keeps them open anymore.
• NTFS is able to store small files and directories in fixed size (1 kB) MFT records (inodes). When such files are deleted then the MFT records are marked free for reuse or for undelete, and no space can be freed.

Status: Not NTFS-3G problem.

Moving a file to trash is only possible if the trash directory is owned by the current user. This implies that ownership of files has been enabled, either by forcing ownership to the current user or by using a generic ownership and permissions mode.

This generally happens when permission options are partially set and the uid of the current owner is not defined in the mount command. On Linux, only the owner is allowed to set the modification time of a file.

Workaround : either set the uid option, or remove permission related options, or else use the permissions option.

Yes, this is possible and some distributions do it. For instance WUBI, the Ubuntu Installer for Windows.

Yes, this is possible if it’s properly setup. Below is the example how to create, initialize and turn on a 2 GB swap file safely, deadlock free:
dd if=/dev/zero of=swapfile bs=1M count=2000 mkswap swapfile swapon swapfile
You must turn off the swap file with ‘swapoff’ before you would be able to unmount NTFS. Please also note that other solutions, for example using swap on a loop device, are not safe and can cause deadlock!

Yes. For example by using LILO, the same way as with any other filesystem: copy the Linux boot files to NTFS, configure /etc/lilo.conf then run lilo.

Yes. There are two solutions depending on the Linux kernel version:

1. Obsolete: Use the FUSE kernel module from the FUSE 2.7.4 software package and please read the FUSE README.NFS file.
2. Preferred: Use the FUSE kernel module included in the Linux 2.6.27 and later kernels.

Yes. You need to use NTFS-3G 1.2506 or later and the FUSE kernel module from the FUSE 2.5.3 package. Please see more details in the FUSE README file.

User mounted partitions, e.g. when using the ‘user’ or ‘users’ mount options in the /etc/fstab file, are done with the ‘noexec’ mount option by default for security reasons. This means that memory mapping (mmap) files for execution will be denied.Another reason can be the lack of kernel support for shared writable mmap which was added to Linux kernel 2.6.26.

Solution: Add the ‘exec’ mount option to the end of the mount options. It’s important that the option to be the last one, otherwise other mount option can over judge its effect. However please also note that Wine was not designed to run arbitrary applications directly from a Windows partition. To do so, one must install the Windows application via Wine onto the Windows partition first.

This is a known bug in Firefox which affects FAT32 and NTFS partitions;

Status: Not NTFS-3G problem. The latest Firefox releases should fix this problem.

VMware tries to use shared writable mmap for paging files but it can’t detect that it’s not always supported.

Workaround: Set “mainMem.useNamedFile=FALSE” in the .vmx file. It will disable paging files and VMware will work fine, often with much better performance.

Status: The VMware bug has been fixed in all hosted products (Workstation, Fusion, Player, …) released after Jan 30th 2008. Alternatively use Linux kernel 2.6.26 or later.

VMware uses shared writable mmap for paging files but it doesn’t detect that this method is very inefficient.

Workaround: Set “mainMem.useNamedFile=FALSE” in the .vmx file and VMware will perform much better. Please also see this VMware Knowledge Base article which addresses troubleshooting the most common hosted disk I/O performance problems.

Since 2011, ntfsprogs is bundled with NTFS-3G and you have to use the same version for both.

Be careful with older ntfsprogs-2.0.0 because it had some reliability issues.

By default they use the possible smallest, 512 or 1024 bytes, write block size which results eight or four times more work to do for FUSE, kernel and NTFS-3G. Since they are not optimized yet, the performance will suffer almost one fold in the worst case. Use at least 4 kB block size and the write speed will improve dramatically. Encfs is hit by a Linux kernel deficiency. Since it uses a non-page size internal header thus writes are not page aligned and the kernel will split them which halves encfs write performance.

Amarok performance may depend on the codec. Updating FLAC files are known to be slow because the software uses very small buffer size.

Normally the I/O performance of NTFS-3G and the other file systems are very comparable. However there can be several reasons for real or believed inadequate performance in certain scenarios. All software and hardware components must work flawlessly together to get the best possible performance and if just one of them fails in some way then the overall system performance can suffer noticeably. If the NTFS-3G driver uses close to 100% CPU time then it’s usually a driver issue, though not always. Please see the details and explanation here.

If the NTFS-3G driver doesn’t use close to 100% CPU time then the problem is typically not directly related to and not caused by the NTFS-3G driver. The most likely explanations are

• USB is running in Low-Speed (0.1875 MB/sec) or Full-Speed (maximum 1.5 MB/sec) mode instead of High-Speed mode (maximum 60 MB/sec). The USB performance is reported to be exceptionally bad on Mac OS X. Many users claimed that Firewire is much faster. Please note that NTFS-3G is independent of the bus type (USB, Firewire, SATA, PATA, etc), and the overall performance can depend on the bus type and its driver quality significantly.
• There is a slow USB device attached to one of the ports of the USB hub to which the disk is attached.
• Using the sync mount option which forces extra writes to device (do not use sync unless you have a good reason.)
• Unaligned partition on a 4096 byte sector size hard driver like Western Digital Caviar Green.
• Solid State Disks (SSD), USB and other flash drives can have many reasons for low performance:
  • The write performance of some Intel and other SSDs can dramatically fall with use. Low level formatting may help temporarily.
  • The write performance of some Intel and other SSDs can significantly drop when the disk endurance management feature automatic turns on to enable the device to have, at a minimum, five year useful life. The typical limit is 20 GB writes per day.
  • The random write and parallel performance of many flash, USB and SSD hardware can be as low as 0.02 MB/s.
  • Defragmentation causes even worse performance and shorten the life of these drives.
  • Partitions not aligned to flash block boundaries.
  • Heavy temporary file and small file activity.
  • Heavy page (swap) file activity.
• DMA is turned off. Check the BIOS and use hdpram, sdparm, blktool on Linux.
• Using an embedded device or a very fast I/O subsystem (100+ MB/s, RAID).
• Hardware or bad sector errors. Check the log files under /var/log.
• Some external USB drivers may power down during write activity which can cause big delays for I/O operations.
• Not using the performance improved driver on Mac OS X.
• A software ignores errors or doesn’t have correct error handling. In such cases the problem often becomes visible in NTFS-3G, not in the faulty software.
• Some Nautilus releases have a performance bug with files larger than around 20 MB. The problem goes away if command line tools or alternative file managers, like Thunar or Konqueror, are used.
• Not using at least NTFS-3G Version 2009.3.8.

Status: An optimized, high-performance version, primarily for consumer electronics devices, is available commercially.

The most common explanations are

• Not using at least NTFS-3G Version 2009.3.8.
• Writing multi-GB files on a highly internally fragmented volume.
• Some software are using the most inefficient block sizes by default.
• A highly sparse file is being regularly written or updated.
• You are using transparent compression (you may disable compression alltogether by using the option nocompression or disable compression per directory)
• Some software indeed do intensive file operations sometimes (Beagle, Amarok collectionscanner, updatedb, Spotlight, etc).
• The CPU usage is not directly visible in case of kernel file system drivers but this is not true for user space drivers. That is, they are in the process list unlike the kernel drivers. Higher CPU usage is normal and expected in some scenarios. This is true for most file systems, not only NTFS-3G.
• The NTFS block size (cluster size) is smaller than 4096 bytes. This often happens, for instance, if FAT32 was converted to NTFS. The driver always logs this information for block devices. You can search for the value of the ‘blksize’ in the system log files under the /var/logs directory. Typically this information can be found in the ‘messages’ or ‘daemon.log’ log file, depending on your operating system.
• Using an embedded device or a very fast I/O subsystem (100+ MB/s, RAID).
• VMware is not using “mainMem.useNamedFile=FALSE” in the .vmx file.

Workaround: using the mount option “big_writes” generally reduces the CPU usage, provided the software requesting the writes supports big blocks.

Status: An optimized, high-performance version, primarily for consumer electronics devices, is available commercially.

Either you don’t use at least NTFS-3G Version 2009.3.8 or your disk space is highly fragmented in a close to full cluster allocation zone, or a highly sparse file is being updated (e.g. a bittorent file, VMware image file).

Workaround: Use a software which can compact the disk space (e.g. the free, open source ntfsresize: shrink then enlarge after making a backup). Please note, file level defragmentation, what the built-in Windows defragmenter is only capable, does not help usually.

Solution: Please the status information here.

Chkdsk sometimes optimizes the NTFS layout and later finds its own bugs (for instance when an index root attribute is moved from extent MFT record to the base one). This is not a problem with NTFS-3G.

Workaround: No need, this is a CHKDSK bug.

Status: The latest NTFS-3G optimized NTFS index metadata layout.

The typical detailed error messages are the following (XXX are numbers): Cleaning up XXX unused index entries from index $SII of file 0x9. Cleaning up XXX unused index entries from index $SDH of file 0x9. Cleaning up XXX unused security descriptors. These messages are part of an optimization process which is completely independent of NTFS-3G. Nothing to worry about them.

Workaround: No need.

Status: Not NTFS-3G problem.

These messages are part of the CHKDSK maintenance process and are independent of NTFS-3G. Nothing to worry about them.

Workaround: No need.

Status: Not NTFS-3G problem.

Newer versions of Windows use the latest character table as defined by the Unicode consortium, and CHKDSK checks against the table defined on the system on which it is running. As a consequence a mismatch on the uppercase table is found when the table does not have the same version as the current system. This may have some visible consequence when listing files which have some very rare characters in their names.

Currently, mkntfs creates the same uppercase file as was defined by Windows Vista.

Workaround: No need.

It has been.