Comments
2 comments
-
Hi
Thank you for your post.
From the information provided, it does look like it is permissions issue to the share.
Could you follow the documentation below to see if this rectifies your permission issue:
Click here
Many Thanks
Wendy Mitchell
Product Support Engineer -
Thank you for the information. Working with our internal engineers, we've determined it is truly a permissions issue and are working to properly configure Samba permissions to the underlying AIX directories. We did get native and Redgate backups to write to Samba folders and are working through the finer points of the permissions architecture to allow for flexible file/folder manipulation abilities through Windows domain logins.
Add comment
Please sign in to leave a comment.
We narrowed the cause to write permissions to the Samba share ONLY when using Red Gate to write the backup file. Native SQL Server uses the same account for the SQL Server Agent and can write the .bak to the Samba share just fine.
EXEC master..sqbutility 999, 'RWE', '\XXXSambaSQL_nn' (unqualified share name)
Results: <SQBUTILITYRESULT>:0:Folder does not exist : \XXXSambaSQL_nn (cannot see the share, actually)
EXEC master..sqbutility 999, 'RWE', '\XXXsamba.domain.xxxxxxx.comSQL_nn' (fully qualified name)
Results: Insufficient rights to create files : Cannot create file "\XXXsamba.domain.xxxxxxx.comSQL_nnsql backup test 20150424145311405.txt". Access is denied.
Someone said this has to do with SQL Server recognizing NETBIOS and Redgate not using NETBIOS. (I'm a novice to network issues).
Redgate backup service account and SQL Server Agent account are the same. Using a SQL Agent job, native SQL can write to Samba and Redgate cannot.
So my question is what permission(s) do the Samba share and/or Redgate need in order for Redgate to write to the Samba share?
Thanks.