How can I share a mounted NTFS volume over AFP?

June 15, 2008 5:01 PM

Networkfilter: I have a NTFS volume mounted on my OS X Server box. I'd like to access it over the net using AFP. It's not showing up as an available AFP share. What gives?

The NTFS volume mounts fine on the server:

admin@os-x-server$ sudo mount_smbfs //user@windows-fileserver/SHARE ~/ntfsdir
Password: os-x-server-password
Password: windows-password
admin@os-x-server$ ls -l ~ | grep ntfsdir
drwxr-xr-x    1 admin  staff  16384 Dec 31  1969 ntfsdir
admin@os-x-server$ ls -l ~/ntfsdir
drwxr-xr-x   1 admin  staff    16384 Feb 23 05:27 dir1
drwxr-xr-x   1 admin  staff    16384 Jun  3 09:42 dir2
drwxr-xr-x   1 admin  staff    16384 Apr 15 16:24 dir3
.
.
.

So it's mounting fine and the permissions look okay. In the Workgroup Manager for the OS X Server, ~/ntfsdir is set as a share point, owner is given read and write access, and AFP is enabled for that share. But when I try to mount the AFP share on my local machine, I get the following error:

user@os-x-client$ sudo mount_afp afp://admin:password@os-x-server/ntfsdir ~/afpdir
Password: os-x-client-password
mount_afp: the mount flags are 0000 the altflags are 0020
mount_afp: AFPMountURL returned error -5019, errno is 2
user@os-x-client$

Google says that error -5019 means bad share name. And indeed, when I use Connect to Server... from the the Finder on the client machine, the share ntfsdir doesn't show up, even though it's enabled in the Workgroup Manager, AFP access is on, and owner has full read/write permissions to the share (both in AFP share config and in the server's filesystem itself).

Even weirder, the I can't even mount the share over AFP from within the server itself! I get the following error:

admin@os-x-server$ sudo mount_afp afp://admin:password@localhost/ntfsdir ~/testdir
Password: os-x-server-password
mount_afp: the mount flags are 0000 the altflags are 0020
mount_afp: AFPMountURL returned error -5019, errno is 32
admin@os-x-server$

So for some reason this share is not being advertised properly. I've tried making other test AFP shares, and they work fine... it must have something to do that I'm trying to share a directory that is itself a mount point for a mounted NTFS share.

I don't see why the AFP service even knows that ~admin/ntfsdir (on the server) is an NTFS mounted share... seems like it should just be another directory in the filesystem, from its perspective. Unless it's a permissions thing that I'm missing, although, like I said, the permissions for ~admin/ntfsdir look good; I can browse the mounted NTFS volume on the server through the command line, etc.

Any clever suggestions for me?

posted by DLWM to computers & internet (4 comments total)

A shot in the dark: Is the share a subfolder of another share, or on the root of the drive? I have seen issues where Windows shares that are a subfolder of another share fail.
posted by disclaimer at 5:27 PM on June 15, 2008

I'm have my doubts AFP is not going to let you re-share a network volume -- you're looking at a potential security nightmare if anyone can re-offer network filesystems mounted as a given user. I don't have the AFP spec in front of me, but certainly if I were writing it I'd forbid pass-through sharing.

It's likely you're running into two issues: AFP won't share out a network filesystem, and the GUI doesn't know that.

By the way, you've got some terminology incorrect. You don't have an "NTFS volume mounted." You have an "SMB network volume mounted." Saying "NTFS volume" implies you're actually talking to the filesystem on disk (such as over USB to an external spindle) and not a network filesystem. It's a pedantic difference, but you're going to run into trouble finding help for doing things when you describe them incorrectly.
posted by majick at 8:36 PM on June 15, 2008

admin@os-x-server$ ls -l ~ | grep ntfsdir
drwxr-xr-x 1 admin staff 16384 Dec 31 1969 ntfsdir

Not relevant to your question, but try  "ls -ld ntfsdir", instead of your pipeline. The "-d" tells ls to look at the directory itself and not its contents.
posted by philomathoholic at 9:50 PM on June 15, 2008

majick: Thanks for the correction. If you can't be pedantic in computers and math, where can you? ;) By calling it a "mounted NTFS volume," I wanted to stress that the filesystem in use on the Windows server was NTFS -- just in case that was causing a permissions issue in conjunction with the Mac boxes.

However, some research on Apple discussions reveals that, as you imply, all that matters (from the perspective of the OS X Server) is that's it's a SMB share. The "underlying" filesystem is irrelevant:

First off, re-sharing a volume that uses the smb filesystem is not possible due to the way permissions are calculated for that volume. Regardless of the local filesystem of the volume that houses the share point on your Linux server (ext3 or whatever), that share point's filesystem as it appears to all clients, including your Mac OS X Server computer when it connects as a client, is the smb filesystem. Since that's a network filesystem already, some types of information cannot be "appended" to it. AFP and SMB/CIFS filesystems, when mounted via Go/Connect to Server (or mount_smbfs) will use a set of masked POSIX permissions. (This means that, if you're logged into the server as a local admin - locadmin, for example - and you mount the SMB share point as Sally, then locadmin is the owner of the mount point and its enclosed files. The currently-authenticated user is granted the permissions assigned to the user account used to connect. Hence, permissions masking. This happens in every instance when mounting a volume via SMB/CIFS. It happens when connecting to an AFP share point except when the client is bound to a shared directory system, where the user name authenticated at the login window matches the account used to connect to the share point.)

So there you have it. Not possible to re-share mounted SMB volumes because of the way authentication works. An interesting side-note, from the same guy who explained the SMB stuff above:

One of the reasons that you can reshare an NFS volume is that you can tell the other server - your Linux box - to map the connection coming from your Mac OS X Server box to a user with read & write permissions to the NFS export (share point), usually the owner. In this way, any commands sent by Mac OS X are issued as the owner of the NFS export, according to the Linux system's point of view. The main difference here is that, since the mapping is defined on the Linux box's system, Mac OS X does not employ its own permissions masking.

philomathoholic: Thanks for the tip! Didn't know about that.
posted by DLWM at 6:13 AM on June 16, 2008