Mac OS X - Problems with file permission into NTFS usb drive

Question

I can read/write files within an NTFS external USB drive.

I have some problems with large files like AVI/MKV stored on an NTFS external drive. Those files appears greyed into Finder and, always using Finder, when I "Open With" my video player I receive a strange error:

Item “file.avi” is used by Mac OS X and cannot be opened.

Well, I found a workaround: if I drag & drop file.avi into my video player everything works fine.

But really I cannot figure out why this problem appears.

Please consider I haven't any NTFS custom drivers installed (i.e. MacFUSE or NTFS-3g). To mount my NTFS USB drive in R/W I have modified only /etc/fstab, adding the following line:

LABEL=WD320 none ntfs rw

Solution 1

I've found a thread that deals with the very same subject. Files appear greyed out and can not be opened with the same error message.

Here are the steps to (hopefully) resolve it:

• Open a Terminal and run

  xcode-select --install
  

• The above will install the XCode command line tools

• Then, run

  GetFileInfo /Volumes/WD320/yourfile.avi
  

• There should be information about the file type and creator and other file attributes

• Now, change those attributes by calling

  SetFile -c "" -t "" /Volumes/WD320/yourfile.avi
  

• Now the file should play

I obviously couldn't try it (which I'd normally do), but maybe it helps.

Solution 2

Item “file.avi” is used by Mac OS X and cannot be opened.

This means the item has had a file type of 'brok' and a creator code of 'MACS' set for it (and not cleared):

When you use the Finder to duplicate files, when the Finder first creates the duplicate file, it sets a special file type of 'brok', and a creator code of 'MACS' (the creator code of the Finder itself), to signify that the file is in use. Once the Finder finishes creating the duplicate file, it resets the file type and creator code to those of the original file.

Ordinarily, you'd only encounter a situation where the 'brok' file type isn't reset if the Finder were to crash or were somehow else interrupted during the file copy. If that isn't the case for you, then what you're seeing could well be a bug in the rw support of the built-in NTFS driver.

As slhck mentioned, you should be able to clear this reaction by the Finder by clearing the file type and creator code of the file-in-question.

Solution 3

My response to this problem is the result of cobbling together answers taken from several other posts (many thanks) and my own experience.

The background: I have an external hard drive with an NTFS file system. I want to plug it in occasionally. Previously the volume would mount 'read only'. Once I got that fixed, the files on the volume were in an unusable state. in order to get the volume mounted correctly and have the files accessible, I had to do the following:

FYI: I'm a kornshell user. Adjust these commands to your preferred shell.

$ sudo ksh
<password>

$ mv /sbin/mount_ntfs /sbin/mount_ntfs.orig

$ vi /sbin/mount_ntfs

Then paste the content below:

#!/bin/ksh

# --- direct all script stdout to a temp file for examination
exec > /tmp/ntfs

# --- connect all stderr to stdout
exec 2>&1

# --- get the last argument on the command line - this is the mount point
eval echo \$$# |
read MOUNT_PT
echo "\${MOUNT_PT} = \"${MOUNT_PT}\""
echo

echo "Mounting $@"

# --- call the original ntfs mounter with the arguments handed in
/sbin/mount_ntfs.orig -o rw "$@"

echo "Mounted  $@"

# --- show the result of the mounting operation
mount

# --- fix files at the newly mounted MOUNT_PT that are in the 'brok' state
find "${MOUNT_PT}" -type f |
while read FILE; do

    # ---
    # --- use 'SetFile' to modify the file status
    # ---
    # --- this command line assumes the 'SetFile' command has been installed
    # --- and is available in your PATH
    # ---
    SetFile -c "" -t "" "${FILE}"

done

Then:

$ chmod a+x /sbin/mount_ntfs

$ chown root:wheel /sbin/mount_ntfs

Now, any time I plug in the disk, it is mounted 'read/write' and the files on the disk have their 'brok' status reset. This script works well for me. Your mileage may vary.

Enjoy --

Solution 4

Thanks a lot for this - I improved the script above as it didn't run on my OSX 10.8.4 machine (gave errors) and was a bit slow. Only need to check when an read-only disk is mounted... Changes marked with JCV CHANGED:

#!/bin/ksh

# --- direct all script stdout to a temp file for examination
exec > /tmp/ntfs

# --- connect all stderr to stdout
exec 2>&1

# --- get the last argument on the command line - this is the mount point
eval MOUNT_PT=\${$#}
# -- JCV CHANGED: corrected eval expression

echo "\${MOUNT_PT} = \"${MOUNT_PT}\""
echo

echo "Mounting $@"

# --- call the original ntfs mounter with the arguments handed in
/sbin/mount_ntfs.orig "$@"

echo "Mounted  $@"

# --- show the result of the mounting operation
 mount

# --- fix files at the newly mounted MOUNT_PT that are in the 'brok' state
find "${MOUNT_PT}" -type f |
while read FILE; do
  #JCV CHANGED: added check whether file type affected
  GetFileInfo -t "${FILE}"  | read FILETYPE
    if [[ $FILETYPE = "\"brok\"" ]];then
    # ---
    # --- use 'SetFile' to modify the file status
    # ---
    # --- this command line assumes the 'SetFile' command has been installed
    # --- and is available in your PATH
    # ---
    SetFile -c "" -t "" "${FILE}"
    echo "fixing file ${FILE}"
   fi
done

View more solutions

Comments

[slhck]

Is this only happening on media files (e.g. videos)? Can you specifically rule out some file types?

[slhck]

Another thing you could try is to just install NTFS-3g and see if it works with that.

[Admin]

A non-techie solution is to open the greyed-out files with the useless Quick Time Player (QTP) using 'quick view' > double (or right) click filename > Quick Look This only works with files that QTP can open such as mp4 avi etc. It won't open mkv files.

[Admin]

To circumvent the problem completely you can create the files by transferring them from an external hard disk, (instead of copying them from your puter's HD) to your NTFS HD. Laborious, sure, but then the files can be accessed directly

[slhck]

Anybody care to explain why the downvote? @NSGod actually referred to my answer as the thing to try out -- his (very good) answer only explains the technical background though.

[freedev]

Very good. Thanks a lot for this suggestion :)

[suspectus]

Could you please mention the changes made and why - thanks.

[JCV]

thanks for the reply - I tried to explain it in the post above.

[suspectus]

That means a reader has to read both code blocks and do a mental comparision. Some annotation to describe what you have done and why would be helpful.

[JCV]

The script works only until the disk is remounted - then it has to change the parameters again. I tried changing setFile params to -c "????" (creator application unknown) which gives a persistent solution but then it confuses quicktime while opening a movie (unknown file type blah blag).

[trlkly]

Can you no longer edit these fields in the Finder file properties itself? They appear to be in editable text boxes in the screenshot given in the answer given by @NSGod. If you can, that would explain a downvote, if you recommended downloading an unnecessary program.

[NSGod]

@trikly: No, the window shown in my answer is a screenshot of Rainer Brockerhoff's Xray app (brockerhoff.net/xray). The Mac OS X Finder has never had the ability to edit file types and creator codes directly via a GUI (you may be able to use AppleScript). My intent with showing the image was to try to better illustrate what was happening.

[Benno]

Still works well in macOS Sierra for my NTFS mounted HDD files :-) thank you!