Hi Greg,

You need to add

tst-networker@hostA

tst-networker@hotsB

In the remote access field of the 2 hosts.

This should grant that user permissions to perform the directed restore.

If that doesn't work, add tst-networker@* in the administrator's group of NetWorker, as if I remember well the user needs permissions "manage Jukeboxes" in order to be able to perform a restore/directed restore.

If you don't want to grant Admin rights in NetWorker create a new group with manage jukeboxes rights and include that user: tst-networker@*, however check the Admin guide in case there is any further right required.

Thank you.

Carlos.

Hi Carlos,

Thanks for your very quick response time.

I've try your proposition and unfortunately, that doesn't resolve my probem.

1) tst-networker@hostA, tst-networker@hotsB on both client:

That doesn't work better. I don't understand why do I need to put tst-networker@HostB when I only want to restore Data on HostA? I've try with tst-networker@* on both client, doesn't matter.

2) My user already have all the right required in Networker. the only privilege he don't have is: Change security settings, Remote Access All Client and Configure Networker.

We use LDAP authentication... Could this be part of the problem?

Hi Greg,

Maybe it's a OS limitation/permissions related.

As per documentation these are the requirements:

Access requirements to perform directed recoveries are as follows:

• Users in the Administrators group on the NetWorker server are automatically granted the necessary privileges.
• The recovery must be launched by the root user or Windows Administrator onther administering client.
• The root user or Windows Administrator on the administering client must have the Remote Access All Clients privilege on the NetWorker server.
• SYSTEM@destination_client must be listed in the source client’s Remote Access list.
• SYSTEM@destination_client must have the Recover Local Data privilege.

If the user on the destination client does not have Remote Access All Clients privileges, then the user@destination_client must be listed in the source client’s Remote Access list.

Thank you.

Carlos.

Hi Greg,

Make sure that you are not trying to perform Cross Platform Directed Recovery , meaning from Windows to linux or vice versa , or from Unix to Windows or vice versa , as Cross Platform Directed Recovery is Not Supported.

Otherwise please provide us with the operating systems of the clients of the source and destination and their NetWorker versions installed on them as well.

Thanks,

Ahmed Bahaa

Hi Greg,

As the Administrating client is Windows 2008 R2 , Can you try to run the NetWorker GUI with Run As Administrator and then re-try again the recover.

Make sure that the source and destination clients must use the same type of file system.

Also ensure that the administering host must be a client of the NetWorker server. The administering host is the host from which the graphical user interface is displayed.

There is some UNIX specific restrictions:

-  Restrictions related to relocating non-ASCII directories on UNIX machines:

   • If the remote directory is an existing non-ASCII directory, the locale of the browsing session from which the directed recover is started must match the locale in which the remote directory was created.

   • If the remote directory does not exist, the relocation directory will be created on the remote machine’s file system based on the locale of the browsing session.

For the Remote Access  attribute of the client resource for the source machine must allow access to the user / host machine that is performing the

directed recovery operation. Do this by adding  "SYSTEM@target_client " to the source client resource’s Remote Access  attribute.

Add  "user=system,host= target_client "  to the Users attribute of the NetWorker server’s preconfigured Administrators user group.

Note: If a different client (target) is specified, the restored machine will use the samehostname and IP settings as the source machine. This can cause hostname and IP address conflicts if the source machine is running on the same network.

Waiting your updates.

Thanks,

Ahmed Bahaa

Ok, thanks for that.

• The recovery must be launched by the root user or Windows Administrator onther administering client.

OK

• The root user or Windows Administrator on the administering client must have the Remote Access All Clients privilege on the NetWorker server.

administrator_user@HostB (administering client) is administrator of networker, so OK.

• SYSTEM@destination_client must be listed in the source client’s Remote Access list.

Source and destination are in my case identical. And it's a linux machine. Schould I had root@hostA in remote Access list? Or is the next fact enough?

• SYSTEM@destination_client must have the Recover Local Data privilege.

root@* is administrator of Networker. with recover local data privilege and remote access all client privilege. OK

• If the user on the destination client does not have Remote Access All Clients privileges, then the user@destination_client must be listed in the source client’s Remote Access list.

I've put User@hostA in the remote access list of HostA client. But it's not better. Any other Idea or precision?

Hi Ahmed,

Thanks for your help,

• I already run Networker user GUI as Administrator.
• Source and Destination are the same machine (linux)
• The administering Client is a client of Networker and the administrator of this machine is an administrator of Networker.
• root@* is administrator of Networker.
• On HostA client (the one I will to restore (source and client), I had user@HostB (administering Host) as a remote access user.

Any other idea?

Thanks,

Greg

Hi Greg,

The following are requirments:

-The root user or Windows Administrator on the administering client must have the Remote Access All Clients privilege on the NetWorker server.

- SYSTEM@destination_client  must be listed in the source client’s Remote Access list.

- SYSTEM@destination_client  must have the Recover Local Data privilege.

If the user on the destination client does not have Remote Access All Clients privileges, As you require, then the user@destination_client must be listed in the source client’s Remote Access list and must have the Recover Local Data privilege.

Also i found in the Admin guide that if you want to give clients client-tasking  rights to a NetWorker client, you have to do the following:

1. Stop the NetWorker host services whose tasking rights are being updated.

2. Open the servers file in a text editor.

The default installation location for this file is:

• /nsr/res/servers (UNIX)

• NetWorker_install_path \res\servers (Windows)

3. Enter one hostname per line.

4. Save the changes and exit the text editor.

5. Restart the NetWorker host.

I didnt try that before actually, so i will be waiting your updates on how that performs with you.

Thanks,

Ahmed Bahaa

Additionally, NetWorker uses the contents of the /nsr/res/servers (UNIX), or the NetWorker_install_path \res\servers (Windows) file on each NetWorker client to control who has client-tasking rights (the right to request a program to be executed on another client). This client-tasking might be any of the following:

- Server that performs an archive request

- Scheduled backup

- Another client that requests a directed recover

During a NetWorker software installation, you can add the names of NetWorker servers to this file. To add additional hosts at  a later date, a text editor must be used to add the hostname to the file.

- So that the client with the tasking rights  can back up to other NetWorker servers, the names of the additional NetWorker servers must be added to this file.

- So that other clients can perform directed recovers to the client with the tasking rights, their names must be added to the servers file.

IMPORTANT:

If the servers file is empty, then any NetWorker host has tasking rights. This is a potential security concern.

Thanks,

Ahmed Bahaa

Hello Greg,

I think the problem resides on the restore process being started from a Windows box, and trying to restore Linux files.

I had a similar case in the past and we eventually managed to solve it, however I would suggest you to run the restore from one of the Linux boxes and check out the results.

You can also run the restore from the command line and check if you are still getting the same error messages:

recover -s servername -c source_client -R destination_client –I recover_option [directory_name]

If you run it from the destination box you should run:

recover -s NW_server_name -c source_client_name -d path_for_restore

Otherwise you would need to add the following users in the Remote Access Field:

SYSTEM@*

root@*

tst-networker@*

And also the user you are logged in on the Windows server you are running NWUI from.

If adding these users fails then I think that the problem is that user tst-networker, which is originally a Windows User, DO NOT have rights to write on the destination Linux client.

Thank you.
Carlos.

@Ahmed:

-The root user or Windows Administrator on the administering client must have the Remote Access All Clients privilege on the NetWorker server.

OK

- SYSTEM@destination_client  must be listed in the source client’s Remote Access list.

- SYSTEM@destination_client  must have the Recover Local Data privilege.

If the user on the destination client does not have Remote Access All Clients privileges, As you require, then the user@destination_client must be listed in the source client’s Remote Access list and must have the Recover Local Data privilege.

OK. root@* is Administrator and have all privilege.

Also i found in the Admin guide that if you want to give clients client-tasking  rights to a NetWorker client, you have to do the following:

1. Stop the NetWorker host services whose tasking rights are being updated.

2. Open the servers file in a text editor.

The default installation location for this file is:

• /nsr/res/servers (UNIX)

• NetWorker_install_path \res\servers (Windows)

3. Enter one hostname per line.

4. Save the changes and exit the text editor.

5. Restart the NetWorker host.

The server File on the client doesn't exist. So it could not have an influence.

I didnt try that before actually, so i will be waiting your updates on how that performs with you.

Thanks,

Ahmed Bahaa

@Carlos

As I didn't have acces to this client now, I cannot try from the command line. But:

-     If I just put, SYSTEM@*, root@*, tst-networker@* in the remote access list of my client, it doesn't work.

-     But if I put tst-networker (the user that I use on the administering client to log me in Windows) as an administrator of       Networker, it works perfectly... So I guess It's not a write right problem on Linux, am I wrong?

Thanks for your help.

Greg

Greg

Have we verified the servers file is set up correctly yet?

David