Issues with Remote Agent for Mac on 10.7.5: cannot access root level of drive

[ahdtech]

I have installed RALUS_RMALS_RAMS-1798.17 on a serverized Mac OS X 10.7.5 virtual machine for my client. The person in charge of maintaining the company's Backup Exec 2012 server informs me that he is able to authenticate to the remote agent as root, but is unable to access the root level of the file system. He suspects that there is some permissions issue on the Mac side that might be interfering with the agent's ability to do so.

The beremote process is running and owned by root.

Just throwing this out there, but notice that /opt, /private, and several directories enclosed within /private are, after running the installer, owned by uid 10001, gid 110. Neither of these seems to actually correspond to a user or group on the computer.

Any assistance would be much appreciated with this.

[Backup_Exec1]

Hi

Please check the link below the above version listed for MAC is not a part od SCL

http://www.symantec.com/docs/TECH175581

Check page no 19 /54

Thanks

[ahdtech]

Hi Sameer, and thanks for your quick reply.  I'm not wholly certain how I'm meant to read this chart. Isn't the presense of 10.7 on the chart indicative of support? Are you saying that 10.7 isn't supported at all, or is it that only some versions of 10.7 are supported (and, if so, which)?

I must say: I was already shocked that you don't yet support Mac OS X 10.8. I hope you won't tell me that you still have not provided support for 10.7.

[Backup_Exec1]

Hi

From the SCL I see that 10.7 is supported but updates after it is not mention in SCL

Also if you see the point 1 above the table "1. All MAC OS X 10.6 supported up to and including the most recent patch level." same is not idicated for 10.7 patches

Can you please add the root account in beoper group and also give additionall permission to agent directory of backup exec as it has limited rights

Additionally check this too see if that helps

http://www.symantec.com/docs/HOWTO23460

Thanks
 

[ahdtech]

Thanks again for your quick reply on this Sameer, and your willingness to work with me on this.

Should the rams installer have created a "beoper" group, because there isn't one on my system. Should I create one? Is that what the mysterious, unattached gid that I'm seeing in my permissions is supposed to be? i.e.:

drwxrwxr-x@   3 10001  110            102 Jan  8  2012 opt

drwxrwxr-x@   6 10001  110            204 Jan  8  2012 private

By "agent directory" do you mean /opt/VRTSralus?

The description in the first table row in the link that you provide ("The Remote Agent is installed on a Macintosh system in a NIS domain, but Backup Exec is unable to browse resources on the system.") sounds like exactly the problem that's being described to me, though I don't believe we're using a NIS server. Is that an essential component? We haven't used that with the 10.6 server that's been backing up at another facility of my client's company.

Finally, are you privy to whether or not any further revisions of 10.7 are supported (i.e. is the fact that it is not explicitly stated in the SCL that they are the last word on whether or not they might work, or is it just that Symantec has yet to test as much)? 

[Backup_Exec1]

Hi

"Finally, are you privy to whether or not any further revisions of 10.7 are supported (i.e. is the fact that it is not explicitly stated in the SCL that they are the last word on whether or not they might work, or is it just that Symantec has yet to test as much)?"

Yes if it is not in SCL that is not yet tested by Symantec so in that your configuration when you call support is not supported.

Moreover when you install Mac agent the beoper group should be created automatically if not you can try creating one & then check about agent directory yes I mean to say /opt/VRTSralus try giving additonall permisision to it and see if that helps too

Hope that helps

Thanks

[pkh]

1) FYI, here is a quote from the SCL which is relevant in your situation

2. Minor dot (.) version support: The contents of this document including 3rd party applications, databases, operating systems, in combination with Symantec products represent what has been tested in Symantec labs, or in Symantec-supervised partner labs, but is not intended to be a complete list of supported products and versions. Manufacturers of these products may frequently release minor version updates to their products as maintenance during their product's normal life cycle. (e.g. version 1.x.x.x) that may not be explicitly listed in this document. In these situations where the base or major version of the product is listed as supported in this document but the minor maintenance update is not, Symantec will provide "reasonable effort" support on these versions until specific testing of them has completed.

2) Is the Mac's root account added as a credential to the media server and used when accessing the Mac?

[ahdtech]

Hi again, Sameer, and hi pkh.

I don't handle the media server's management, and have only been working on the remote agent's installation. I'm told that the root account has been added as a credential on the media server, and is used when accessing the Mac. The problem is, though, that it is somehow being prevented from accessing the root level of the Mac's file system.

Sameer, I have created a beoper group, and given it the group id of 110, as I notice that your installer changes the permissions of several directories (/opt and /etc, and enclosed files and folders) to "110" for the group permissions. This gid was not actually being used by a group on the Mac, so I am surmising that, if your installer was actually supposed to create this beoper group, it was designed to give it that gid. Permissions for /opt/VRTralus are already nearly as open as I can make them.

pritaz:rams root# ls -la / | grep opt

drwxrwxr-x@   3 10001  beoper         102 Jan  8  2012 opt

pritaz:rams root# ls -la /opt/

total 0

drwxrwxr-x@  3 10001  beoper   102 Jan  8  2012 .

drwxr-xr-x  34 root   wheel   1224 Jan 14 10:24 ..

drwxrwxr-x@  7 root   wheel    238 Jan 14 18:58 VRTSralus

With respect to the "beoper" group, your documentation actually mentions the need to create a group called admin, and to add whatever users you're using to backup into that group (http://www.symantec.com/business/support/index?page=content&id=HOWTO73769#v53932540). What's weird is that admin is the default Mac OS X group for users with administrator privileges. It should exist already (and, of course, did on this system). 

I'm still waiting to hear from the man who manages the media server whether creating the beoper group, with root as a member, and with the gid 110 made any difference.