Process Cannot Access File because it is being used by another process

[StevenHB]

I'm consistently getting errors writing to the unraid system I maintain in my home. I first noticed this when the Duplicati backup process that uses the unraid system for its storage would fail with an error message such as this one:

Failed after uploading 192 volume(s). Error message: Failed to upload file "duplicati-inc-content.20150907T052251Z.vol193.zip": 
The process cannot access the file '\\<IP address>\<path>\Duplicati\duplicati-inc-content.20150907T052251Z.vol193.zip' because it is being used by another process.

 

While working with it yesterday, I found that files I edited locally (from my Windows 8.1 laptop) couldn't be written back - attempts would get a similar message about the file being in use by a another process.  Now that I think about it, this could be related to the use of a multi-disk share that I recently setup and started using. Is there a known problem with multi-disk shares?

 

For what it's worth, the work I was doing yesterday was to switch to using FTP (vsftpd) to send files to the unraid server.  The backup that ran overnight did not get any "used by another process" errors (I'd been getting them consistently before that change), so that may be another clue as to where the issue lies.

[RobJ]

The only thing I can think of, since you recently added the share setup, is that you might still have something configured to use the disk path.  It's best to either always use the disk path or always use the share path, but not both.

[StevenHB]

I think that I have a drive on that laptop mapped to one of the drives. I can eliminate it.

 

There's definitely content that was stored on Disk1 which is now part of the new, combined share. Is this a problem by itself?

 

What additional setup information would you like?

[RobJ]

Under certain conditions, I believe it *can* be a problem, although I don't know if they apply to you.  All I wanted to suggest is make sure the stations accessing the data are configured the same way, to all use the share path, not some using the Disk1 path.  The shares use the FUSE system, regular disk access doesn't, so that *might* make it possible for 2 different processes accessing the same files.

[StevenHB]

I've now had FTP work successfully two days in a row, so I'm prepared to conclude that there's something about using the share from my Windows client that's causing the problem.

 

I still have a mapped drive to Disk1. It's not being used for anything, but I'll change it to use the multi-disk share and, eventually, will switch back to using the share for backups to see if it makes a difference. I have a decent workaround in the meantime.