Q: Is it possible to disable users from moving/deleting folders?

Folder-based file storage doesn't scale very well for these cases.  Never has, really.  Way too easy to fill "the world" with old junk files that get forgotten and left undeleted, and with folders that are no longer needed, and it's too hard to keep track of what data is current and what's duplicated or not, and otherwise becomes a complete morass.   Just archiving the old data systematically can get tedious, too.

Put another way, you'll probably want to look at a customer relationship management package, or a custom database, or at least a different way of approaching and storing — and protecting — your customer data.  This might be some front-end apps that manage the existing morass of directories, or maybe a database where the data is stored and accessed.  As an example of a package that provides a customer-management and customer-tracking interface, there's Sugar CRM — and there are other packages around.

As for your question, you're headed for a tangle of access control list (ACL) entries which likely won't get you where you really want.  To keep a particular directory from moving elsewhere for instance, the user that should be denied this capability of movement can't have write access to the parent directory.   That means the root directory of your storage area is protected against write (modifications), while the subdirectory allows write — which allows the users to access.  If this follows the usual course, there are then ACLs added to provide different groups of users with different access — management access, supervisors, folks that are making changes to the subdirectories, and then those folks that should only have read access.  Possibly also into different teams, too, if you should have sensitive projects or sensitive data around.

These ACLs are managed using Get Info in the Finder menus in the GUI, and also via command-line commands such as chmod and maybe the chflags commands available within Terminal.app environment.  (These too tend to become command line scripts or apps, as managing and repairing these ACLs over time gets to be a hassle, both as directories are added and as settings are changed.)

There are some protection- and ACL-related overviews here, here (screen shots are dated, but the Unix underpinnings have not changed) and here (again, a little dated but still correct).

As a slightly different approach toward this goal, using a revision control system as a storage mechanism is fairly common in some environments — git or mercurial can store all sorts of stuff, and provide access controls, security, and the ability (for instance) to mirror data.  Your users can "check out" the files for a project, make your changes, and then "check in" the project files.  This completely avoids the need to manage those shares, and it means you can use the access control mechanisms within the particular revision control system to manage, track and audit access and changes.

You very likely won't find a tool that exactly maps to what you want or need here, and add-on application software will either require you to adapt to the tool or to customize the tool.  The same holds for using protection masks and ACLs — you'll have to learn the capabilities of OS X and map your operations to what OS X provides.  Customized software can usually do whatever you want for cases such as you're describing, and that ranges from fairly simple scripts on up to full-on databases with distributed front-end tools and revision control.

Mail has many of the same basic problems as using folders as storage — it works great for small environments and person-to-person, but doesn't scale well to larger teams and larger customer bases, and mail generally becomes a complete disaster as a communications and knowlege-management medium for a business.  Given most business folks are so accustomed to using mail, they often don't think about the burial of their critical business data in unmodifiable and untrackable and unauditable forms scattered across a gazillion mail files, though.

Outsider wrote:

 

Mrhoffman,

 

Thank you for the response and this will get me on the right track; I think the ACL route will be the best solution for us. Mail isn't an issue at all as we use a web interface and cloud backup solution for that element; neither OS X or Mac Mail will be responsible for the handling of our mail operations. As for folder storage, we have a company portal that will eventually be upgraded so that the all operations will be accessed through said portal, however in the mean time due to usability and the need to limit different services for the office, folder storage is the most comfortable solution. Therefore, as long as I have a system to eliminate, at least limit, data move issues as a stop gap until the portal is functioning in the manner that we wish, I'll be happy.

You're focusing on two classic computing tools here — shares, and (because I mentioned it as a parallel) mail — and are looking to apply those here.  That's certainly your choice and your call.  But I'd suggest taking a few steps back for a moment, and looking at what you want and need to be doing with the information here in more general terms.  How the information arrives, gets used, and eventually gets archived or gets deleted from your system, and how access is controlled.

If you believe I'm referring OS X Server and its mail server with my reply, that would be incorrect.  All mail servers and all mail clients stink as information and communications tools for groups.  All of them.   Mail is very familiar, and it is fundamentally broken as a coordination and communications tool.  It's great for doing person-to-person stuff, and it's usually a comfortably chaotic debacle in most any moderate-sized or larger organization. 

When using mail for organizational communications, you end up with a whole pile of chaff, and have to dig through all that for the more important mail, and folks that join the organization later on can be left entirely in the dark as much of the key organizational information tends to be buried in individual mail files.

Shares have many of the same problems, but — unlike mail — there often aren't "owners" for the files left around, which means scratch files and drafts and other work products can end up scattered around, and often with inconsistently-named and inconsistently-located files — this is a step past those directories that get dragged around into the wrong folders, but — like what you're seeing with the misplaced folders  — very common.

In the Microsoft world, SharePoint tries to address some of these issues, as do tools such as SugarCRM for customer relationship management.