Um, get rid of their AFP shares? ;)

There are no AFP shares in this scenario, on the Mac the volumes are presented as Xsan (They are fibre attached for speed). However some producers who are on laptops (see also: not fibre attached/do not need speed) have access to some folders on the Xsan volume that are being re-shared through a Windows server.

So a fibre attached user would navigate like /Volumes/Xsan_Volume/example_folder whereas a non-fibre user would navigate via smb://example_windows_server/example_folder

We've straightened out POSIX/ACLs, but we want to enforce file naming

If there are no afp shares, how are they writing illegal windows characters?

If there are no afp shares, how are they writing illegal windows characters?

Xsan volumes can mount on Mac workstations as if they were locally attached external hard drives. No AFP and no SMB involved.

To my knowledge, I know of nothing that will prevent a Mac user from using specific characters on a volume. This is a common problem when using any sort of file share cross-platform. I'm afraid you'll just need to educate your Mac users or consider running a script on your server to routinely run and find/replace illegal characters.

+1 on talkingmoose's analysis and suggestions.

@talkingmoose wrote:

Xsan volumes can mount on Mac workstations as if they were locally attached external hard drives. No AFP and no SMB involved.

...however, OP stated:

We are a cross platform shop and currently re-share an Xsan/StorNext Volume via SMB on Windows Server 2008r2.

@donmontolvo

What I've said is still correct. Macs can mount the Xsan volumes via fiber for speed. This connection is akin to mounting an external hard drive not mounting via AFP nor SMB.

A server can also mount an Xsan volume and share it to network users over copper via AFP or SMB.

The two types of connections aren't mutually exclusive.

@talkingmoose wrote:

What I've said is still correct.

Agreed. :)

Yep... educate them.