NTFS Write Support on OSX Lion With NTFS-3G - Im

17/04/12 NTFS write support on OSX Lion with NTFS‑3G ‑ im.getting(this);

1/13fernandoff.posterous.com/ntfs‑write‑support‑on‑osx‑lion‑with‑ntfs‑3g‑f

IM.GETTING(THIS);

8 Aug 2011

53 Responses

30634 views

fuse

fuse4x

lion

macfuse

ntfs3g

osx

NTFS WRITESUPPORT ON

OSX LION WITHNTFS-3G

EditEdit DeleteDelete TagsTags AutopostAutopost

Update 2: Check out this post for a prebuilt binary installer for NTFS3G that can be used withthe Fuse4X solution detailed below (i.e., if you're not willing to go through all the steps ofinstalling XCode, MacPorts, etc. that's detailed below, you can just install Fuse4X binary (fromhere) and the NTFS3G installer I'm providing on the post linked above).

Update: Thanks to some suggestions from Marcos on the comments below, I kicked myselfback into trying to solve the mount problem with uids/gids on fuse4x / ntfs3g. I've updated thescript below, it now improves things somewhat. It's still not perfect it'll work fine if your userlogs in automatically, otherwise, it'll try to wait for 20 seconds (adjustable on the TIMEOUTvariable) until the user session is active and it picks up the user id from the session started, andif that too fails, it falls back to the old behavior (fixed uids/gids). There's also an alternativesolution for that provided by Marcos on the comments area of his post, check it out (inportuguese Google Translate is your friend).

It's a well known fact that OSX had NTFS read support for a long time, but write support could

only be easily enabled either by:

Buying thirdparty solutions, from Paragon or Tuxera. The latter is actually a productfied

version of the opensource solution mentioned below;

Enabling manually on the native driver by messing around with system files. That option is

known to be very unstable and can potentially corrupt your NTFS partition, so it's strongly

NOT recommended. Also, this worked only on early versions of Snow Leopard apparently

Apple disabled this "feature" later (though it seems nobody tried it again with Lion). It's

obvious that with this move Apple was clearly saying that the driver is not reliable for write

support and should not be used as such.

A port of MacFuse and NTFS3G provided by Tuxera. The official versions are old and don't

work at all on 64bit kernels (i.e. Lion).

On the last case, there are unofficial builds of MacFuse that work on 64bit kernels, but not

without a few issues this post will outline the steps on getting this unofficial version of MacFuse

working along with the older version of NTFS3G (the version that was still free, before Tuxera

went completely commercial with it). Also, while most of the procedures detailed here were

tested in my OSX Lion installation, it should in theory work on Snow Leopard too, I just have no

way to confirm this at this time. Feedback is welcome on that.

I'm also going to outline the steps on getting to work a solution based purely on MacPorts, a

package manager for OSX that works by downloading the source code to a package, compiling it

on your machine, and installing it. That solution works fine for the most part, with only a small

caveat, that may or may not affect you depending on how you work with your Mac. In my opinion,

though, this solution is also more robust and (hopefully, once the small kinks get worked out)

bugfree solution and easier to maintain and update (thanks to MacPorts) on the long term, and I

hope it gets noticed by the developers involved because of that. I'm personally using this solution

right now, but due to it being somewhat more cumbersome to setup, it probably should be taken

as geared towards power users if you want something a bit easier to setup, you're probably

better off with the MacFuse + Tuxera's NTFS3G solution presented below.

Before we start: While the steps I outline here are more or less foolproof, you'll be in fact messing

around with a little bit of the inner workings of OSX. In theory, what you'll do shouldn't

completely wreck your system (at worst, you'll no longer be able to mount your NTFS partitions),

but the standard disclaimers apply: Any problems caused by what you'll do henceforth are

entirely YOUR responsibility, not mine. If your system stops working correctly, if your NTFS

partition gets corrupted, if your system blows up to pieces, etc. it's YOUR fault. Also, since the

procedures outlined here modifies system files and needs you to work mostly on the Terminal,

some experience with working with the terminal and the bash shell is, while not required, advised,

specially in the case you bump into problems. If you're not confortable with that and absolutely

need NTFS write support, do me and yourself a favor, and buy one of the paid solutions

mentioned above.

I'll start with the easier solution (for now), since I suppose this will be the one that most people

will end up going with as it requires less presetup procedures.

And before you start either of the procedures below, umount your NTFS volume first (rightclick / ctrl+click the volume icon on the desktop and select "Eject").



MacFuse + NTFS3G (older opensource release from Tuxera)

Get the latest opensource version of NTFS3G by Tuxera from here and only here don't get

anything newer than that, that would be Tuxera's commercial version, and it'll require you to buy

it after the 15day trial.

For a 64bit supported MacFuse, there are two options: this (use the link for the file macfusecore10.52.1.9.zip) or this. The former is the last opensource version of MacFuse fromTuxera patched by an independent developer to work on 64bit. The latter is a patched version of

a newer version (2.1.15) meant for Wuala's app although, for our purposes, it should work with

NTFS3G just as well. There are no notable or even documented differences between the older

and the newer, so the choice is up to you during testing, I've used both without problems.

Unpack the zip file for MacFuse and doubleclick the pkg file to install. Next, install NTFS3G

from the link above. Once it's done, you'll be requested to restart do so.

Once it comes back up, a few moments after the desktop comes up, you'll be greeted by something

like this:

Download full size (43 KB)

Yeah, that's the issue I mentioned early on. It's not an usability issue, i.e. the partition will be

mounted readwrite correctly (even though it says on the dialog it wasn't), and you'll be able work

with it without any problems or corruption issues, as far as I'm aware. The issue is really just that

nagging dialog that pops up every time you mount a NTFS volume, including on boot in this case,

if you've got a Windows install on your Mac like me. In short, everything works fine despite that

dialog.

The problem seems to stem from the binary "fuse_wait" from NTFS3G that's run as a final part

of the mounting procedure for some reason it can't detect that ntfs3g mounted the volume and

stays on a hopeless loop trying to detect this condition until it gives up after 15 seconds. So my

workaround involves replacing the fuse_wait binary with a script that does more or less the same

thing, but actually detecting (sort of) the mount operation and not timing out.

Open a Terminal window. First of all, make a backup of the original binary:

sudo mv /usr/local/bin/fuse_wait /usr/local/bin/fuse_wait.orig

Then create the file that'll hold our script and setup the proper permissions for it:

sudo touch /usr/local/bin/fuse_waitsudo chmod 0755 /usr/local/bin/fuse_waitsudo chown 0:0 /usr/local/bin/fuse_wait

Now, let's edit the file so we can paste our script into it:

sudo nano /usr/local/bin/fuse_wait

Here's the script, paste it into the editor:

#!/bin/bash

MNTPOINT=$1shiftTIMEOUT=$1shiftMNTCMD=$1shift

$MNTCMD "$@" &> /var/log/ntfsmnt.logMNTCMD_RETVAL=$?

if [ $MNTCMD_RETVAL -eq 0 ]; then until [ /sbin/mount | /usr/bin/grep -c "$MNTPOINT" -ge 1 ] || [ $TIMEOUT -eq 0 ] do sleep 1 let TIMEOUT-- done



fi

[ $TIMEOUT -eq 0 ] && RETVAL=1 || RETVAL=$MNTCMD_RETVAL

exit $RETVAL;

Press CTRL+X, say Yes to save the file, and press Enter to accept the file name.

Next, we'll edit another file. Still on the Terminal, type:

sudo nano /System/Library/Filesystems/ntfs-3g.fs/ntfs-3g.util

We're on nano again. Find the line that looks like this:

DEFAULT_NTFS_MOUNT_OPTIONS="auto_xattr"

Add some options to the end so it looks like this:

DEFAULT_NTFS_MOUNT_OPTIONS="auto_xattr,noatime,auto_cache"

Again, CTRL+X, say Y to save and press Enter.

That's it. Reboot, and you should no longer get the error dialog the next time you mount your

NTFS partition. If you have any problems, look into the file /var/log/ntfsmnt.log, it should

contain some description of any problems found during mount, but I hadn't any so far.

Fuse4x + NTFS3G from MacPorts

Fuse4x is a fork of MacFuse intended to bring the old and abandoned MacFuse codebase up to

date, and also improve compatibility with the Fuse upstream project, while maintaining

compatibility with existing filesystems for MacFuse.

To get it working, you'll need to install Xcode on your system if you're on Lion, Xcode's a free

download from the App Store. Since MacPorts works by compiling every package you ask to

install, there's no way to escape that. You may uninstall Xcode after you install the packages you

need, but then you'll lose the ability to easily upgrade packages (using port upgrade) once new

versions are released you'll need to install Xcode again for that.

Once you get Xcode installed, get MacPorts and install it.

Done? Ok, after you get all this installed, open a terminal window and type:

javac

That should pop up an Apple Update window asking if you'd like to install a Java update and some

such. Do that. That's really just a small precaution if you don't do that now, that window will

popup during the build process on MacPorts in my case, since I wasn't prepared for it, the Java

update kept downloading on the background while MacPorts was still building the dependencies

for Fuse4x and NTFS3G. The build process completed sucessfully despite that though, so Java is

probably not a required dependency, but it doesn't hurt to be careful, so I recommend to get this

missing Java dependency installed first so your build process go without surprises.

Now that you have the Java dependency installed, we can get to the real meat. First, if you haven't

done that yet, update your MacPorts repository:

sudo port selfupdatesudo port upgrade outdated

Install NTFS3G as NTFS3G now depends on Fuse4x by default (which wasn't the case back

when this article was first written), using the command below should install Fuse4x automatically

before installing NTFS3G:

sudo port install ntfs-3g

Ok, at this point you should have a functional fuse4x and ntfs3g install. Unfortunately, since

most MacPorts packages are really just the straight sourcecode for their upstream project with

only a few patches to make it compilable on OSX, those packages most often don't really integrate

well with the workflow of the system, specially UIwise (e.g., there are no preference panes for

Fuse4x or NTFS3G). Most importantly, that means that this ntfs3g install won't automount

NTFS volumes at boot or volume insertion (for removable disks) this would still be done by the

standard NTFS driver on OSX. Due to the nature of how most packages are ported over to

MacPorts, you'd be expected to mount your NTFS volumes via NTFS3G manually, via the

terminal, which sucks. We'll have to hack our way around to get that working somewhat better.

The idea is to trick OSX into redirecting the automount procedure for OSX's native NTFS to use

NTFS3G instead. Still on the terminal, make a backup of the file mount_ntfs, which is

responsible for mounting NTFS volumes with the native driver:

sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig

Again, create an empty file, setup the permissions, and open it in an editor:



sudo touch /sbin/mount_ntfssudo chmod 0755 /sbin/mount_ntfssudo chown 0:0 /sbin/mount_ntfssudo nano /sbin/mount_ntfs

Ok, we're almost there. Paste this script in the editor:

#!/bin/bash

VOLUME_NAME="$@:$#"VOLUME_NAME=$VOLUME_NAME#/Volumes/USER_ID=501GROUP_ID=20TIMEOUT=20

if [ /usr/bin/stat -f "%u" /dev/console -eq 0 ]; then USERNAME=/usr/bin/defaults read /library/preferences/com.apple.loginwindow | /usr/bin/grep autoLoginUser | /usr/bin/awk ' print $3 ' | /usr/bin/sed 's/;//' if [ "$USERNAME" = "" ]; then until [ stat -f "%u" /dev/console -ne 0 ] || [ $TIMEOUT -eq 0 ]; do sleep 1 let TIMEOUT-- done if [ $TIMEOUT -ne 0 ]; then USER_ID=/usr/bin/stat -f "%u" /dev/console GROUP_ID=/usr/bin/stat -f "%g" /dev/console fi else USER_ID=/usr/bin/id -u $USERNAME GROUP_ID=/usr/bin/id -g $USERNAME fielse USER_ID=/usr/bin/stat -f "%u" /dev/console GROUP_ID=/usr/bin/stat -f "%g" /dev/consolefi

/opt/local/bin/ntfs-3g \ -o volname="$VOLUME_NAME" \ -o local \ -o negative_vncache \ -o auto_xattr \ -o auto_cache \ -o noatime \ -o windows_names \ -o user_xattr \ -o inherit \ -o uid=$USER_ID \ -o gid=$GROUP_ID \ -o allow_other \ "$@" &> /var/log/ntfsmnt.log

exit $?;

Press Ctrl+X, say Y to save, press Enter to accept the file name.

Now, note the option uid and gid. It teels ntfs3g which OSX user and group should own the files

on the mounted volume. If you don't provide these options, ntfs3g will default to the root user,

which will allow you to do most writing operations on the volume except write/modify to existing

files to be able modify files, you should then specify the uid and gid for the login you use on your

system. In a standard OSX installation, the uid 501 and gid 20 should be the first standard user

you provided on OSX install, and the "staff" group, respectively. To make sure these uid and gid

pair match the ones for the user you use on your system, type in the Terminal (make sure you're

not on a root ("#") prompt):

id -u && id -g

This should output two lines, the first containing the id for your user, and the second the id of the

default group for your user. If they don't match the ones on the script, edit the script again and

modify it accordingly. Update: This is needed only in a worst case scenario where you haveautologin disabled and you don't login manually within 20 seconds (adjustable in theTIMEOUT variable).

Now, here's the caveat with the whole Fuse4x method: since we had to explicitly provide the uid

and gid for the user/group that'll own the files on the volume in order to have full access to it, this

means that this method will have problems in multiuser Mac stations.

For example, if you have two users say, john, and mary on your Mac, john will have a uid of 501

and mary will have a uid of 502. If the mount script is setup as above, john will have full access to

the volume, but mary, while being able to mount NTFS volumes just fine, won't be able to modify

existing files on the volume, just like mentioned earlier when you don't provide the uid/gid

parameter.

There's no way out of that, as far as I know. I've tried a ton of argument combinations for ntfs3g

while trying to avoid the uid/gid arguments, nothing worked. I welcome suggestions. But for now,

it works well enough for me as it is, I'm the only user on my Mac anyway, and I suppose that's the

case for most Mac users, so I didn't bother to sweat about it too much. If that's really a problem

for you though, then you should be better off with the MacFuse + TuxeraNTFS3G solution, that

doesn't have this problem.



53 responsesLike

Comment

8 months ago Mitchell responded:

This is great. Works well, and I don't have to pay to use NTFS.

8 months ago megastorus (Twitter) responded:

This is a great article. Thanks a lot.

I sent a link to your blogpost to fuse4x maillist

https://groups.google.com/forum/#!topic/fuse4x/mCgddOK3zHI

8 months ago Fernando Figueiredo responded:

@megastorus: Oh wow. Took me awhile to figure out who you are I guess it's me

who owe thanks for the prestigious linking, and obviously, the awesome job

you're doing with Fuse4x. It's shaping up as nice, stable, and upstream

compatible replacement to MacFuse.

So, thank YOU a lot! :)

8 months ago Akagi responded:

I always get a popup that says that the medium could not be read. And it offers to

initialize the medium, ignore the problem or to eject the medium.


@Akagi: first of all, is that a removable volume, or a partition on your disk? Are

you using the solution based on MacFuse or Fuse4x?

With that said (or asked), it looks like your volume is either corrupt or formatted

in a nonstandard way. In the former case, however, ntfs3g ought to be able to

recover/fix the more common errors on the disk at mount time, so either your

disk/partition is in pretty bad shape, or your fuse/ntfs3g install is messed up

somehow, in which case OSX may be trying to mount the volume with the native

driver, and if the ntfs volume have even a small consistency error, the native

driver will refuse to mount the disk and not even try to fix it (because there are

no native tools on OSX for that), and that situation would probably make OSX

spit out an error along the lines of what you're seeing. Either way, if that volume

is a partition on your main Mac disk, I'd try booting into Windows and scheduling

a disk check in there. Good luck!

8 months ago Akagi responded:

Hi,

thanks for your answer!

I use the Fuse4x with ntfs3g via MacPorts. The original NTFS driver from

Tuxera (the last free release) were completely deinstalled.

The device is a fresh formatted USB stick. I formatted it with Ubuntu (in a

VirtualBox installation on my MacBook Pro). There the stick is mounted

correctly.

I can also mount the stick on my Mac Book Pro via command line (e.g.

mount_ntfs /dev/disk4s2 /Volume/...).

Maybe I damaged something within my Lion installation.

Best regards!


Phew, that was a long one. Comments are welcome, of course. Cheers!

13Like



@Akagi: Have you actually replaced the mount_ntfs binary as mentioned in the

post? A better test would be trying to mount using a command like "ntfs3g

/dev/disk4s2 /Volume/..." , which is what actually does the job of mounting and

working with the volume.

You may also try running "ntfsfix /dev/disk4s2" on the terminal and checking the

output from it.

8 months ago Marcos responded:

Dear Fernando,

First of all, thank you for your excellent article!

I would like to let you know I've found a solution for the multiuser issue.

Basically what you have to do is get the current active user with the following

command: ls l /dev/console | awk ' print $3 '

You may take a look at my blog for further details

(http://blogdopersonaltec.wordpress.com). I've gave you the proper credits, of

course... ;)

Best regards!


Olá Fernando!

Eu é que tenho que agradecer pelo seu artigo que serviu de inspiração... :)

Sobre a solução, funcionou sem problemas aqui, mas deu um trabalhão

encontrar essa alternativa... rsrs Todas as outras que tentei retornavam root

como usuário... Achei até um programa em C que desenvolveram para essa

finalidade, mas no final optei pela solução mais simples (método "KISS", rsrs).

Abraços!

Até mais!

Marcos.


Fernando,

Dê uma lida na resposta que publiquei para você no meu blog. A questão que

você levantou tem solução também... Só não mencionei no artigo para não

complicar demais a vida dos leigos... rsrs

Abraços!

8 months ago Anil Kuppa (Facebook) responded:

Dear Fernando,

I couldn't install ntfs3g . It gives me errors saying

" The following disk images could not be opened:"

The reason is "not recognized" . I followed your steps I first installed Macfuse

and tried installing Ntfs3g.

My ntfs3g version is "ntfs3g2010.10.2macosx.dmg" and Macfuse version

is"2.1.15"

Please let me know where I went wrong.

I'm trying second step,but it would take a lot more time. I've just begun the

download and it might 56 hours.


@Anil Kuppa: It looks like to me it's just the dmg file for ntfs3g you downloaded

that's corrupt. Delete it and try downloading it again (empty your browser's cache

first, to avoid getting a local cached copy of the corrupt file from the browser). I

downloaded here, from the link on the post, and the install image is opening fine

here.

7 months ago Anil Kuppa (Facebook) responded:

I followed the second method, it works perfectly fine!!!!. I just checked your

comment, but now I don't want to make any changes.

During the 2nd procedure, there were 2 places of difference:

1) When I entered javac, the terminal gave me different options i should run

alongwith javac



2) I could not run sudo port upgrade outdated

Error: No ports matched the given expression

When I installed ntfs 3g, using the command you gave earlier, it automatically

fetched and installed fuse4x.

Thanks a lot for the blog :) . I had earlier reformatted my external HDD to

extFAT.

But extFAT was horribly slow, so I'm now happily using NTFS.


@Anil Kuppa:

> During the 2nd procedure,

> there were 2 places of difference:

> 1) When I entered javac, the terminal

> gave me different options i should run

> alongwith javac

That's fine, it only means you already had the javac dependency, probably you've

installed it before while doing something else.

> 2) I could not run

> sudo port upgrade outdated

> Error: No ports matched the given expression

That's ok too, it's not really an "error", it just means there was nothing to

upgrade, which is usually the case in a fresh MacPorts install.

> When I installed ntfs 3g, using

> the command you gave earlier,

> it automatically fetched and

> installed fuse4x.

Hm, so if I understood correcly, you just did "port install ntfs3g" directly instead

of installing fuse4x explicitly first. Well, aren't you a stubborn guy? :) But yeah,

it looks like the MacPorts maintainers have finally deprecated MacFuse and setup

Fuse4x as the default dependency for NTFS3G, so you got lucky :) But thanks

anyway,it would've taken longer for me to notice if you hadn't taken that chance.

I'll update the post to reflect that.

> I had earlier reformatted

> my external HDD to extFAT.

> But extFAT was horribly slow,

> so I'm now happily using NTFS.

I've never benchmarked exFAT on OSX myself so I can't be sure about it, but

either MacFuse+NTFS3G (Tuxera) or Fuse4x+NTFS3G (OSS) is not really

known to be a highperformance solution they are actually known to be quite

slow (on my MBP, I get about a 25MB/s read performance, which is pretty slow

compared to the native driver or paid solutions haven't tried writing, but the

performance usually is at least half the read numbers). But hey, it's free, it works,

and it's stable. And for those that, like me, use Windows on their Macs, it's also a

damn convenient solution, even with the slow performance for example, I use

Mozilla Thunderbird on my Mac with my mailbox files stored on the NTFS3G

partition (so I can use the same mailbox on Thunderbird for Windows) and it

works fine, and it doesn't feel slow at all.


> Either MacFuse+NTFS3G (Tuxera) or Fuse4x+NTFS3G (OSS) is not really

known to be a highperformance solution they are actually known to be quite

slow.

It is true for any Fuse filesystem. Every filesystem syscall makes one additional

context switch (in practice it makes 2 or more). The context switch is really

expensive operation and thus any Fuse filesystem always be slower that the one

implemented in kernel (as a kernel extension).


@megastorus: Hey, hi again :)

Yes, I'm aware of all that. Though I recall reading somewhere that Tuxera's



commercial solution does some funky caching stuff to achieve better

performance (though I believe it's not really that much better than the OSS

solution), but all the while completely breaking compatibility with Fuse.

Not that I care, of course I'm perfectly happy with the OSS solution as it is :) It's

not worth it to break (or worsen) Fuse upstream compatibility (and hence, its

usefulness) for a few dozen MB more of performance. People that need absolute

performance is better off using a native systembacked FS, like exFAT, for

portable data.

7 months ago Michael responded:

This is awesome. Only page I could find with clear instructions. Worked the first

time. Lion has been a huge disappointment so far. Thanks for your help!

7 months ago __B__ responded:

My drive is mounted, but it's filesystem is read as "Unknown (fuse4x)" when I do

cmd+I on Snow Leopard. Do you know what it can be?


It's not a problem. It's just that Fuse4x, since it's much closer to the upstream

Fuse project, it's not currently tightly tied down to OSX UI APIs and such, so it

doesn't expose a descriptive filesystem name for itself (or the pluggedin

filesystem, NTFS3G in this case) to OSX, so OSX names it as "Unkown". This is

purely a cosmetic problem, it doesn't affect the filesystem functionality at all.


As Fernando mentioned this is really a minor cosmetic issue and does not affect

the functionality.

The reason why you don't see the FSName here (and why you see it with

MacFUSE) is that MacFUSE hardcoded the filesystem names in its sourcecode

https://github.com/macfuse/macfuse/blob/master/core/10.5/fusefs/fusefs.fs/Con...

The NTFS3G passes its id and then macfuse fetches the FSName.

But it is not scalable. I strongly believe that it is bad idea to hardcode the FSName

only for a few filesystems. All macfuse/fuse4x filesystems were born equal and

all filesystems should be able to change the FSName, otherwise none of them

should be allowed to do this.

I'll take a look and try to find any workarounds for it. Or probably I should set a

human readable FSName for all filesystems (e.g. "Generic fuse filesystem").

6 months ago Norbert responded:

Thanks for the post, very useful, but I have one addition: I would not use the

noappledouble mount option, because it makes the finder behave strangly and

created the horribly dreaded Error code: 36 here.

Thanks

Norbert

6 months ago ep responded:

Great post! thanks for the script. Only note left here for future reference: for

homebrew user the executable in the script need be

/usr/bin/local/ntfs3g

rather than the /opt/local one you used.

5 months ago Ybalrid responded:

Thank you, it works with fuse4x :)

it was the only problem I have with OS X Lion




@Norbert: The "noappledouble" option isn't strictly necessary, it's safe to leave

it out if you have problems. I do have some strange behaviour occasionally with

some applications, like MS Office, though not with the Finder.

The reason that I use it is because without it OSX litters the entire NTFS partition

with .DSStore and other files containing OSX metadata. That's OSX's standard

behaviour btw, it does that too with windows network shares, and it annoys me to

no end because those files serve no purpose at all for other OS's apart from OSX

and it ends polluting my file lists. That's me nitpicking, I know, but I'd rather have

the occasional weirdness on OSX because of noappledouble than having my

partition littered with useless files. :P

4 months ago Vito responded:

change with these

USER_ID=$(id u) #501

GROUP_ID=$(id g) #20

all is working here!

V


I have tried something like this when I was hacking around that script, and it sorta

works "sorta" because it works when you mount volumes when you're already

logged in. In my case, my MacPro harddisk has a Windows partition that I use,

and that I want mounted on boot. The problem is that the mount_ntfs

binary/script is called during boot, it is done before the user is logged in, so it is

called as root. In short, during boot, the result of your expression would be "0"

for the UID and GID. That's why doesn't really work that well. It should work well

if you're dealing with an external NTFS volume that you plug in only after login,

though.

3 months ago nikkitousen responded:

Worked like a charm with Lion 64 bits :) Thanks!

3 months ago Xiyue Deng responded:

When using ntfs3g on Linux I used to use "o umask=0" switch for ntfs drives,

which results in all file gets 777 permission, but works well. Haven't tried myself

as I'm using the OSXFUSE+ntfs3g.2010.10.2 on 64bit Snow Leopard.

Hopefully the same can be applied here as well.

2 months ago Tony Regnauld responded:

Thank's Man.

Work' s great.

about 1 month ago kees responded:

had Lion installed and yes, NTFS3G didn't work anymore. Tried the fix from

here above and all disks mounted again. Great and good job you've did!

Thanks for that.

Kees

about 1 month ago Emiliano responded:

I am using OSXFUSE+ntfs3g.2010.10.2 on Lion and the trick suggested by

Fernando to avoid getting the popup error, that works perfectly using MacFuse

(I tried that too and could get it working even with the 32bit macFuse bundled

with the ntfs3g driver ), doesn't seem to fix the problem: the ntfs3g driver

apparently gets disabled as the drive gets mounted in read only mode using

Lion's native NTFS drivers...

about 1 month ago Stefan responded:

Works fine with Lion and OSXFUSE & NTFS3G.

Great job, thanks a lot!

about 1 month ago Fernando Figueiredo responded:



@Emiliano: Well, I can't vouch for OSXFUSE, since I don't use it, but I can say

this: OSXFUSE, while it's more closely related to MacFuse as far as client

Filesystem compatibility goes, seems to be operated more (i.e. installed /

configured) more or less in the same way as Fuse4x. Of course, I could just be

wrong. Also, I'd suggest you look into installing a more updated version of NTFS

3G, the one you're using is far too outdated.

about 1 month ago Emiliano responded:

@Fernando: I found a solution/workaround for my problem here:

https://gist.github.com/1100318

The reason why I'm using such an old version of ntfs3g is that, as far as I know, is

the last version of the free driver that can be found already "packaged" for

installation, and OSXFUSE, differently from fuse4x, can also be installed from a

dmg image, instead of having to compile it.

I followed your guide and used fuse4x+ntfs3g from MacPorts from my work

laptop, where I have XCode installed to develop for iOS/OSX, and it works

perfectly. But on my girlfriend's laptop I wanted to keep the installation as

simple/small as it can be, so I chose OSXFUSE and the old version of ntfs3g.

I'm still a beginner in the Mac world, but I guess I'll eventually figure out how to

compile an installer package from sources on my work machine and bring home

the candy ready to be eaten ;)

about 1 month ago Fco. Javier Pérez Velásquez responded:

is there a way now to format a pendrive in ntfs using disk utility....or using the

command line ?


@Fco. Javier:

Yes, there is, through the command line. You use the "mkntfs" command for that,

which is part of the ntfs3g distribution on MacPorts (don't know if you can get it

elsewhere). Type "mkntfs help" for usage instructions, but if you don't care

about the details, you can just go "mkntfs /dev/diskNsN", replacing "N" by the

disk and partition number where you wish to create the ntfs filesystem which

you'll have to figure out yourself by clicking the "Info" toolbar button on Disk

Utility.

about 1 month ago Fco. Javier Pérez Velásquez responded:

All ready did it using a linux distro....Now, I have to say that writing performance

is weak, very weak.

Thanks anyway for the tutorial. Everything worked well.

about 1 month ago Zak responded:

@Fernando,

You stated to Emiliano the he should get a more up to date version of NTFS3G.

Like him, I am using OSXFUSE+ntfs3g.2010.10.2. The link you posted is for

version 2010.10.2. Where do you see a newer version?


@Zak: The link I posted is for the NTFS3G version that's compatible with the

older MacFuse. Since OSXFuse is supposed to be successor to MacFuse, then yes,

that NTFS3G version for MacFuse should work on OSXFuse also, but the point I

was trying to make with Emiliano is that since this version is way outdated, you're

probably missing out on bugfixes, stability improvements and effeciency (though

not necessarily any big performance improvement you shouldn't ever expect

that from any filesystem implemented via Fuse).

MacPorts currently packages a much newer version of NTFS3G I believe the

latest is from january but it's compiled against Fuse4X, which is the only Fuse

implementation provided on MacPorts (and, I'd argue, the best and more

properly maintained anyway). I suppose it's possible to get NTFS3G source from

MacPorts and try to rewire the build configuration so you can compile it



manually against OSXFuse, but I don't expect that to be a simple task and hence I

have no motivation to try it (installing/using Fuse4x+NTFS3G via MacPorts

works well enough for me).

Of course, I understand using MacPorts is not a viable solution for everyone. The

easiest path for me would be to recommend people to use Fuse4x, downloading

the prebuilt binary image available on Fuse4x's site, but you'd have to have a

NTFS3G binary image to go along with it, and I couldn't find anything newer

from Tuxera's 2010 build.

So what I'm currently investigating is building these binary images with MacPorts

that's possible, but have a few gotchas that I'm still looking into, and anyway, I

need a Mac without MacPorts installed so I can have a proper test case for

installing these packages and see if they work so I depend on lending other

people's Macs to do it; I do have some, but they don't come by everyday, so it's

kind of a slow process. But if I manage it, I'll make sure to post a new article with

download links.

about 1 month ago Anatol Pomozov responded:

Just to clarify the latest version of Fuse4X (0.9.0) has MacFuse compatibility

layer and thus NTFS3G binaries compiled against MacFuse should also work

fine with Fuse4X (but I did not test it).

28 days ago doalwa (Twitter) responded:

Thanks a lot for this, was having a lot of issues with Tuxera's free NTFS3G

implementation, your guide worked like a charm!

I'm running OSX 10.7.3 and MacPorts 2.0.4 btw.

28 days ago Fernando Figueiredo responded:

@Robson: Yes, performance is slow you shouldn't expect absolute performance

out of any filesystem implemented with Fuse. With that said, are you copying

50Gb FROM the NTFS disk, or TO it?

If you're copying TO it, then 18 hours sounds about right, and there's nothing you

can do but wait for newer NTFS3G or Fuse4x releases that improve

performance, although, again, you shouldn't expect dramatic improvements even

then (i.e., I find it unlikely that any improvement will trim off more than half of

that time).

If you're copying FROM it though, then 18h is a bit too much. If you're copying

from an USB disk though, then USB IO overhead may be playing a part here.

20 days ago Mr Mike responded:

I tried the Ntfs3g MacPort Version, but the auto mount still won't work.

I tried "ntfs3g /dev/disk1s1 /Volumes/ ..." but all I get is the following error

message:

"Unprivileged user can not mount NTFS block devices using the external FUSE

library. Either mount the volume as root, or rebuild NTFS3G with integrated

FUSE support and make it setuid root. Please see more information at

http://tuxera.com/community/ntfs3gfaq/#unprivileged"

I know it has something to do with the userid or groupid, but I did everything as

described in your guide so ... do you have any idea what could have gone wrong?


@MrMike: Just to clear things up: You're using the solution with Fuse4X, not

MacFuse, right? I mean, you either installed Fuse4X and NTFS3G from

MacPorts, or installed Fuse4X from the binary installer available on

www.fuse4x.org and the binary installer for NTFS3G I provide, correct?

If so, you're not supposed to mount your NTFS volumes using the ntfs3g

command directly you should first either follow the script replacement

procedure (mount_ntfs) detailed on the post, or use the "Switch" script available

on my binary installer for NTFS3G that automates this. Once you do that, you

can mount your NTFS volume with the following command:

diskutil mount /dev/disk1s1

Of course, since the script replacement trick is supposed to make mounting of

ntfs volumes via ntfs3g transparent to OSX, your volume should also be



mounted automatically upon boot or connection (in case of an external drive).

Let me know if you still get any problems, and give more details of how you've

installed Fuse4X/NTFS3G, which system you're running on, etc.


I'm using the solution with Fuse4X and NTF3G via MacPort.

I also did the script replacment (mount_ntfs) as described, but the ntfs disks

won't mount automatically. Same problem with the ones connected after startup.

I only used the ntfs3g command to see where the problem could come from.

I'm running Mac OS X Lion 10.7.3 (11D50b), on a MacBook Pro 8th Generation.

fuse4x 0.9.0_1 and ntfs3g 2012.1.15_2 both installed with "sudo port

<program>"

I updated just a couple of days ago, but it also didn't work before.


@MrMike: Ok, please check if you have the file /var/log/ntfsmnt.log in your

system, and paste it here if you do. It might give a clue as to what's going on.


the file exists, but it's empty. :/


@MrMike: Ok, reverting to the method you were using initially then :) Have you

tried your method logged as root? Something like this on terminal:

$ sudo i

[type in your password]

# mkdir /tmp/mnttest

# ntfs3g /dev/disk1s1 /tmp/mnttest

And see what's the result. Since you didn't get your volume to mount through the

normal methods so far, I think it's unlikely that it'll mount now, but at least there

should be an error message or some other clue to what's the problem.


I tried as an normal user, which returned the errormessage I already posted.

When I try it as root, everything works fine, but the mounted disk is not shown in

the finder (but it can be accessed via the terminal). In both cases nothing gets

logged into the ntfsmnt logfile.


@MrMike: Well, sort of accessing your machine directly, I'm all out of guesses

here... You're the first and only to report such a problem anyway, so it's probably

safe to assume the problem is something specific in your system / OS install

that's causing the problem.

The only suggestion I'd have before resorting to reinstalling OSX is to uninstall

all ports (starting by ntfs3g and fuse4x) and remove macports completely, and

then look around in /usr, /usr/local and also /Library and /System/Library for

kernel extensions to make sure that there isn't any leftover library/binary/kernel

extension from fuse4x or ntfs3g from older installs that may be interfering with

the newer install.

5 days ago Erik responded:

Hello :)

I used the second solution (Fuse4x + NTFS3G from MacPorts), ad it worked OK

for some time. But then I started getting an error (The Finder can’t complete the

operation because some data in “” can’t be read or written.(Error code 36));

when trying to copy some files to a ntfs formatted external HDD connected over

USB. Curiously, this only happens when I try to copy large files (such as movies),

and not when I try to copy folders containing small files (such as a folder

contining several mp3 files). Another curious thing is that the big files copy OK if

I try to copy them from Terminal, using the cp command. Does anyone have any

idea what the f*** is going on?



Archive

2012 (4)

2011 (5)

Get Updates

Follow by email »

Get the latest updates in your email

box automatically.

Subscribe via RSS

Search


@Erik: This sort of occasional cryptic errors tend to happen when using the

"noappledouble" mount option, as also noticed by Norbert in the comments

above. You may try removing the line containing that option on the

/sbin/mount_ntfs script and see if it helps, but then you'll get your NTFS filled

even more with a lot of those hidden folders and files that OSX creates to store

its metadata. You can mitigate this problem a little using "asepsis" as explained

on my blog post right after this one.

I'll edit this blog post removing the "o noappledouble" line from the script I

added this initially because I have this pet peeve with OSX polluting nonHFS

volumes with useless files, but on second thought I suppose it's better for the

general user to have a fully functional volume on OSX than having a nice looking

one :P

4 days ago Erik responded:

@Fernando: That did the trick, thanks! :)

Leave a CommentName: Leave this field

blank to comment. Email:

Homepage:

Want to skip this stuff?Login with any of the following:

Register or login to Posterous

Comment:

Post this Comment

Documents

NTFS Write Support on OSX Lion With NTFS-3G - Im