cancel
Showing results for 
Search instead for 
Did you mean: 

Errno = 13: Permission denied

dbeck
Level 5

All,

Created to mount point directories for backps.  First directory is called data_backup,  Second is called home_backup.

Gave both directories full root permissions  using chmod 777.  When executing ls -alt, boot directories show (drwxrwxrwx  2 root root 4096)

Then after mounting and executing ls -alt again,  the directory data_backup shows (drwxrwxrwx  145 root bin 17408) and backs up with no permission errors.  However, the directory home_backups shows (drwxr-xr-x 79 root users 3072) and gives the error (Errno = 13: Permission denied) when running the job.  Have tried the umount to set permissions, but when mounting home_backup again, permissions are still (drwxr-xr-x 79 root users 3072).   Please advise.

Dave






1 ACCEPTED SOLUTION

Accepted Solutions

Andy_Welburn
Level 6
From the man page for share_nfs one of the -o options is:

root=access_list    Only root users from the hosts specified in access_list  will  have  root  access....By default, no host  has root access, so root users are mapped to an anonymous user ID.

So even tho' you are root on the target server you are essentially "anonymous" as far as the source server is concerned & so only have those effective permissions.

Using share with the option -o root=target_server (i.e. your master) should give you the necessary rights for the backup to work without having to change any permissions directly.

Beware - this DOES give effective root permission so any changes made on the nfs mount regarding file or directory access will also be effective on the source server. I would advise speaking to your server admin prior to attempting this (unless that's you of course!)

Alternatively, you could set the UID of the anon user to be 0:
anon=uid   Set  uid to be the  effective  user  ID  of  unknown  users.  By  default, unknown users are given the effective user ID UID_NOBODY. If  uid is set to -1, access is denied.

PS: this is effectively out of scope of NB and will effectively make the source server somewhat less secure.

View solution in original post

16 REPLIES 16

Andy_Welburn
Level 6

The mount command will essentially overwrite the contents & permissions of the 'mount-point' using the contents & permissions of what its mounting.

You should find that once done these permissions will hold after subsequent umounts & mounts.

dbeck
Level 5

Andy,

After mounting 'home_backup' and issueing the chmod 777 command to give root user full control on home_backup  this is returned,

chmod: Changing permissions of 'home_backup' : Operation not permitted

Dave

dbeck
Level 5

Andy_Welburn
Level 6
Is it from some NAS device e.g. NetApp? If so has root been given access to this export on the device from which you are trying to run the command?

J_H_Is_gone
Level 6

777 is not really giving root full control it is giving EVERYBODY full control.

On the export of the file system on the source server - is it exported with read write or read only or read mostly?

dbeck
Level 5
All,

home_backup is a nfs mount and was exported with read write to the Netbackup Master Server.  This nfs mount are users home directories and all their data.  Logging into the Netbackup Master Server as root.  Should I create a super user for the netbackup jobs instead of using root?  Or is there a setting within Netbackup 6.0 MP7S01 that can be set to get by the Errno = 13.

dave

Andy_Welburn
Level 6
From your previous posting I would suggest  it is more of (***EDIT*** MUST be) a root access permission issue from the export/share than a specific NB issue and once this is sorted I would imagine your 13's would be a thing of the past.

Can you confirm what this is an nfs mount of - e.g. is it a NetApp volume/qtree?


dbeck
Level 5
Andy,

home_backup is a nfs volume mount on a Solaris version 9 server which we exported with read/write permissions to the NBU Master Server.

Dave

Andy_Welburn
Level 6
From the man page for share_nfs one of the -o options is:

root=access_list    Only root users from the hosts specified in access_list  will  have  root  access....By default, no host  has root access, so root users are mapped to an anonymous user ID.

So even tho' you are root on the target server you are essentially "anonymous" as far as the source server is concerned & so only have those effective permissions.

Using share with the option -o root=target_server (i.e. your master) should give you the necessary rights for the backup to work without having to change any permissions directly.

Beware - this DOES give effective root permission so any changes made on the nfs mount regarding file or directory access will also be effective on the source server. I would advise speaking to your server admin prior to attempting this (unless that's you of course!)

Alternatively, you could set the UID of the anon user to be 0:
anon=uid   Set  uid to be the  effective  user  ID  of  unknown  users.  By  default, unknown users are given the effective user ID UID_NOBODY. If  uid is set to -1, access is denied.

PS: this is effectively out of scope of NB and will effectively make the source server somewhat less secure.

dbeck
Level 5

Andy,

Success.... This is the command we set on the Solaris server where the users home directories reside.

share  –F  nfs  –o root=mars:wonka:candystore,rw  /export/home

Thanks to you and everyone else who replied with tips on this issue.

Best Regards,
Dave

J_H_Is_gone
Level 6
I see that you gave the command that makes it work.
But what where you doing worng. 

Meaning, for others who may look at this doc.

what was your issue, and what in that command fixed it?

dbeck
Level 5

J. Hinchcliffe,

The error NBU was giving  when backing up users home directories on the Solaris server was

Errno = 13 : Permissions denied. 

The command we issued in the above reply fixed the problem.   Were in the process of moving users home directories off of the Solaris server to a Redhat Linux server and hopefully this problem won't happen again. 

Regards, Dave

Andy_Welburn
Level 6
originally then?

So you followed my post to correct? (hint, hint wink)

Marianne
Level 6
Partner    VIP    Accredited Certified

I agree - seems Andy pointed you in the right direction..........

dbeck
Level 5

Andy,

Correct, We didn't have root access set in the share on the users home directories on the Solaris server.

Dave

Will_Restore
Level 6
please mark Andy's "root=access_list" reply as Solution wink