Domain – Getting “403 – Forbidden: Access is denied” when hitting the URL without “www” prefix

One of the reasons why you need www or some other subdomain has to do with a quirk of DNS and the CNAME record.

Suppose for the purposes of this example that you are running a big site and contract out hosting to a CDN (Content Distribution Network) such as Akamai. What you typically do is set up the DNS record for your site as a CNAME to some akamai.com address. This gives the CDN the opportunity to supply an IP address that is close to the browser (in geographic or network terms). If you used an A record on your site, then you would not be able to offer this flexibility.

The quirk of the DNS is that if you have a CNAME record for a host name, you cannot have any other records for that same host. However, your top level domain example.com usually must have an NS and SOA record. Therefore, you cannot also add a CNAME record for example.com.

The use of www.example.com gives you the opportunity to use a CNAME for www that points to your CDN, while leaving the required NS and SOA records on example.com. The example.com record will usually also have an A record to point to a host that will redirect to www.example.com using an HTTP redirect.

Try logging onto a computer as your Veritas user and confirm you are in fact able to browse to the data you're trying to back up, and try copying something from the network share to the computer. Also check you can browse to the NAS share and create files on that.

On your Backup Exec Media Server, try and browse to the root of \\NSS324. I don't know about this particular NAS, but if it's a Linux based NAS, I have seen those sometimes either not register themselves in DNS properly (or at all) or they don't consistently answer to their assigned name. If that doesn't work, you might want to try a fully qualified name (i.e \\NSS324.corp.acme-widgets.com (obviously replace that with your actual FQDN)).

In your B2D media, there is no need to map the share on the NAS to a Windows drive letter - Backup Exec will be perfectly happy with simply \\NSS324\IT_Admin\Backup.

I've experienced some idiocy from the Backup Exec interface before, where it claimed the user I has specified as the backup user didn't have enough permission (when it really did). If I ran the job manually, it backed up everything and the job completed successfully (confirmed with a restore).

I've also found any errors in the Backup Exec job log are more useful than the error messages you get when setting up a job. It might be worth setting up the job and ignoring any permission errors you get and run it anyway so you can interrogate the job log. Any errors or warnings in the job log generally point to a Symantec KB article, which admittedly isn't always helpful, but might prompt you to think about something you maybe overlooked.