Description: We have migrated from a linux file server providing access to linux, solaris & NT clients via NFS & samba to an F740 filer running Release 5.3.7R2 . Our goal is to replicate the environment on our old system while taking advantage of as many of the new features the NetApp as possible.

We have run into a challange in the area of quotas: because of the way our old environment was set up, we have one qtree with several subdirectories, however we want to manage quotas at the level of the subdirectories. Currently, these type of quotas don't seem to be supported.

Background: The old system provided file sharing of user home directories & a common files system through nfs & samba.

On the unix side, the common file system consisted of a top-level directory (/common) containing symlinks pointing to several partitions with the actual files (e.g., /files1/common.build would be linked as /common/build). Clients acessed these files using amd & a symlink from /common to the exported directories path (/mnt/nfs/server/common), This provided the advantage of monitoring (with df) and limiting file system usage within projects and groups.

On the NT side, samba managed symlinks & acess permissions in such a way that the server simply provided a share called "common" from /common. Users could, for example, access files from \server\common\build although samba did not directly share out /files1/common.build - \server\common\build was visible to users, but \server\files1\common.build was not. This made the servers share list shorter & simpler for NT users to understand.

Today on the NetApp, we have a qtree at /vol/vol0/common that contains all of the directories fromerly linked to /common on the linux server. Unix clients link from /common to this directory, replicating the experience on the old server. NT clients access these files as a share as before.

There are two disadvanteage to this arrangement: (1) we cannot take advantage of the many features that would be provided if the directories under /common were qtrees. On the old system we were able to monitor & limit file system usage be keeping projects & departments within discrete partitions. qtrees would provide this advantage. (2) Future expansion is complicated because /common is isolated to one volume: if we were to add a second volume, we would need to provide two parallel shares to provide access to NT clients.

We'd like to know: (1) what we could do differently to make this all work; and (2) what features of the filer we might be unaware of that would simplify this setup (e.g., qtrees within qtrees?.