Novell Open Enterprise Server 2 Best Practices Migration Guide - File System Installation & Migration

From MicroFocusInternationalWiki
Revision as of 00:07, 12 January 2008 by Coolguys (Talk | contribs)

Jump to: navigation, search

< Novell Open Enterprise Server 2 Best Practices Migration Guide

File System Installation & Migration

With Linux, over 20 different file system choices are available, ranging from very simple to extremely complex and rich systems. Novell surveys indicate that almost two-thirds of OES Linux customers use either ReiserFS (because of its simplicity) or Novell® Storage Services™ (because they are already familiar with it or need the associated rights), with ext3 running a close third.

If you are already using Novell Storage System (NSS) on NetWare, you can continue its use, or opt for a traditional Linux file system in those cases where it's to your advantage. Primary Novell and Linux file system options are compared in this section, but other systems are available. Use the information and cross-references in this section to match the file system to the data, workload, and access control you need (sometimes very simple is good enough).

Note: OES 2 Linux requires a Linux traditional file system volume for the operating system.

Additional Information: A detailed comparison of Linux traditional file system features can be found at: []. An additional Novell discussion of file systems can be found at [] . Both OES 2 Linux and NetWare support Novell Storage Services as well as their respective traditional file systems. The following table and illustration compare the file systems available with NetWare and those available with OES 2 Linux.

File Systems Available on NetWare and Linux

NetWare Linux
NetWare Traditional File System (NWFS)

(legacy system supported through NW 6.0)

Open source version of the NetWare File System (limited functionality)
Novell Storage Services Novell Storage Services (OES Linux)
Linux Traditional File Systems (ReiserFS, ext2, ext3, JFS, XFS, Others)

Bpg image-3.jpg

Supported File Systems

Novell File Systems

Traditional NetWare File System

The NetWare File System (NWFS) is used in NetWare 3.x through 5.x as the default file system, and is supported in NetWare 6.x for compatibility. It is one of the fastest file systems available; however, it does not scale and is not journaled. An Open Source version of this file system is available on Linux to allow access to its file data. However, the Open source version lacks the identity management tie-ins, and therefore, has little utility. NWFS customers are encouraged to upgrade to NSS.

Novell Storage Services (NSS)

Novell Storage Services is available with NetWare 5.0 and above; it has been open sourced and is included in Novell's SUSE SLES 9 SP1 Linux distribution and later and with Novell's Linux Open Enterprise Server. The NSS file system is unique in many ways, mostly in its ability to simultaneously manage and support shared file services from different file access protocols. It is designed to manage access control (using a unique model, called the Trustee Model, that scales to hundreds of thousands of users securely accessing the same storage) in enterprise file sharing environments. It and its predecessor (NWFS) are the only file systems that can restrict the visibility of the directory tree based on the UserID accessing the file system. Both NSS and NWFS have built-in ACL rights inheritance. NSS also includes mature and robust features tailored for the file sharing environment of the largest enterprises.

Shared NSS Features

NSS on NetWare and OES 2 Linux share these features:

NetWare Linux
Maximum device size (physical or logical) 2 TB
Maximum partition size 2 TB
Maximum # of partitions per pool No practical limit
Maximum pool size (created by using at least 4 partitions of up to 2 TB each) 8 TB
Minimum pool size 10 MB
Maximum volume size Up to 8 TB, depending on the pool size and available space in the pool
Maximum file size Up to 8 TB, depending on the volume size and available space in the volume
Maximum number of files per volume Up to 8 trillion, regardless of how many name spaces are loaded

Note: NSS can support this. Browser and application ability can limit this.

Maximum number of files open concurrently 1 million
Maximum number of volumes per server 255 plus the sys: volume.

You can mount NSS volumes beyond 256, but they are not visible or accessible through the normal NetWare APIs.

Minimum server memory to activate a volume Requires only 4 MB available RAM to activate a single volume of any size and any number of files. Loads a file’s metadata into memory only when you access the file.
Software RAID support RAID 0 (striping)

RAID 1 (mirroring)

RAID 5 (striping with parity)

RAID 10 (mirroring RAID 0 devices)

RAID 15 (mirroring RAID 5 devices)

Data shredding Yes, up to 7 times
File compression Yes
Data migration Yes
Directory quotas Yes
User space quotas (user space restrictions) Yes
Salvage or purge deleted files, directories, or volumes Yes
Distributed File Services for moving and splitting NSS volumes Yes
Novell Archive and Version Services Yes
Device maintenance support Activate and deactivate devices by pool.

Novell Storage Services is generally best file system solution for customers migrating file sharing services from NetWare. NSS file systems created on NetWare can be mounted on Linux.

The following characteristics of NSS on OES 2 Linux should be noted in doing your planning:

  • NSS volumes are cross-compatible between Linux and NetWare. NSS data volumes can be mounted on either NetWare or Linux and data moved between them.
  • NSS devices and storage can be managed in the Web-based Novell iManager utility. NSS also supports third-party tools on both platforms for advanced data protection and management, virus scanning, and traditional archive and backup solutions.
  • In a mixed-platform cluster with Novell Cluster Services, NSS volumes can fail over between Linux and NetWare, allowing for full data, trustee, and file system feature preservation when migrating data to Linux.
  • In addition, NSS on OES 2 Linux:
    • Retains all files, rights, meta-data, restrictions, etc.
    • Includes NetWare Trustee access control (richer than POSIX)
    • Retains file system access (NCP)
    • Retains all file system administration and management features
    • Can be easily clustered with Novell Cluster Services (NCS)
    • Is best for shared LAN file serving: excellent scalability in number of files; scales to millions of files in a single directory
    • Supports multiple data streams and rich metadata (its features are a superset of existing file systems on the market for data stream, metadata, namespace, and attribute support)
    • Is journaled

NSS Features Added to OES 2 Linux

The following features have been added to NSS for OES 2 Linux since the initial release of OES 1 Linux.

  • New Location for the NSS Configuration Files
    In this release, NSS configuration files have moved from the /opt/novell/nss/conf directory to the /etc/opt/novell/nss directory.
  • Encrypted Volumes
  • Extended Attributes (XAttr)
  • Group I/O Management
  • Enhanced Hard Links
  • High Memory Management
  • Lightweight Audit Format (LAF) Audit Log Messages
  • Metadata Migration (METAMIG) Utility
  • The Metadata Migration utility is available for OES 1 Linux and later.
  • Novell Archive and Version Services
  • Novell Distributed File Services
  • Pool Snapshots
    Note: Different pool snapshot technologies are used for NSS pools on NetWare and NSS pools on Linux. You can create pool snapshots on either platform, but you should not move them to another platform. Pool snapshots taken on Linux do not work on NetWare, and vice versa.
    Snapshots taken on a given platform are unusable if you move the pool’s devices cross-platform. Before you move a pool with existing snapshots to a different platform, delete all existing snapshots for the pool.
    On Linux, do not use pool snapshots for clustered pools.
  • Support for NSS software RAIDs 5 and 15 has been added for OES SP1 Linux and later
  • User Quotas
  • Linux User Management enhancements
    Changes in NCP Server for Linux now make it possible for file ownership to be tracked for users of NSS volumes on Linux without requiring the user to be Linux-enabled with Linux User Management.

NSS Features Not Implemented in OES 2 Linux

NSS on OES 2 Linux provides an upgrade to NSS on Linux that is comparable to NSS on NetWare. In some cases, Linux is more feature-rich; for example, Linux and Vista Archive Versioning Service clients work only against a Linux server and not a NetWare server. There are, however, a few instances, where some of the supported features are not yet as feature rich as their counterparts on NetWare.

The following NSS features are available for NSS on NetWare but are not supported for NSS on Linux:

  • NSS multiple path I/O to devices. Multipath I/O is not supported on Linux. Instead, use the same Linux multipath I/O management tools you use for Linux traditional file systems. You should configure multipath I/O before using NSS management tools to create NSS software RAIDs, pools, or volumes on devices. For information, see "Managing Multipath I/O for Devices" in the [SUSE Linux Enterprise Server 10 Storage Administration Guide].

The devices used by NSS pools can take advantage of multiple path I/O support only when they are assigned to a NetWare server. The NSS multipath priorities and failover preferences do not apply when the devices are on the Linux server.

  • CD and DVD media and image files. These are handled differently:

On NetWare, CDs, DVDs, CD and DVD image files, and DOS partitions are mounted as NSS volumes. Disks in USB floppy drives are mounted as local DOS FAT partitions.

On Linux, these alternative media and partitions are mounted using Linux traditional file systems options.

For information, see "Some Other Supported File Systems" in the [SUSE Linux Enterprise 10 Installation and Administration Guide].

  • Transaction Tracking System (TTS). TTS is not supported on Linux. On Linux, file content tracking capability is available for Linux traditional volumes (not NSS volumes) when you mount the volume with the Journal mode setting for file system journaling. The Journal mode logs all file system data including the data blocks and the metadata. For information about the journaling capabilities of Linux traditional file systems, see "Major File Systems in Linux" in the [SUSE Linux Enterprise 10 Installation and Administration Guide].
  • Modified File List. The Modified File List attribute for NSS volumes is available only for NSS volumes on NetWare.

The following are treated differently on Linux than on NetWare:

Feature NetWare Linux
File access protocols NCP



NFS and CIFS (Samba) require users to be Linux-enabled with Linux User Management. AFP is available only through third-party software.

Management interfaces Novell iManager

NSSMU for NetWare

Utilities in the server console ( NSSMU, RIGHTS, FLAG)

NSS commands in the server console

Novell Remote Manager for NetWare

Novell NetStorage for NetWare (via Web browser only, not WebDAV)

Novell Client

RIGHTS utility for NetWare

Novell iManager

NSSMU for Linux

EVMS ( evmsgui)

Utilities in the terminal console (NSSMU, RIGHTS, NSSCON, ATTRIB, RAVSUi, RAVVIEW, nbackup)

NSS commands in the NSS Console ( NSSCON)

Novell Remote Manager for Linux (for Dynamic Storage Technology shadow volumes and for managing NCP Server connections to NSS volumes)

Novell NetStorage for Linux (via Web browser only, not WebDAV)

Novell Client

RIGHTS utility for Linux

Pool snapshot

(retain point-in-time version of a pool using block-level copy on write)

  • Allows backup of block-level changes only, without deactivating the volume.
  • Uses a brief freeze-release process to capture information for last remaining open files.
The stored-on pool must be on a separate partition.
Volume encryption You must mount encrypted volumes only from NSSMU on the first mount after a system reboot so that you can enter the password. The NSSCON utility does not support entering a password from the command line.
File system trustees and trustee rights to control access to directories and files Works with or without concurrent running of NCP Server. Requires NCP Server to enforce the rights and access on the extended attributes.
File system directory and file attributes to control functions available for directories and files Files and Folders plug-in to iManager

Novell NetStorage

Novell Clientâ„¢

Files and Folders plug-in to iManager.

See also "Displaying Key NSS Directory and File Attributes as Linux POSIX Permissions" in the OES 2: File Systems Management Guide.

Default mount location for NSS pools Not applicable /opt/novell/nss/mnt/.pools/poolname

Default mount location for NSS volumes Server root /media/nss/volumename

Volume name space Accommodates all name spaces (DOS, Macintosh, Long, and UNIX). Accommodates all name spaces (DOS, Macintosh, Long, and UNIX).

UNIX is the default name space, which is case sensitive. However, you can specify Long name spaces on mounting the NSS volume to make its directory names and filenames case insensitive.

Software RAID support RAID 0 (striping)

RAID 1 (mirroring)

RAID 5 (striping with parity)

RAID 10 (mirroring RAID 0 devices)

RAID 15 (mirroring RAID 5 devices)

RAID 0 (Striping)

RAID 1 (mirroring)

RAID 5 (striping with parity)

RAID 10 (mirroring RAID 0 devices)

RAID 15 (mirroring RAID 5 devices)

RAID 0, 1, 4, 5 and 6. RAID 10 can be created using the mdadm(8) command as a complex RAID using the RAID10 option, or as a nested RAID. For information, see the [SUSE Linux Enterprise Storage 10 Storage Administration Guide].

Novell Distributed File Services

For information, see the OES 2: Novell Distributed File Services Administration Guide.

Supported NSS volumes on OES 2 Linux can contain junctions or be a junction target.

DFS does not support junctions on NCP volumes.

Novell Dynamic Storage Technology

For information, see the OES 2: Novell Dynamic Storage Technology Administration Guide.

Not Supported Available in the initial OES 2 release.

Note: For additional information, see Section F.0, "Comparison of NSS on NetWare and NSS on Linux" in the OES 2: NSS File System Administration Guide.

Traditional Linux File Systems

As the table below indicates, the OES Linux kernel supports a variety of Linux traditional file systems in addition to NSS. In fact, a Linux traditional file system is required for the system volume. The upper level of the kernel deals equally with these file systems through an abstract layer, the virtual file system (VFS).

Linux file systems differ somewhat from NetWare and Windows file systems. This section provides only minimal highlights. If you decide to use any of the traditional Linux file systems, you'll want more detail. Which file system you use largely depends on the purpose you are using the file system for. Some typical Linux traditional file systems and their recommended use are described in the following table:

Linux Traditional File Systems

Linux Traditional File System Description Recommended Use
Second Extended File System (ext2) ext2 is a legacy file system with a solid reputation for simplicity, quickness, and stability. It uses less memory than other options and is sometimes faster.

ext2 does not maintain a journal so it is not recommended for any server that needs high availability. Novell recommends moving to ext3.

ext2 is the right file system for /boot
Third Extended File System (ext3) ext3 has the same data and metadata format as its predecessor (ext2). It is considered the "Linux" file system. It's fast performing and offers options to coordinate its metadata journaling with data writes.
  • Robust and quick
  • Does not scale well to large volumes or large numbers of files (over 500), even with the htrees scalability feature recently added. (htree is not available with OES/SUSE Linux Enterprise Server 9, but is included with OES 2).
  • Journaled
  • POSIX extended access control
ext3 is best for general purpose file and print, and databases such as Oracle, that feature only a few large files.

It is not recommended for GroupWise and other email packages as there are more than 500 files in a folder and GW will not run.

If used for GroupWise, enable the htree feature in ext3.

Reiser File System (ReiserFS) ReiserFS has a solid reputation for its simplicity, quickness, and stability.

It supports metadata journaling, but does not include data journaling or ordered writes. Its disk space utilization, disk access performance, and crash recovery are better than ext2/3.

  • Best performance on Linux given a great number of small files.
  • Outscales ext3 with htrees.
  • Uses disk space efficiently
  • Journaled
  • POSIX extended access controls
Reiser is best suited for collaboration (email), iFolder3, and web-serving applications.

It's designed to transact many small files being opened, read, written, and closed in a short timespan.

The downside is that tools for automatically fixing the file system in the event of a rebuild are not as robust as the NSS pool and volume rebuild

Journaled File System (JFS)

64-bit system

JFS was developed by IBM* to support high throughput server environments (AIX and OS/2) where performance is the ultimate goal; it was ported to Linux to allow for ease of migration of existing data. Performance is excellent across a wide variety of workloads.

This feature-rich system is a full 64-bit file system.

  • Features high performance and scalability
  • Is journaled. Supports both large files and partitions
  • Supports group commit of log entries for multiple concurrent operations, which improves journaling performance
  • Supports a different directory organization for small and large directories
  • Uses space efficiently
  • POSIX extended access controls
Recommended for high-end hardware (64-bit, multiprocessor systems)
Extended File System (XFS)

64-bit system

XFS originated from SGI (Irix) and was designed specifically for large files and large volume scalability. This high-performance system is good at manipulating large files and performs well on high-end hardware.
  • It's one of the few file systems on Linux that supports data migration.
  • Scales to petabyte volumes; handles large amounts of data.
  • XFS takes great care of metadata integrity.
  • Supports independent allocation groups that can be addressed concurrently by the system kernel, which suits the needs of multiprocessor systems.
  • Preallocates free space on the device to reduce file system fragmentation. However, delayed writes can result in data loss if the system crashes.
  • Journaled (an asymmetric parallel cluster file system version is also available)
  • POSIX extended access controls
Recommended for:

Extremely large file systems, large files, and large numbers of files. High-end hardware (64-bit, multiprocessor systems). Video and multi-media files. Note: SGI also offers a closed source cluster parallel version of XFS called cXFS, an asymmetrical model. It's slave nodes can run on Unix, Linux and Windows, making it a cross- platform file system. Its master node must run on SGI hardware.

Best Bets

Collaboration: GroupWise and other email/collaboration solutions typically deal with many little files. Since only the application process accesses the file system, the added overhead of rich ACL and file attributes found in NSS or NTFS is redundant. The characteristics needed are a file system whose performance remains relatively constant regardless of the number of files in the volume, and that performs well with small files. Best bets are ReiserFS and XFS.

Database: MySQL, Oracle, SQL, Progress, etc., typically deal with a few, very large files that are left open most all of the time. Virtually any file system with Direct IO capabilities (APIs that allow the database to directly manipulate the file buffers) can be used. Since databases do not create many files, file systems that do not scale to many files, but still have Direct IO interfaces will work fine. Reiser, ext3, and XFS all are recommended. If you are using MS SQL server, NTFS is required.

Web Services: Web services can encompass a broad set of workloads. For simple web services, virtually any file system can be used. Since these typically don't need rich access control file systems, you can avoid the extra overhead of NTFS or NSS to get slightly better performance. However, if the web services solution leverages identity and requires user security for many people (more than 50 accounts), then NSS is the better choice.

File Serving (NAS): Two NAS use cases need to be considered:

  • Serving files to application servers in a tiered service oriented architecture (SOA).

Minimal access control is required, so choose a file system that is scalable and fast: Reiser, XFS, VxFS .

  • Serving files to end users' desktops and workstations.

Quite heavy access control is required, so the access control and security management capabilities of NSS with CIFS and NCP file access protocols begin to be important.

NSS provides security between users and, at the same time, allows for very granular sharing between given users and groups. NSS includes a visibility feature that prevents unauthorized users from even seeing subdirectory structures they don't have rights to.

For additional information, see Section 1.2, "Linux Traditional File Systems" in the OES 2: File System Management Guide and "File Systems in Linux" in the [SUSE Linux Enterprise Server 10 Administration Guide].

File System and Directory Structure Comparison

Both NetWare and Linux file systems use directories and subdirectories. Linux directories can contain any number of subdirectories:

NetWare Linux
SYS Volume Root File system “/”
  • ETC
  • and so on...
Directories (conform to File system Hierarchy Standard v2.2)
  • var
  • opt
  • bin
  • home
  • and so on

  • NetWare separates directories with a backslash. Linux uses a forward slash.
  • NetWare filenames are not case sensitive. Linux file names are.
  • File names in Linux:
    • Can contain 255 characters.
    • Can include special characters (like *?$) but these are sometimes not useful (for instance, a filename that starts with a $ can be mistaken for a variable).
    • The path, including slashes (/), can be 4096 characters long.
  • File types in Linux include the following:
    • Normal files
    • Directories
    • Links
    • Device Files
    • Sockets
    • FIFOs (first-in-first-out)
  • In Linux
    • The file system is organized in one hierarchical tree.
    • Partitions/volumes do not appear as drives, but are integrated into the file system tree under directories.
    • Users store files in a directory; the operating system takes care of the physical storage, without regard to whether the file is stored locally on a hard drive or remotely on a file server.
    • Every device and hard disk partition is represented in the Linux file system as a subdirectory of the root directory. Directories that are only one level below the root directory are preceded by a slash, to indicate their position and prevent confusion with other directories that could have the same name. For example, the floppy disk drive in Linux might be /etc/floppy.
    • The root directory lives in the root partition, but other directories (and the devices they represent) can reside anywhere.
    • Removable devices and hard disk partitions other than the root are mounted (attached) to subdirectories in the directory tree. This is done either at system initialization or in response to a mount command.

The table below lists some common second-level Linux directories:

Linux Directory Description
/boot Kernel and files needed for booting
/root Home directory of the sysadmin user
/bin System binaries, user programs with normal user permissions
/sbin System binaries/executables that need root permission
/data A user-defined directory
/dev System device files/tree
/etc System configuration files
/home Users’ home directories
/home/username A user’s personal home directory
/tmp System temporary files

(Unix Special Resources)

Applications software, containing another layer of directories:

/usr/X11R6 File of the X Window system

/usr/bin Executable programs

/usr/lib Libraries for programs in /usr/bin and /usr/src

/usr/sbin Programs for system administration

/usr/src Source files, for instance of the kernel

/var System variables (spool directories for mail and print; log and lock files, etc.)
/lib Libraries needed for installed programs to run
/media Mountpoints for removable media
/mnt Mountpoints for temporarily mounted file systems
/srv Data directories for servers
/opt Application directories
/proc Information about the running system. It's created by the kernel on system startup and is not stored on the hard disk
/sys Similar to /proc, this directory contains information about the hardware

Common Linux File Commands

touch Create a file/update access time on a file
cat View a file
more View a file and scroll
less View a file and scroll
head View the first few lines (default 10)
tail View the last few lines (default 10)
ln Create a link
cp Copy a file
mv Move/rename the file

OES Linux File System Hierarchy

As a general rule, OES uses the Filesystem Hierarchy Standard (FHS) for file location, but there are exceptions; you'll want to check each application to determine where its files are located.

Linux File Permissions

File permissions, or rights, with traditional Linux file systems are not nearly as granular as the rights system available with NetWare; however, they should be adequate for most situations.

NetWare File System Rights and Linux Permissions Compared

NetWare Rights Linux Permissions
Supervisor Set UID (Advanced)
Read Read
Write Write
File Scan
Access Control
Execute (file attribute) eXecute

Trustee Rights Management Utilities

NetWare Rights Linux Permissions
NetStorage (browser) NetStorage (browser)
Novell Client Novell Client
Rights utility Rights utility

If you are using NSS volumes, you can use the Trustee Rights Utility for Linux to specify trustee rights for directories and files in NSS volumes on OES Linux. This utility does not provide support for Trustees on Linux file systems or for NSS volumes on NetWare. However, the trustee information does work seamlessly with NetWare if the volume is moved to NetWare.

Traditionally, three sets of permissions are defined for each file object on a Linux system. These sets include the read (r), write (w), and execute (x) permissions or their numerical counterpart (4, 2, 1). In addition, it is possible to set the set user id, the set group id, and the sticky bit.

  • File permissions are assigned in three categories or to everyone (all):

users (u) groups (g) others (o) all (a)

  • The root user receives the permissions available to all three categories of users.
  • Permissions and meanings change depending on whether they are applied to files or directories.

The following tables summarize these concepts:

Permission Definition for Files Definition for Directories
Read (r or 4) Allows a user to open and read the contents of a file Allows a user to list the contents of the directory (if they’ve also been given execute permission)
Write (w or 2) Allows a user to open, read, write to, and edit file contents Allows a user to add to or remove files from the directory (if they’ve also been given execute permission)
Execute (x or 1 ) Allows a user to execute the file in memory (if it is a program file) and shell scripts Allows a user to enter the directory and work with directory contents.

Additional File Permissions
SUID File executes with the permissions of the user who owns the file No effect
SGID File executes with the permissions of the group that owns the file All files and sub-directories owned by the Group owner.
Sticky Bit No effect Files and sub-directories can only be deleted by the owner or root.

For example,

  • In order to remove a file, you must have write permission to it.
  • In order to view the contents of a directory (see what files it contains), you need read permission for that directory.
  • In order to access a file (read from it, write to it, or execute it) in the directory, you need execute permission for the directory.
  • File permissions can be assigned with the chmod command (which accepts either letters or numbers to represent users, groups, and others) as indicated in the table below.
  • If the numbering system is used, 655, for example:
    • The first number in the group of three is the user's accumulative rights (r+w+x).
    • The second number is the group's accumulative rights.
    • The third number represents others accumulative rights.

Linux File Permission Examples Using Either Letters or Numbers

chmod g+w file Add write permission for the group to the file
chmod o-r file Remove read permission for others
chmod a+r file Assign all (user, group, others) only read permission, no matter what permissions they had before
chmod 644 file Assign read and write (4+2) for the user (the first number), read (4) for the group (the second number) and read (4) for others (the third number)
chmod 755 file Assign read, write, and execute (4+2+1) for the user, read and execute (4+1) for the group and for others
chmod 755 dirA Grant permission to list contents, create files and change into dirA for the user; group and others may not create files in dirA.

File Permission Scenario


Assume a directory has permissions of 777.

When user root goes to this directory and creates a file, this file now has permissions of 644 (_rw_r__r__).

Some assume that irrespective of what the parent directory permissions are, users in the Other category can only read the file created by root and would not be able to write to it or delete it. But, in this scenario, only the parent directory's permissions are evaluated. The permissions set at the file level are over-written. As a result, anyone can delete or write to the file created by root.


If users (owner, group, or other) have write rights to the directory, they can delete any files in that directory—regardless of the file level rights. To avoid this problem, turn on the sticky bit. (In this case, this means setting permissions of 1777 on the parent directory.) This prevents users from deleting files unless they are also the owner of the file.


The first column of the long directory list shows the access characteristics of a file, in the form of 10 flags, e.g. drwxr-xr-x.

Flag Descriptions

Position 1 File type: d (directory)

- (ordinary file)

l (symbolic link)

Position 2-4 Permissions for the user/owner (u): r (read)

binary 4

w (write)

binary 2

x (execute)

binary 1

Position 5-7 Permissions for other users in the same group (g):
Position 8-10 Permissions for all other users (o):

Note that a hyphen (‘-’) denotes lack of the given permission type. For example, r-x means that read and execute permission are granted, but not write permission.

Access Control Lists in Linux

The traditional permission concept for Linux file system objects is adequate for most practical cases. However, for more complex scenarios or advanced applications, permissions can be expanded with POSIX file ACLs (access control lists).

ACLs allow permissions to be assigned to individual users or groups even if these do not correspond to the original owner or the owning group. They are a feature of the Linux kernel and are currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS.

For example, when you replace a Windows server with a Linux server, some of the connected workstations may continue to run under Windows even after the migration. In this case, the Linux system offers file and print services to the Windows clients via Samba which supports access control lists. User permissions can be configured both on the Linux server and in Windows with a graphical user interface (only Windows NT and later).

Note: For an OES Linux server, you can control access to services locally or with eDirectory.

For additional information, instructions for setting ACLs, and example scenarios, see Section 14, "Access Control Lists in Linux" in the SUSE Linux Enterprise Server 10 Installation and Administration Guide.

File Ownership

  • File ownership can only be changed by the root user.
  • Group ownership can changed by the root user or by the file owner, but only for groups the owner is a member of.

Example Ownership Commands

chown Change owner of a file/directory
chown user file Change owner of a file to a user
chown file Change owner to user and group
chgrp Change the owning group

Planning File System Migration

Use collection tables to gather the information you need to plan the file services migration:

  • Will you be using NSS, traditional Linux file services, or a mix?
  • Do you plan to implement Samba, iFolder, or NetStorage?
  • How many servers will be needed and which file system will be installed on each?
  • Will the eDirectory LDAP server be hosted on the same server as the file services?
  • Will other OES 2 Linux services be hosted on the same machine?
  • What file system rights and permissions will be needed? Are default Linux permissions sufficient?

Sample Collection Table

Server Location File System Type Hosted Services Rights Needed Samba

iFolder NetStorage

Server1 SW Office ReiserFS GroupWise r-w-x
Server 2 SW Office ReiserFS Operating System r-w-x
Server 2 SW Office ext3 Oracle r-w-x
Server 3 Baltimore NSS file/print full Samba



Plan the File System Layout

Consider the following:

  • Protect the server's root file system.
  • Partition off anything that users can write to as well as logs and cache.
    • /var
    • /home
    • /var/opt/novell/ifolder3
      • Protect the DIB set
        Create a partition for /var/nds/dib. All core dumps are saved here, so allow at least 2GB.

      Identify Needed File System Components

      You'll need to determine which file service features best meet your requirements. All file system features in OES 2 Linux are mutually compatible; you can install NSS on OES 2 Linux, use traditional Linux file systems (ext3, ReiserFS), or use a mix.

      In addition, the following file system components are available and need to be assessed if they will be included:

      • iFolder3
      • Samba
      • NetStorage

      RAM. Only iFolder3 requires additional RAM.

      Disk Space. For the file services you plan to install, compute the total additional disk space required (above the basic system requirement). Refer to the following for rules-of-thumb.

      • iFolder: Plan for 15 MB as well as storage for the user data for all iFolder user accounts. As a guide, multiply the expected number of users times the storage quota to be allotted for each iFolder user account. Allow for growth as well.
      • Samba: Allocate enough additional disk space for the partition containing the /home directory to meet your users’ file storage needs.
      • NetStorage: There are no disk space requirements associated with NetStorage since it only provides access to other file storage services.

      Other Considerations. Refer to the documentation for each service to gather any additional information before installing the service.

      Plan the NSS Implementation

      As you plan your NSS implementation, the following file system guidelines should be noted:

      • You can move NSS volumes cross-platform to a Linux server and vice versa; However, you should not move an NSS system (SYS:) volume from NetWare to Linux unless you intend to use it as a data volume (or not at all) while it is mounted on the Linux server.
      • If you move an NSS system pool cross-platform, any volumes it contains function as data volumes on Linux, including the sys: volume.
      • NSS volumes that were originally created on NetWare can be moved cross-platform to Linux. But only volumes that were originally created on NetWare can be moved back from Linux to NetWare.
      • On Linux, users of the NSS volume must be Linux enabled with Linux User Management in the following situations:
        • If the user accesses the data via any non-NCP protocol such as Samba/CIFS.
        • If the user needs to use any Linux service or utility to access the data, such as FTP. For additional information, see Section 22.2, "Access Control Issues for NSS on Linux" in the [OES 2: NSS File System Administration Guide].
      • You can move storage devices containing NSS volumes between NetWare servers and OES 2 Linux servers. When you move an unshared device to a different server, you must decommission its volumes in eDirectory for the current server, then recommission them for the new server. For shared NSS pools and volumes, Novell Cluster Services provides this service automatically.
      • You cannot install the Linux operating system on an NSS volume. OES 2 Linux requires a Linux traditional file system volume for the operating system, such as Ext3 or ReiserFS. Use NSS on Linux for data pools and volumes.
      • You cannot SAN boot cross-platform.
      • You cannot move Linux traditional file systems cross-platform to a NetWare server.
      • You cannot create or mount Linux traditional file systems on a NetWare server.
      • You cannot install the NetWare operating system on a Linux traditional file system volume nor on an NSS volume on Linux.
      • NSS pools that are a source pool or a destination pool for NSS pool snapshots on NetWare cannot move cross-platform if you want to keep the pool snapshots. A pool snapshot is no longer available if you move its source pool or destination pool to a Linux server. The snapshot no longer works even after you move the pools back to NetWare.
        Before you move an NSS pool cross-platform, make sure you delete any of its snapshots stored on other pools and any snapshots for other pools it might contain.

      Identify NSS Coexistence and Migration Issues

      For a complete discussion of the issues involved in the coexistence and migration of Novell Storage Services for OES 2 that might affect your planning, see the following sections in the [OES 2: NSS File System Administration Guide]:

      • Section 6, "Cross-Platform Compatibility Issues Between NetWare and OES 2 Linux"
        Discusses pool snapshots, NSS volumes and features, file access, and management tools
      • Section 7.0, "Migrating NSS Devices from NetWare to OES 2 Linux"
        Includes guidelines for moving NSS pools and volumes between NetWare and OES Linux servers and instructions for moving both clustered and non-clustered devices from previous versions of NetWare and OES1 Linux

      Additional Information

      Refer to the following sections in the [OES 2: NSS File System Administration Guide]:

      • Section F.0, "Comparison of NSS on NetWare and NSS on Linux"
      • Section G.0, "Comparison of NSS on NetWare and the NetWare Traditional File System"
      • Section H.0, "Comparison of NSS for Linux and Linux Traditional File Systems"
      • For information about installing and configuring NSS, see Section 3.0, Installing and Configuring Novell Storage Services.
      • For guidelines and instructions about upgrading the media format of NSS volumes to use hard links, see Section 5.0, Upgrading the NSS Media Format.
      • For guidelines about setting up NSS volumes and services on a virtual server, see Section 4.0, Using NSS in a Virtual Guest Server Environment.
      • For management tools overviews and quick references, see Section 8.0, Management Tools for NSS.
      • For information to help you plan storage services to use with the NSS file system and services, see Section 9.0, Planning for NSS Storage Solutions.

      Installing NSS on Linux

      Important: Although the NSS kernel modules are included in SLES 9 and later, they are not usable without OES 2 because NSS is a unique file system that is tightly integrated with identity management. The root user is the only local user who can see NSS volumes on an OES Linux server. NSS needs Linux User Management (LUM) and Novell eDirectory to establish non-root connections to the volume. It is OES that provides Linux User Management, eDirectory, Novell Core Protocol Server, and volume and user space management tools that make NSS volumes usable on an Linux server.

      The reasons the NSS kernel module ( km_nss) and its sources are delivered with SUSE Linux Enterprise Server 9 and later include the following:

      • Kernel modules need to be open-source to meet the GPL requirements.
      • If a customer adds a kernel patch for some third-party module, application, or service, the NSS sources must be in the kernel code in order to get recompiled with the patch. Otherwise, an OES deployment using NSS would break.

      To install NSS on Linux, include the NSS pattern install when you install the OES 2 Linux server. Make the following selections:

      1. Select EVMS as the volume manager. If you are installing OES 2 Linux on a system with a single device and plan to create NSS volumes, that device must be managed by the Enterprise Volume Management System (EVMS) volume manager instead of the default Linux Volume Manager 2 (LVM2). You should also choose the EVMS install option if you plan to use free space on the system device to create NSS volumes. The volume manager for the system device is configured in the Partitioning section of the Installation Settings for the YaST install.
      2. Install the NSS pattern.
        1. a.On the Installations Settings page in the YaST install, click Software to go to the Software Selections and System Tasks page.
        2. b.From the OES Services options, select Novell Storage Services.

        3. The following additional OES 2 services are automatically selected:

          • Novell Backup / Storage Management Services
          • Novell eDirectory
          • Novell Linux User Management
          • NCP Server / Dynamic Storage Technology
      3. Install iManager somewhere in the same tree as the NSS server.
        • Same server. If you install iManager and NSS on the same server, the storage-related plug-ins are automatically installed.
        • Different server. If you install iManager on a different server, make sure you install the storage-related plug-ins needed to manage the NSS file system and services. See Section 8.1, "Novell iManager and Storage-Related Plug-Ins in the OES 2: NSS File System Administration Guide.
      4. Enable NSS.
        When you install NSS during the initial install, NSS is enabled automatically.
      5. Create a Linux Identity for Users
        In order to use Linux services and utilities on an OES 2 Linux server, eDirectory users must also have a Linux identity. The Linux User Management (LUM) technology creates the local user identity and stores the UID for the user in eDirectory.
        You don't need to Linux-enable users unless you plan to use the following NSS capabilities:
        • User quotas
        • Hard links
        For information about how to Linux-enable users, see the [OES 2: Novell Linux User Management Technology Guide].
      6. Upgrade the media format for hard link support (optional).
        The new hard link support in NSS requires a media format upgrade after you have installed or upgraded the operating system. For guidelines and media upgrade instructions, see Section 3.5, "Upgrading the NSS Media Format" in the [OES 2: NSS File System Administration Guide].

      Additional Information

      For additional information on installing NSS on Linux, see the following sections,in the [OES 2: NSS File System Administration Guide]:

      • Section 9.0, "Planning for NSS Storage Solutions"
      • Section 3.0, "Installing and Configuring Novell Storage Services"
      • Section D.1, "Installing Linux with EVMS as the Volume Manager on the System Device"

      You can also install NSS after the OES 2 Linux install by selecting NSS from the software options in YaST.

      EVMS Requirement

      OES 2 for Linux requires EVMS to understand and manage NSS partitions. However, the Linux kernel won't allow EVMS to manage LVM partitions and volumes, so LVM installs by default. Thus, the disk(s) where the boot partition (such as /boot for Grub) and system partition (such as for the swap and / ( root) volumes) reside are typically unavailable to NSS. This means that single drive servers require additional configuration to include both Linux system volumes and NSS on the same drive.

      The device where you want to create NSS volumes must be managed by EVMS if you plan to use the Storage plug-in to iManager or NSSMU to create and manage NSS partitions, pools, and volumes.

      To create an NSS data volume on the same device as your boot partition or system partition, make sure to configure the device for EVMS during the install. For information, see Section A.0 "Installing Linux with EVMS as the Volume Manager of the System Device" in the [OES 2: Linux Installation Guide].

      When your data volumes are on non-system devices, do not configure devices during the install. Instead, leave the devices as unconfigured free space and do not assign a volume manager for them. After the install, create the volumes with NSSMU or the Storage plug-in to iManager.

      Migrating NSS Data and Devices from NetWare to Linux

      Two primary tools are recommended for migrating file system data (including NSS data) from NetWare to Linux:

      • Command Line Utilities (migfiles)
      • The File System Migration Tool

      Prerequisites for both source and destination servers are the same for either method.

      Before beginning the migration, make sure you understand "Section 7.0, "Migrating NSS Devices from NetWare to OES 2 Linux" in the OES 2: NSS File System Administration Guide. This section includes the following subsections:

      • Section 7.1, Guidelines for Moving Devices Cross-Platform
      • Section 7.2, Moving Non-Clustered Devices From NetWare Servers to OES 2 Linux Servers
      • Section 7.3, Moving Non-Clustered Devices From NetWare 6.0 to OES 2 Linux
      • Section 7.4, Moving Non-Clustered Devices From NetWare 6.0 to NetWare 6.5 or OES NetWare
      • Section 7.5, Moving Clustered Devices with NSS Volumes Cross-Platform
      • Section 7.6, Upgrading NetWare 5.1 NSS Volumes and NetWare Traditional Volumes to NSS Volumes

      NSS Migration Prerequisites

      Source NetWare Server

      1. Upgrade previous versions of NetWare (and Linux) as necessary: Migrating Data from Previous Versions of NetWare. If you have data you want to migrate on servers running older versions of NetWare (such as NetWare 5.0 or 6.0), you must first upgrade the servers to NetWare 5.1 SP8 or NetWare 6.5 SP6 and then use the OES Migration Tools 1.0 or SCMT 1.2 to migrate the data.
        • To upgrade Legacy NSS Volumes: Mount the NSS volume on a NetWare 6. x server. The mounting process starts the upgrade which takes some time (often several days; however the process runs in the background).
          Leave the upgraded NSS volume mounted on NetWare 6.x afterwards since the media format is not backward compatible with NetWare 5.1 servers.
        • To convert traditional NetWare volumes to NSS volumes: Use the Volume Copy Utility to upgrade legacy NetWare 5.1 Traditional volumes to NSS volumes on NetWare.
          Note: After upgrading a NetWare server to OES NetWare, it is possible for a Traditional volume to still reside on that server, but this creates a problem when migrating from NetWare to OES Linux because the Traditional volume data cannot be read on OES Linux. You should move the data from the Traditional volume to an NSS volume before upgrading, either by directly copying it, using the Volume Copy Utility (VCU), or using the Server Consolidation and Migration Tool (SCMT).

        For additional information, see Section C.O, "Upgrading Legacy NSS and NetWare Traditional Volumes" in the [OES 2: NSS File System Administration Guide].
        Migrating Data from OES 1.0 Linux. If you have data you want to migrate on OES 1.0 Linux initial release or SP1 servers, you must first update to SP2 and apply the latest OES patches and then use the OES Migration Tools 1.0 to migrate the data.

        See section 2.0, "Migrating Data from NetWare or OES 1 Linux to OES 2 Linux" in the [OES 2: Migration Tools Administration Guide for migration instructions].
      2. Migrate Upgraded NSS Volumes to OES 2 Linux. Mount NSS volumes from NetWare 6.5 SP3 and earlier directly onto OES SP2 Linux and earlier. You can mount NSS volumes from NetWare 6.0 servers directly onto OES SP2 Linux servers.
      3. Make sure the media format is consistent with the format that will be used by the destination server. (If you will be taking advantage of the new media format on the destination server that allows hard links, see Section 5.0, "Upgrading the NSS Media Format" in the [OES 2: Migration Tools Administration Guide] before proceeding. You can move NetWare 6.5 SP 4 or later NSS media to an OES 2 Linux server if the operating platform can support the NSS media format. NetWare 6.5 SP3, OES 1 SP2 Linux, and earlier servers do not have this support.
      4. Ensure that the latest version of Storage Management Services (SMS) is running on the source NetWare server. SMS updates can be downloaded from the Novell Downloads Web site.
      5. When migrating data from a Traditional NetWare volume, make sure all name spaces (DOS, LONG, NFS, and MAC) are loaded on the source NetWare server. If the source server is running NetWare 5.1 SP8 and your data contains extended ASCII or Unicode characters, add the following setting to the /etc/opt/novell/sms/tsafs.cfg file:
             useCodeSet= xxx
        For xxx, substitute the code page value set on the NetWare server. For example, the default code page is 437. (Alternate forms include CP437, CSPC8CODEPAGE437, and IBM437.) For more information and a list of code page values, see “Code Pages” in the NetWare 5.1 Server Operating System Guide.
      6. Restart SMS by running the following command:
             rcnovell-smdrd restart
      7. Although data on the source server is not deleted as part of the migration, you should make a current backup of the data as a precaution. A module named tcnvlnx.nlm is copied to the SYS:system folder of the source NetWare server and a tcnvlnx.cfg configuration file is also created in the same folder. The module generates an output file containing a listing of files, directories, and associated trustees. This output file in stored in the SYS:system/tcnvlnx directory.

      Destination OES 2 Server

      You'll need to install NSS on the OES 2 Linux destination server before moving devices (shared or unshared) or data from NSS on NetWare to NSS on Linux.

      The following prerequisites must also be met on the destination OES 2 Linux server.

      For NSS Destination Volumes

      1. Use the Novell Storage Services Management Utility (nssmu) or iManager to create the NSS volumes to which you will be migrating the data. Make sure you allocate sufficient space for the volume to hold all of the source data.
        Make sure the destination volumes have properties similar to those of the source volumes. For example, if compression is turned on for the source volume, turn on compression for the destination volume as well. The same applies to user quotas and other NSS features.
      2. (Conditional) If you want to use the CASA secret store to store usernames and passwords during the migration (via the--use-casa option),
        1. Make sure the following RPM is installed on the OES 2 Linux server:
               CASA-1.7- xxx.i586.rpm
        2. Restart the CASA daemon by entering the following command:
               /etc/init.d/miCASA restart

        For more information, see "Using CASA with Linux" in the Novell Common Authentication Services Adapter (CASA) documentation.

      For NCP Destination Volumes

      If you have installed the NCP server for Linux, you can create NCP volumes on top of Ext3 or Reiser file systems on Linux. NCP allows you to use the same method of file system trustees and trustee rights to control access to data on Linux Traditional volumes as you use on NSS volumes and NetWare Traditional volumes.

      Since both NSS volumes and NCP volumes use the Novell trustee model for controlling access to data, if you migrate data from an NSS volume on NetWare to an NCP volume, the trustees and trustee rights are enforced. You will need to make sure trustees are authorized users of the destination server

      • NCP Server must be installed and running on the OES 2 Linux server.
      • Linux User Management must be installed and enabled.
      • Users must be Novell eDirectory users that are Linux enabled for the server

      Be aware of the following:

      • User Quotas. NCP volumes do not support user quotas. If they are set on the NSS volume, they are not enforced on the NCP volume.
      • Deleted Files. NCP volumes do not support deleted file salvage and purge. If you have deleted files on the NSS volume, they are not migrated. If you want to salvage deleted files, do it before you migrate the data.
      • Encryption. NCP volumes do not support volume encryption. If you migrate data from an encrypted NSS volume, the data is not encrypted on the NCP volume. Novell strongly recommends not migrating data from an encrypted NSS volume to an NCP volume.

      Note: Moving files is now supported between NCP volumes. For example, you can move a file from an NCP volume on NSS to an NCP volume on a Traditional Linux file system. Trustee rights to files are maintained. However, file attributes unique to NSS, such as those associated with quotas and salvaging, are lost if the target volume is not NSS. In addition, NSS file attributes can now be set on NSS volumes from an NCP client.

      If you will be moving NSS data to NCP destination volumes, complete the following:

      1. 1.Use the NCP Server Console utility (ncpcon) to create the NCP destination volumes.
      2. 2.Make sure the user performing the migration (usually the eDirectory admin) has read/write access to the POSIX path that corresponds to the NCP volume. One way to ensure this is to make admin the owner of the POSIX directory where the NCP volume is created.
        See Section 4.0, "Migrating Data from NSS Volumes to NCP Volumes" in the OES 2: NCP Server for Linux Administration Guide for detailed instructions.

      Moving Devices

      NSS supports moves of devices containing NSS volumes between any servers that support a compatible media format, including moves between NetWare servers and OES 2 Linux servers.

      The OES 2: NSS File System Administration Guide includes a table specifying which operating systems can be moved cross-platform between servers in the same Novell eDirectory tree. See "Table 5-1 Cross-Platform Compatibility of NSS Volumes by Operating Platforms." Links are also provided to examples of each category of move.

      • Unshared Devices. When you move an unshared device to a different server, you must decommission its volumes in eDirectory for the current server, and then recommission them for the new server in order to preserve the NSS pool and volumes on the device when you move it.
        • Decommission the volume by removing its related Storage object from eDirectory for the original server.
        • Recommission the volume by creating a new Storage object in eDirectory for the destination server.

      When moving a non-clustered device, you must also move any other devices that contribute segments to the NSS pools on the device you are moving.

      • Shared Devices. When you move shared devices cross-platform, Novell Cluster Services automatically manages Storage object updates to eDirectory. You can use a shared NSS data pool and volume in a mixed cluster configuration, using Novell Cluster Services for Linux, if all nodes in the cluster support the same NSS media format.
        • For information about upgrading to the latest media format, see Section 5.0, "Upgrading the NSS Media Format" in the OES 2: NSS File System Administration Guide.
        • To use NSS with Novell Cluster Services, see the OES 2: Novell Cluster Services 1.8.4 for Linux Administration Guide.

      Setting Up File Access for Users

      File access for users on the OES 2 Linux server can be set up either before or after you move an NSS volume from NetWare to Linux.

      • Same tree. File system trustees and trustee rights continue to work after the move.
      • Different tree. Use eDirectory to enable or reassign affected users for access in the destination tree.

      One of the following protocols and services must also be set up and configured:

      • NCP Server and Services: Install and configure NCP Server to allow users to access the volume with the Novell Client or other NCP services. For information, see the OES 2: NCP Server for Linux Administration Guide.
      • Other Protocols and Services: Install and configure other protocols, such as Samba or NFS as needed.

      If you use non-NCP protocols or Linux services for user access on the destination OES 2 Linux server, you must Linux-enable the current users of the volumes with Linux User Management before you move the devices if you want file ownership information to be usable after the move.

        • To enable multiple users at once, use the nambulkadd command. User IDs are automatically refreshed after the enabling process ends.
        • To enable a single user at a time, use iManager.

      Deactivating and Reactivating Pools

      For each NSS pool, decommission the pool and its volumes on the original server and reactivate them on the destination server. See the following sections in the OES 2: NSS File System Administration Guide.

      • Section 7.2.3, "Decommissioning Each NSS Pool and Its Volumes on the Original Server"
      • Section 7.2.4, "Recommissioning Each NSS Pool and Its Volumes on the Destination Server"

      Migrating NSS Data

      NSS data can be migrated to OES 2 Linux from NSS volumes on NetWare using the command line or GUI migration tools provided with OES 2 Linux.

      • Migrating Data with Command Line Tool (migfiles). If you are using the command line tools, the procedures for migrating file system data from NetWare NSS or Traditional volumes varies depending on whether the source and destination servers are in the same eDirectory tree or in different trees.

      See Section 2.2, "Using the Migration Commands" in the OES 2: Migration Tools Administration Guide for detailed instructions.

      • Migrating Data Volumes with the File System Migration Tool. When you install an OES 2 Linux server, the File System Migration tool is automatically installed in YaST. This tool lets you perform basic data migrations from NetWare or OES 1 Linux to OES 2 Linux using a graphical user interface (GUI) instead of command-line utilities.

      The File System Migration tool supports only full volume migrations. Source volumes on OES1 Linux servers must be NSS volumes. Access the tool from the graphical desktop at the destination OES 2 Linux server, by selecting Computer > YaST Administrator Settings > Open Enterprise Server > File System Migration Utility.

      See Section 2.3, "Using the File System Migration Tool" in the OES 2: Migration Tools Administration Guide for detailed instructions.

      Additional Information

      • For a general discussion of migration issues in OES 2, see "Migrating and Consolidating Existing Servers and Data" in the OES 2: Planning and Implementation Guide.
      • For guidelines about users and access, see Section 22.2, "Access Control Issues for NSS on Linux" in the OES 2: NSS File System Administration Guide.

      Post Migration Procedures

      Restore Rights and Ownership

      After files are transferred, file permissions may need to be reset. As discussed earlier, Linux file system permissions are different from and not as granular as those used by NetWare or Microsoft Windows systems. This becomes extremely apparent for directories where multiple groups previously had access to the data within a file. On Linux file systems, this is not possible so an alternative must be found. Novell recommends the following permissions as a starting point. You may need to change the permissions to better fit your needs.

      Type of files Permissions:

      user group other


      numeric value

      Home directories (ex: /home/<userid>) rwx --- --- 700
      User files (ex: /home/<userid>/<myfile>) rw- r-- --- 740
      Share directories for a team (where the group is used for access.) rwx rwx --- 760
      Shared team files (where the group is used for access.) rw- rw- --- 660