Comments on: How can I share a mounted NTFS volume over AFP?

Question: How can I share a mounted NTFS volume over AFP?

DLWM — Sun, 15 Jun 2008 17:01:14 -0800

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?

By: disclaimer

disclaimer — Sun, 15 Jun 2008 17:27:56 -0800

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.

By: majick

majick — Sun, 15 Jun 2008 20:36:13 -0800

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.

By: philomathoholic

philomathoholic — Sun, 15 Jun 2008 21:50:43 -0800

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.

By: DLWM

DLWM — Mon, 16 Jun 2008 06:13:05 -0800

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.