Seagate NAS Connection Problem
-
We have a cheap (but functional) Seagate Blackarmor 440 NAS we use for backups. I am in the middle of demoing some backup software and have about settled on VEEAM and our current solution (just for SQL. and a few physical servers needs).
I decided to rebuild my NAS since it takes days to delete data off of it. And rebuilt it with RAID10. This NAS does allow for some active directory integration on permissions to the shares and those are set as before.
On the backup server, I go out to the path to the share \backupnas\share and I can create files and folders and delete them.
In VEEAM, I set up the new NAS volume in the drive repository, set up the permission (login) to the NAS, it detects it and even shows the free space. All is good there. When I run the backup, I get...
4/17/2014 4:51:34 PM :: Processing 'pinnacle' Error: Client error: The network path was not found. .
Agent failed to process method {Stg.OpenReadWrite}.On our other backup suite, BackupAssist, that I use for SQL, same thing...it knows the NAS is there, heck, it is even mapped as a drive on the backup server...it gets:
BA1505 Cannot open the specified destination directory from the server - it may not exist or the SQL server may not have the correct authorisation
Cannot open backup device '\backupNAS\SQLBackup\SQLINSTANCE-Contracts-20140418.072841.445-FULL.bak'. Operating system error 50(The request is not supported.).
BACKUP DATABASE is terminating abnormally.The NAS setup didn't change...still CFIS and NFS...but for some reason, after recreating the volume, I am having these issues...I did go from RAID5 to RAID10 but really doubt that matters...
Any ideas?
-
RAID levels definitely have no effect there. This is definitely an issue at a higher level.
-
To put double backslashes in a post, use triple. It treats the first as an escape character. \\server\folder
-
@scottalanmiller said:
RAID levels definitely have no effect there. This is definitely an issue at a higher level.
Yeah...this is so frustrating...nothing changed but making a new volume, shares and assigning the same permissions back...maybe I am finally seeking the "sucky" side of these NAS units (which up to know, haven't been as bad as some have reported.)
-
No need to share NFS since you are using SMB.
-
Have you tried just opening the SMB share wide open.... "Read/Write to Everyone" ?
-
@scottalanmiller said:
Have you tried just opening the SMB share wide open.... "Read/Write to Everyone" ?
Yes...it was FULL access but still had permissions to limit some access...
I am starting over with the volume...one more time...step by step...will remain at RAID10 though...
-
Open it completely for testing. Once that is working, lock it down.
-
Here's what I've done
Created the RAID10 Volume (took about 5-6 minutes to format)
Created a single share with FULL NFS access...tried to view it in windows explorer and got this:
So, there was another option for public access, with along with FULL NFS access selected, takes away the AD options...selected that...BAM...I can get to the folder in Windows Explorer...Started the SQL backup from BackupAssist...BAM...it works...so FULL NFS and Public access makes it work...
Waiting on the SQL to finish before trying VEEAM but it sounds like it will work now...I can slowly add some AD back into it...while it is always good to have security, backups are not one I am too worried about as no one here would have the time or knowledge to poke around in that drive...
-
@garak0410 said:
Created a single share with FULL NFS access...tried to view it in windows explorer and got this:
No, NFS is what you should turn off completely. There is no need for it. Use SMB only and open that all the way up. Windows can't natively talk to NFS.
-
OK something is really fishy if he disabled SMB and only has NFS running, yet he's able to backup to the device (assuming he hasn't installed a NFS driver in Windows).
-
@Dashrender said:
OK something is really fishy if he disabled SMB and only has NFS running, yet he's able to backup to the device (assuming he hasn't installed a NFS driver in Windows).
Yeah, that is weird. The software must have its own NFS stack that it is using or installed SFU silently and doesn't tell him. Very odd. But hey, NFS is easier to deal with so... good deal.
-
@scottalanmiller said:
@Dashrender said:
OK something is really fishy if he disabled SMB and only has NFS running, yet he's able to backup to the device (assuming he hasn't installed a NFS driver in Windows).
Yeah, that is weird. The software must have its own NFS stack that it is using or installed SFU silently and doesn't tell him. Very odd. But hey, NFS is easier to deal with so... good deal.
Well, regardless, it is working for the SQL backup....writing fine...I set up a new Backup Repository in VEEAM to the share with Full Access and Public access and it still fails with THE NETWORK PATH WAS NOT FOUND...baffling...
-
@garak0410 said:
@scottalanmiller said:
@Dashrender said:
OK something is really fishy if he disabled SMB and only has NFS running, yet he's able to backup to the device (assuming he hasn't installed a NFS driver in Windows).
Yeah, that is weird. The software must have its own NFS stack that it is using or installed SFU silently and doesn't tell him. Very odd. But hey, NFS is easier to deal with so... good deal.
Well, regardless, it is working for the SQL backup....writing fine...I set up a new Backup Repository in VEEAM to the share with Full Access and Public access and it still fails with THE NETWORK PATH WAS NOT FOUND...baffling...
Well, that kinda gives credibility to Scott's theory that your backup software for SQL is using it's own NFS driver.
Time to try Scott's earlier suggestion, enable SMB and open it up fully - everyone full control. no other permissions set.
-
@Dashrender said:
@garak0410 said:
@scottalanmiller said:
@Dashrender said:
OK something is really fishy if he disabled SMB and only has NFS running, yet he's able to backup to the device (assuming he hasn't installed a NFS driver in Windows).
Yeah, that is weird. The software must have its own NFS stack that it is using or installed SFU silently and doesn't tell him. Very odd. But hey, NFS is easier to deal with so... good deal.
Well, regardless, it is working for the SQL backup....writing fine...I set up a new Backup Repository in VEEAM to the share with Full Access and Public access and it still fails with THE NETWORK PATH WAS NOT FOUND...baffling...
Well, that kinda gives credibility to Scott's theory that your backup software for SQL is using it's own NFS driver.
Time to try Scott's earlier suggestion, enable SMB and open it up fully - everyone full control. no other permissions set.
Sorry...enable SMB on what device? If the NAS, there is no option for that...
-
The NAS doesn't support SMB? Something is wrong. That's 95% of its use cases.
-
Maybe the NAS uses the old name for SMB.... CIFS?
-
@scottalanmiller said:
The NAS doesn't support SMB? Something is wrong. That's 95% of its use cases.
I know...as mentioned, this all worked great before I rebuilt the volume. Seagate support has suggested factory reset...of course they did...
-
@garak0410 said:
@scottalanmiller said:
The NAS doesn't support SMB? Something is wrong. That's 95% of its use cases.
I know...as mentioned, this all worked great before I rebuilt the volume. Seagate support has suggested factory reset...of course they did...
If you rebuilt the array, what's wrong with a factory reset?
-
@Dashrender said:
@garak0410 said:
@scottalanmiller said:
The NAS doesn't support SMB? Something is wrong. That's 95% of its use cases.
I know...as mentioned, this all worked great before I rebuilt the volume. Seagate support has suggested factory reset...of course they did...
If you rebuilt the array, what's wrong with a factory reset?
Nothing...just more work (I've got a ton on my plate today)...LOL...about to go attempt it...
