I got the following error on a single file on unRaid 6.0.1 when i run a backup (Goodsync).

 

- ERROR: Error copying file: BlockCopy after Denied/Locked: Cannot open local file '//HUNTERNAS/pictures/2015/20150320_193536.mp4' for read: Access is denied.  (error 5)

 

No matter how i try to access, delete, copy or read the file, I get this error.

 

What happens when I try to play the video:

http://my.jetscreenshot.com/12412/20150701-pixp-92kb.jpg

 

This is the message I get when I try to manually copy the video:

http://my.jetscreenshot.com/12412/20150701-2q4k-31kb.jpg

 

Any thoughts what could be going on?  How could rights be changed on a single file?

Run new permissions in the tools page. If it is not fixed, then see check disk filesystems in my sig.

Before I try that, there's one more bit.  The file does not exist on the server.  All the files in this directory are on one Disk, and I've searched throughout that drive and can't find the file.  So it does not exist.  I had deleted it some time before the error showed up.  Perhaps this is diagnostic?  Will New Permissions scan the disk and resolve broken filename links?

See check disk filesystems in my sig if your using RFS otherwise use xfs-repair.

I have files on the cache drive waiting for mover.  Should i wait for that to complete before I unmount the affected drive?

 

Do you have a "pictures" folder in the root of any or all of your drives? Look on all drives, including the cache drive.

There is a pictures folder on Cache (updated several hundred files last night).  Also on Disk1 (where all of the pictures are stored).  No other disks have a pictures folder (although the 'pictures' share spans several Disks).

Has the server been rebooted since the original issue occurred? The /mnt/user fuse filesystem is rebuilt from what exists on the disks each time the server is started, and it's theoretically possible that it's out of sync. Does the file appear if you browse to /mnt/user/pictures/2015/ using MC on the local console or telnet?

Interesting.  The file, 20150320_192536.mp4 DOES NOT show up in MC on either the Disk1/pictures/2015 or user/pictures/2015 share (either LS or MC, neither sees the file).  ONLY from windows do I see the file.

 

The server has booted several times in the past week.  The problem showed up after I had moved files and was setting up my backup software (goodsync) to sync files between my workstation and the nas.  Perhaps Goodsync created the problem?  (www.goodsync.com).  Perhaps there's a better tool to use for backup?  Goodsync is somewhat complex, but it does a good job.  I've used vice-versa before as well.

Interesting.  The file, 20150320_192536.mp4 DOES NOT show up in MC on either the Disk1/pictures/2015 or user/pictures/2015 share (either LS or MC, neither sees the file).  ONLY from windows do I see the file.

Do you have multiple windows machines that show the file, or only that specific workstation?

Now that is really fascinating.   

 

I checked on two different Laptops (via wifi, win 7 and win , and neither of those laptops can see that file in either the Disk1 or pictures/2015 share...

Now that is really fascinating.   

 

I checked on two different Laptops (via wifi, win 7 and win , and neither of those laptops can see that file in either the Disk1 or pictures/2015 share...

Well, that pretty much exonerates unRaid as being the source of the issue. Perhaps offline files on the offending machine?

Yeah, it was really strange.  As you could tell from the screen print, it was a zero byte file, but it ONLY showed up on the unraid drive.  I rebooted the server today and went back and looked at the file, it was still there, on a whim I deleted it.  And it worked this time.  Must have been in some kind of lock state between my PC and the server?

 

So for a root cause analysis, I guess when Good sync ran, it created some kind of lock on the file and a reboot of the server apparently broke the lock for the zero byte file on the server.  Interesting to note that the lock remained through a reboot of the PC...

 

Odd...but thankfully SOLVED!