First I should say that my unRaid server is running fully stable for some time now and I do have no problems at all to remotely read/write data on it from Windows 7 or XP PC's using smb or ftp, I do get good network speed and there is no lost packets or any problem. I did already copy 100's of GB's on both directions, verified them with md5 etc ( yes I'm integrity paranoiac ) and never had any kind of corruption.

 

However I'm having some strange problems when on any of my PC's instead of Windows I do run Acronis True Image (running it from it's bootable media, based on Linux) and try to do an HDD backup and set it to read/write image file on unRaid server (via smb) directly on an user share that is part of the parity protected array (problems described below), however if I set it to read/write image file to an unRaid cache user share (set on unRaid as Use cache disk: only) then it works fine no problem at all, also if I set it to read/write image file on a share on another Windows PC I do also get no problem at all, then in sum the problems only really seem to happen when Acronis True Image needs to read/write to an user share that is part of parity protected array.

 

The problems on Acronis True Image Echo Workstation 9.5 are mostly (permanent) freezes when Acronis True Image tries to read/write from unRaid, for eg. one situation that I could easily reproduce and I did tested it a lot of times to be sure is the following:

 

- I do already have a full hdd image file (from one of my windows pc's hdd obviously) saved on unRaid server, I do have that image file duplicated and available on two unraid user shares, one is on a cache only share (I did created it there initially to avoid problems to create it...) then did cp it to the protected array...

 

- Boot True Image disc on the PC that image was created from... and want to create a differential image (only with changes made after creating the previous/existing image file), I do select the existing image file from the unRaid server (via smb) and select that I want to create differential image, then true image should read parts of the already created image file (probably something like included files structure, checksums etc) and the local hdd so that it can identify what is new/changed...

 

- on the step above If I select the existing image file as the one available on the cahe-only user share and it works fine and creates a new file with differences as expected... however if I select existing image file as the one available on the parity protected user share then true image hangs/freezes when trying to read the remote existing image file. If I wait something like 30 mins it will show an error that there was a problem to read file.

 

Also during hang if from a 3rd pc (windows) I do try to read that same image file from unraid (try to md5 it for eg. or copy using windows shell, teracopy is different I will explain below) I can't read it, file looks like locked on the unraid server. Also I did a lsof on unRaid and could see this:

 

root@unRAID:~# lsof|grep BackupC
shfs      9679       root    4u      REG        9,1 15190548722      12439 /mnt/disk1/pub/BackupC.tib
shfs      9679       root    5u      REG        9,1 15190548722      12439 /mnt/disk1/pub/BackupC.tib
shfs      9679       root    7u      REG        9,1 15190548722      12439 /mnt/disk1/pub/BackupC.tib
smbd      9912       root   31u      REG       0,13 15190548722         14 /mnt/user/pub/BackupC.tib
smbd      9912       root   32u      REG       0,13 15190548722         14 /mnt/user/pub/BackupC.tib
smbd      9912       root   33u      REG       0,13 15190548722         14 /mnt/user/pub/BackupC.tib

 

One other thing I did noticed is that if I do not want to wait and hit reset button on the pc running true image then such lock (and these "handles" on lsof remain for some minutes, until they disappear and the lock is lifted also, I can then read the image file on the 3rd pc running windows)

 

Also if during that lock on a 3rd pc (windows) I do try to use teracopy to copy that somehow locked file then teracopy tells me something like that the file is locked and asks me if I want to unlock it, doing it also lifts that lock (I can post a screenshot showing that if you don't know what I'm talking about).

 

I do ask myself what can be different for samba to access a protected or a cache share? just a timming issue that may trigger a problem on true image? or is there something else that may cause it like... is it ok to open a file from protected array multiple times at same time a read multiple parts of time (multiple handles)? any idea?

 

This is not a major problem to me as most of times I will just want to write image files to the cache drive really, and only then move them to parity protected (as it is obviously faster to create images that way), anyway I'm posting this as I do find it strange what the hell true image may be doing to cause this problem with unraid parity protected shares.

 

Sorry if I have been too long but I did tried to put all details I could on my message, if you need I test something more please just ask.

 

When you say it works on a cache-only share... are you accessing the share via it's share name, or via the 'cache' share.  That is, suppose you have a cache-only share that you named 'backup', are you referencing this share as:

 

a) \\tower\backup

 

or

 

b) \\tower\cache\backup

 

 

I've always received an error that the share is no longer available after the backup process starts. Same with Windows Image tool. Some files were created however and I can still browse the share without issue.

When you say it works on a cache-only share... are you accessing the share via it's share name, or via the 'cache' share.  That is, suppose you have a cache-only share that you named 'backup', are you referencing this share as:

 

a) \\tower\backup

 

or

 

b) \\tower\cache\backup

 

Sorry if it was not clear I did tried to add many details and maybe it got confuse/bloated

 

I meant "a)", an user share set on unRaid as "Use cache disk: only".

 

In all my tests I did always tried to access the user shares, never discX or cache shares directly.

 

In sum:

 

- accessing \\tower\tmp (set as cache only) works fine

 

- accessing \\tower\pub (set as a share on parity protected array and no cache enabled for this share) gives me the weird problems I described

 

Will test true image accessing cache and discX shares directly soon and let you know what happens.

 

Anyway these problems only really happen with true image as I did already had all kinds of apps reading/writing from these same user shares on parity protected array, even vm's running live with hdd image files stored remotely on the protected array and stressing read/write on it a lot as you can imagine... and no problems at all... only really true image seems to cause this.

 

It sounds like your problem is most likely due to the way Acronis looks at the available disc space prior to most any operation.  When trying to access a user share, which is across multiple discs, any available disc query will likely NOT look normal to acronis that is expecting a standard response as seen with accessing a single disc.

 

  I have had other similar issues using disc back-up utilities in addition to Acronis, as well as some other programs, (such as some spreadsheet and word processing programs), that seem to make attempts to capture and freeze disc storage for what essentially becomes an unknown destination file size, since the file is in the process of being created, so the actual final file size is unknown.  This seems to only be an issue when writing to USER SHARES, that span more than ONE disc.  Single disc user shares and as you stated cache only shares also, do not seem to be effected.  This seems to support my thoughts of why these failures occur with multi-disc user shares.

 

  As a result... I always write ONLY to specific DISCS and not user shares when making data back-ups on-the-fly that is being compressed and created at the same time where the final file size is unknown.  Making copies and moving back-up files later to user shares will of course not cause any problems.

 

  Hope that might help to let you know, why I believe this does occur, and why you may want to do what I have done...  I have created an ACRONIS directory on only ONE of my unRAID discs on my back-up server.  I always perform ANY back-up operation ONLY bay accessing that directory directly  via \\unRAIDservername\discx\ACRONIS - where unRAIDservername is replaced by the name of the unRAID server, and discx is replaced by the drive with the ACRONIS folder that I wish to write to.

 

  I also appologize for such a long reply.  Hopefully it will help everyone that may read this in the future though!  :-)

 

 

I havent done a lot of testing, but I usually just write to \\unraid\cache\Backup from Acronis just because its the fastest way of writing to my server.

Did and re-did a few more tests and:

 

- accessing \\tower\tmp (set as cache-only user share) works fine

 

- accessing \\tower\pub (set as an user share on parity protected array and no cache enabled for this share) gives me the weird problems I described.

 

After reading Electron286 post I did also tried to edit this user share to use only 1 hdd (Included disk(s): disk1), then it haves only 600GB free but that doesn't help.

 

- accessing \\tower\disc1\pub works fine

 

may it be shfs/fuse related? but \\tower\tmp also go through it right?

 

but I think it also seems timing related, as for eg.:

 

1. if right after unraid server restart (no files cached at all) I access \\tower\pub with true image then the problem happens, and in fact I don't even need to actually start the diff backup, just on the step to select existing backup file (it will read it and show some infos about the selected backup, partitions structure, etc) then it hangs immediately (tested 3 times), and lsof on unraid shows this:

 

root@unRAID:~# lsof | grep Backup
shfs      4207       root    4u      REG        9,1 15190548722      12439 /mnt/disk1/pub/BackupC.tib
smbd      8351     nobody   30u      REG       0,13 15190548722         25 /mnt/user/pub/BackupC.tib

 

no data being transferred on network, just freezed and these handles open... if I reset true image pc handles remain for some time... if instead of reset true image pc I stop array on unraid server then hadles get closed and true image unfreezes.

 

2. however after I access \\tower\disc1\pub directly, then if I access \\tower\pub (exactly like in 1.) then it will work now, until I restart unraid server or stop/start array (I guess because file at disc1\pub get's cached? that's why I suspect it may be timming related).

 

I did repeated these tests at least 3 times to make sure I could always reproduce what I'm posting here.

 

 

Also if during that lock on a 3rd pc (windows) I do try to use teracopy to copy that somehow locked file then teracopy tells me something like that the file is locked and asks me if I want to unlock it, doing it also lifts that lock (I can post a screenshot showing that if you don't know what I'm talking about).

 

Did some more tests and found that this is not correct, there was some confusion on my 1st tests on this, sorry for that, teracopy really shows a message about file in use by other process and there is an option to unlock it (but in this case not correct... teracopy probably "thinks" it can't access file as it is open by other process on the pc that teracopy is running at, but this is not obviously the case as this is a 3rd pc and the file is locked at unraid server, not at this 3rd pc). I did probably got the (wrong) idea that unlock would unlock it because in the mean time the lock disappeared on unraid server (it disappears after some minutes).

Not sure if this can be useful... I did enabled samba log (log level = 2), attached.

 

Did booted true image, selected a few backup files (you will see multiple backup file names showing) it didn't freezed at just doing that (sometimes it does) then I did tried to start diff backup to BackupC.tib (there is also BackupC2.tib and BackupC3.tib on server already from previous tests), it would be supposed it create BackupC4.tib but it did hang/freeze at 0% doing nothing (I guess that at this time it should read existing backup file). lsof:

 

root@unRAID:~# lsof | grep pub
shfs      8354       root    4u      REG        9,1 15190548722      12439 /mnt/disk1/pub/BackupC.tib
smbd      8456       root  cwd       DIR       0,13         320          7 /mnt/user/pub
smbd      8456       root   31u      REG       0,13 15190548722         27 /mnt/user/pub/BackupC.tib

 

Then I did hard reset the PC running true image, at 04:02 windows boots at that PC... "handles" still visible on lsof on unraid server and file access is locked until near 04:21 then there is a timeout entry at log and they disappear, file is unlocked again.

 

I did noticed that there is on log some successive and fast file opens/closes, maybe related? also as file get's locked (because it is open for write?) maybe there is an attempt to open the yet locked file or something similar... just guesses...

 

Btw, despite I'm posting these infos to try to help checking this issue, as I did stated above I don't want to push you looking at this problem with great priority, most of times I will really create backups on the cache drive for performance I'm just reporting it as it may be useful to identify a possible problem that may eventually also be triggered by something other than true image (despite so far I didn't found any)

log.smbd.txt