@scottalanmiller said:

Unless you got it through work, I would not donate gear to a for-profit company. If it is a grey area that you got it from a company related function then sure. But if you got it fully on your own, I would keep it.

Got to convince my wife it will be no more a power hog or a fire hazard as my other stuff...I turned it on and configured it last night and it was surprisingly quiet and cool.

Here's an update:

When I look at the security audit for our file server, it shows this copier login, logout and on a second login it, it shows this for the login ID:

Security ID: NULL SID
Account Name: `LL~t___tV
Account Domain: WORKGROUP

Not sure what is causing this but here is more mystery...

As mentioned, changing the scanning port from 445 to 139 worked for a while. While Xerox was here, I did that and bam, it scanned. And it scanned items over and over with DEFAULT settings. While they did not call this resolved, they left to await more info from their engineers.

So, I started my own testing. I scanned an item and instead of the default DOC name it gives (and appends numbers to for multiple scans), I gave it a name AT the copier, like test. Bam! It FAILED with login failure and the garbled ID. I went to port 445, back to 139. Scanned and it worked. Gave the file a name at the copier and it failed. So, I narrowed that down and passed on the info to Xerox.

The interesting thing about this garbled Account Name is that it comes from WORKGROUP. Not sure why.

@Dashrender said:

If anything happens to that unit after you donate it, you might find yourself on the hook for those problems.

So noted...:) (another reason to keep)

This may be a crazy question considering the price but hear me out.

I write reviews and get mostly IT items sent to me to keep and review. They can be as small as HDMI cables, to gaming laptops.

This last time, I received a Seagate Business Storage Windows Server 8TB. Retails for $1599. It has Windows Storage Server 2012 and about 5TB free on RAID5. It also has the nifty USM slot for portable Seagate drives for very easy offsite backup rotations.

I am a storage freak as I like local storage. I have two Western Digital 2 Drive RAID 1NAS's at home for extra backup protection (and I still backup to external drive and keep offsite). I take a lot of digital photos and videos and can't have too much storage.

Well, this NAS fell into my lap and I almost think it is "too much power" for my home needs. My wife thinks it may be a power hog and worries if it should ever overheat. (my current NAS units go to sleep mode when not in use) But, it is perfect for work, especially for backups and additional storage needs. My work is very frugal and at this time, I know they wouldn't purchase this device. However, I think it would be a better fit here. Considering I got it for free, I am in a big debate to use it for home use and sell my other NAS's or put it to use at work where it is honestly really needed.

I know I'll end up making my mind up but just wondering what you other IT pros would do in this situation.

Love you guys...so funny...

I've for sure stumped Xerox...but I am pushing them because downtime (well, semi-downtime since the back copier is fine) is not accepted around here...

We have two Xerox Workcentre 5755's. Both are on the same firmware (the one released around the first of April.) One of them can scan to our new Windows Server 2012 R2 file server and the other one can't. It goes back and forth between REMOTE DIRECTORY LOCK FAILED or LOGIN FAILED. CHECK USER PASSWORD AND/OR SETUPS.

I've reentered password, reset password, tried a new user account for the sever, clones the machine and Xerox has been out with no results. I've even got Level 3 XMC people looking into it, No resolution.

Changing the port from 445 to 139 worked for about 3-4 scans and it stopped. Same goes for changing back to 445. It is strange that the back copier is totally fine.

I've done searches and it says that there was at one time an issue with SMB with these copiers and server 2012 R2. There was also a patch released to fix it the problem but when I went to install it, it said PATCH INSTALLATION FAILED!!! THIS PATCH IS NOT INTENDED FOR THIS DEVICE.

Xerox and XMC continues to work on it but management is getting fed up with the wait.

Any suggestions?

This ended up being a name resolution problem. FQN in the storage repository did the trick. Back on track now...

@scottalanmiller said:

Oh, it is Veeam. Veeam might use native NFS. I thought that this was your old backup software, sorry. Veeam should be NFS I believe.

Yeah, the old BACKUP ASSIST that I will use just for SQL from our physical server, is fine now when I set the share to PUBLIC in the NAS GUI...just VEEAM now...it is having problem...this worked fine before I rebuild the volume as RAID10 and made a new share...it has to be in the share somewhere but I've set everything up the same...

@scottalanmiller said:

And it is wide open with read and write for everyone?

Sorry for the delay...crazy day with other stuff. Yes...wide open for everyone. VEEAM still returns the error...

@scottalanmiller said:

@garak0410 said:

Real Quick...I did see this setting:

NFS Service ON or OFF...it was set to OFF. If I set to on, it asks for allowed IP's...I've never had to set that before and it is off on my Archive Server (same series NAS) and it is fine.

NFS should be OFF. Test with nothing but SMB for now. Unless the software uses its own NFS, then use nothing but NFS.

I created a new Share with just CIFS, no NFS...same error:

4/18/2014 9:50:24 AM :: Processing 'Backup Server' Error: Client error: The network path was not found.
Agent failed to process method {Stg.OpenReadWrite}.

Guess I'll go for the factory reset now...

Real Quick...I did see this setting:

NFS Service ON or OFF...it was set to OFF. If I set to on, it asks for allowed IP's...I've never had to set that before and it is off on my Archive Server (same series NAS) and it is fine.

@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...

@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...

@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...

@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...

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...

@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...

@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.)

@scottalanmiller said:

What's holding up the decomm at this point? Are there still services relying on the old box?

Just crazy busy with SOLO IT guy stuff...

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?