Skip to main content
Solved

Any way to create a policy to prevent users from using illegal Windows characters ? [ ] / \\ = + < > ; : " , | *


Forum|alt.badge.img+6

We are a cross platform shop and currently re-share an Xsan/StorNext Volume via SMB on Windows Server 2008r2. Mac users often use one of those illegal characters which wreaks havoc with our backup and with our reshare.

Is there a way to prevent OS X from saving files with characters considered to be Illegal on other OS's?

Best answer by talkingmoose

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.

View original
Did this topic help you find an answer to your question?

10 replies

donmontalvo
Forum|alt.badge.img+36
  • Legendary Contributor
  • 4293 replies
  • July 30, 2013

Um, get rid of their AFP shares? ;)


Forum|alt.badge.img+6
  • Author
  • New Contributor
  • 9 replies
  • July 30, 2013

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


Forum|alt.badge.img+12
  • Contributor
  • 417 replies
  • July 30, 2013

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


Forum|alt.badge.img+12
  • Contributor
  • 417 replies
  • July 30, 2013

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


talkingmoose
Forum|alt.badge.img+36
  • Community Manager
  • 1900 replies
  • Answer
  • July 30, 2013

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.


Forum|alt.badge.img+12
  • Contributor
  • 189 replies
  • July 30, 2013

+1 on talkingmoose's analysis and suggestions.


donmontalvo
Forum|alt.badge.img+36
  • Legendary Contributor
  • 4293 replies
  • July 30, 2013

@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.

talkingmoose
Forum|alt.badge.img+36
  • Community Manager
  • 1900 replies
  • July 30, 2013

@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.


donmontalvo
Forum|alt.badge.img+36
  • Legendary Contributor
  • 4293 replies
  • July 30, 2013

@talkingmoose wrote:

What I've said is still correct.

Agreed. :)


Chris_Hafner
Forum|alt.badge.img+23
  • Jamf Heroes
  • 1716 replies
  • July 31, 2013

Yep... educate them.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings