File Sharing & Protecting

# File Sharing & Protecting

NetApps, Native, Mixed Mode, SMB, Filesystem

## Files in a Multi-Operating System Culture

This document attempts to outline some of the basic issues and techniques for securing your directories and files at an appropriate level. It covers Windows shares on windows desktops and servers, Unix NFS based filesystems, and the NetApp "filers".

NRAO has a large-scale, highly robust and very reliable file "appliance" at each major site (CV, GB, AOC). These are usually referred to as "NetApps" as they were purchased from Network Appliance, Inc., or more recently as "the filer" at each site.  The filers can serve files for both Windows and Linux (Unix) systems. In New Mexico and Green Bank, the paradigm for sharing and protection used is that of Unix; but in Charlottesville, the system uses "mixed mode" which causes issues (see sidebar at right/below).

MIXED MODE ON FILERS

Because the paradigms and protocols for sharing files and folders on a filer with "mixed mode" are quite different and to some extent mismatched, there are some issues (it boils down to not being able to please all the people all the time). However, NetApps do a superb job of reconciling these, about the best in the industry in terms of keeping permissions as consistent and correct as possible.

There are three classes of filesystems or "shares" that the NetApp provides:

• Native NFS (Unix) filesystems; these are usually reserved for things like mail spools, system files, etc.; all three filers use this filesystem type; New Mexico and Green Bank use it exclusively.
• Native SMB (Windows) filessytems or "shares"; generally not accessed directly from Unix or Linux systems. This is only used in CV for a set of shares that originated on the "Eagle" NT server years ago.
• Mixed Mode filesystems. Also only in use in CV for login "home" directories.

## Successful Cross Platform Sharing in Mixed Mode

There are some issues associated with the use of NetApp Mixed Mode filesystems, especially if you access the same files from both a Windows system (e.g., through \\cvfiler\) and a Linux system (e.g., via /users/pmurphy/ where you substitute your username for pmurphy). These issues only affect mixed mode filesystems such as /users.

For UNIX Users: the best approach is to create a new folder from Windows in your /users/<username> directory (mine would thus be /users/pmurphy/windows/, for example). Use this area to store files from the windows side, and if you want to share them with your Unix account or others running Unix/Linux, have your colleagues copy the file from there (or copy it yourself to where you want to work on it from Linux/Unix).

If you choose to edit the files in this windows directory on the Unix side directly, make sure your editor does not create a new version of the file. This can be done:

• For emacs, put this in your .emacs file:

 ( setq make-backup-files t )

This forces emacs to overwrite the current file (and preserve the inode) instead of making a brand new file for each edit.

• For vi: Set the option backupcopy' to yes'. The effect is as for emacs.

For Windows Users: WARNING! You should never change the permissions of your top level home directory on cvfiler (\\cvfiler\users\{yourname}) via right clicking and choosing "properties" from the Windows file explorer. If you need or want to change permissions on your home directory, do it on a Unix or Linux system. Failure to follow this advice may lead to you losing e-mail and other undesirable things.

## Possible Mixed Mode Complications

If you do not take the above advice, then you may suffer from any or all of the following:

• ACL loss: If you have put an Access Control List (ACL) on a file using a Windows system, and that file is then edited with, say, emacs on Linux, the net effect is for the ACL to be lost. That's because most Unix editors actually make a new version of the file, and as Linux ACLS (in Red Hat 9 and newer; older versions don't have ACLs) are inconsistent with Windows ACLs, it cannot be copied from the Linux side.

• Unix Permissions looking weird: If a Windows file has an access list, the permissions on the Unix side may look totally permissive (read/write/execute permission to everyone, i.e. rwxrwxrwx), but that is not so. If a different account had no write permission on the file from the windows side, that account will not be able to write to the file from Unix/Linux either.

• Permission Liberalization: If you edit a windows-ACL-protected file on Unix on the mixed mode filesystem, and your editor creates a new version of the file, check the permissions; it may be (depending on editor) that the liberal but fake (rwxrwxrwx) permissions were copied to the new instance of the file and have now become real; the ACL will be most likely lost.

Besides these issues, there are good things about the NetApp file system. One of the best is the snapshot feature, which provides a snapshot or frozen-in-time read only picture of what the filesystem was like at specified intervals. See the Computing Guide page on on backups, the snapshot section for more details. Note the caveat about the .snapshot directories being hidden until you explicitly open them on windows.