By default, you cannot access LUNs through any shares, NFS or CIFS. Use the 'lun share' command to change this. However, I don't think this is the method you want to use for backing up your LUNs. 1. Backup performance will be less than optimal and 2. I don't think you will have a usable LUN when you restore it. We use snapvault to backup up our LUNs then we use a backup application that supports ndmp backups. Our backups to tape are then done at the volume level and not the file or qtree level. This provides a significant performance improvement. The only thing we have to do when restoring a LUN is ensure the qtree the LUN will be restored to exists as the software will create a folder instead of a qtree and LUNs can only exist in the root of a volume or in a qtree.

If you do succeed in backing up a LUN through a share, try restoring it elsewhere and see if it seen as a LUN by the filer. Likely it won't. If you don't want to do ndmp backups, then probably best to mount the LUNs and use Backup Exec to do regular Windows type backups of the contents.

On 9/28/07, John Sfetsoris John@ivisinfo.gr wrote:

hello everybody we have several luns that cannot be backued up from veritas backup exec. These luns are mounted via cifs and had initally security style unix, that recently changed to ntfs (before starting backup proccess), therfore we cannot change the lun share from "none" to"read" in order to make them capable to be backed up (the command returns "read only file system"). Plz note that these luns are snapvault destination (no snapvault destination is running during the backup proccess). Has anyone any knowledge or a workaround in how to make the lun share "read" , and what else needs to be done , to be able to backup the luns thnks in advance John