> Depends on what philosophy you subscribe to- if it's on a local system
> only, then create a group for members that will need access to it, and
> create a directory in the /home tree, like /home/'project_foo
> If it's going to be NFS mounted by other systems, then create an /export
> directory and put it similarly in there, which has the convenience as
> you change your filesystems (and you will...) and perhaps share more
> directories, or add more disk, you can keep them 'centrally' located (or
> mounted) under a single top level directory..  Unless your /var
> filesystem is _huge_ (or on the same filesystem as /, ick!), I wouldn't
> put anything to be shared in the /var tree...(as already mentioned).
> Likewise, /usr is meant to be capable of being mounted read-only, and
> contains (generally) static binaries and libraries required for full
> multi-user (read this as networked) mode operation of the system, so I'd
> abstain from using /usr either.
> Scott

Thanks for this Scott. The files are going to be NFS mounted by Linux 
workstations and SMB mmounted by Windows workstations, so I guess that 
/export is the right place. I will make this a separate filesystem.

I currently have separate filesystems for /, /tmp, /usr and /var. Considering 
your comment about /usr being mounted read-only, why is /home a link to 
/usr/home when hme obviously contains variable data? If I use a new 
filesystem for /home, should I mount this at /home and make /usr/home a link 
to /home, or do I just mount it at /usr/home?


[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to