Update SMB Support

[shadowsports]

Looking for updated SMB support.

Cannot back up windows 8/2012 PC's to my NAS

I understand there are multiple threads about Samba, SMB and error 0xc03a0005 "The version does not support the version of the file format" . I'd just like to add my request for this feature/enhancement.

Thank You

[schumaku]

That's not related to an SMB update at all. Much more about a configuration option required on the SAMBA share level. Have re-added this issue to the QNAP Bug Tracker ref. QTS 4.1 some days ago:
---

[4.1 20131101] SAMBA Customisations (i.e. strict allocate = yes) Wiped By Edit Shared Folder Properties

Customization _mandatory_ for Windows 8.1 Image System Backup and File History are silently wiped when editing the shared folder properties - breaking standard (and highly essential!) Microsoft Windows features.

If this can't be avoided easily, QNAP _must_ add an additional control (along with i.e. Hide Share, oplocks, ... for strict allocate.

In my opinion, strict allocate must be set to yes by default for interoperation with Windows and current OS X clients anyway.

There is more related to Windows 8.1/2012/2012 R2 Image System Backup and File History. Most likely, SMB2 and/or Async I/O does break Image System Backup and File History, too.

Steps To Reproduce

Edit smb.conf, add a "strict allocate = yes" to a share section:

[backup-xyz]
comment =
path = /share/CACHEDEV1_DATA/backup-xyz
browsable = yes
oplocks = yes
strict allocate = yes
ftp write only = no
recycle bin = yes
recycle bin administrators only = no
public = yes
invalid users = guest
read list =
write list = admin,XYZbackup
valid users = root,admin,XYZbackup
inherit permissions = yes
smb encrypt = disabled

Close editor, restart SAMBA.

Now go to Shared Folders -> Action: Property (discussed before - this must be Properties!) and change something, i.e. hide or oplocks.

Check smb.conf again, or try using Windows 8.1/2012/2012 R2 Image System Backup and File History - the customisation is gone, Image System Backup and File History fails.
---

[shadowsports]

Fantastic bug report with everything an engineer would need to reproduce the behavior.

I did see your suggested mod to add "strict allocate" but I'd rather wait for the fix.

Thanks Kurt !!

[eliteman]

I have this same problem. I've added "strict allocate = yes" to the smb.conf and still have this problem. I can't seem to find a way around it. Currently all of my system state backups are broken.

[schumaku]

Hello,
Welcome to the QNAP NAS Community Forum!

I have this same problem. I've added "strict allocate = yes" to the smb.conf and still have this problem.

Firmware version? Does the "strict allocate = yes" remain in the smb.conf [sharename] section on a Microsoft File Share (SAMBA) restart? Most likely yes. Does it remain when change access rights? Most likely no...

-Kurt.

[damasta]

i'd like to add myself to this thread, because I believe I am suffering the same problem.

the short story: it would seen that my trusty old TS409 pro (firmware 3.3.2 Build 0918T) does not support windows 8/8.1 all that well...

the "strict allocate" option seems to be a problem within samba, since not just qnap suffers from this. over at synology and apple they are discussing similar (same?) problems.

after modifying my smb.conf to
[global]
strict allocate = yes

my backups seem to be working again - most of the time. :-/

since I changed that option, my qnap TS409 Pro will start thrashing the disks every so often and CPU load jumps up to ~70% (this caused by smbd and pdflush mainly) and remains there for about 5-10 minutes. during that time, the system barely responds to SMB requests at all, causing my windows to time out - sometimes even causing mapped drives to unmount.

if I attempt to backup with windows 8 or 8.1 (especially the system image backuop) during this time, it will fail - every time. message is either:
"the version does not support the version of the file format" or recently also:
"windows backup was unable to read from the backup target."

if I wait for some 10-20 minutes, the problem goes away and backup commences.

I realize there may be no cause and effect releation here, but I am not enough of a Linux expert to understand the details.

is there anything else I can do to help?

[schumaku]

the "strict allocate" option seems to be a problem within samba, since not just qnap suffers from this. over at synology and apple they are discussing similar (same?) problems.

Let's say shared pain...

after modifying my smb.conf to
[global]
strict allocate = yes

my backups seem to be working again - most of the time. :-/

To be correct: According the SAMBA documentation http://www.samba.org/samba/docs/man/man ... onf.5.html "strict allocate" is for usage in [sharename] sections "(S)" - not the [global] section "(G)". Anything might or might not work properly.

Can't help further on the old NAS I'm afraid.

[eliteman]

Hello,
Welcome to the QNAP NAS Community Forum!

I have this same problem. I've added "strict allocate = yes" to the smb.conf and still have this problem.

Firmware version? Does the "strict allocate = yes" remain in the smb.conf [sharename] section on a Microsoft File Share (SAMBA) restart? Most likely yes. Does it remain when change access rights? Most likely no...

-Kurt.

Current firmware version: 3.3.2 Build 0918T (TS-209 PRO II)

"strict allocate = yes" remains in the smb.conf [sharename] section on restart. I haven't changed access rights to test that, but even with it staying after restart I test a system state backup to it and it fails.

Does this answer your questions?

[schumaku]

Thank you. AFAIK the removal is specific to QTS 4 or certainly QTS 4.1 currently in Beta only.

[rorr]

Thanks - I found that the "strict allocate = yes" option in the smb.conf solved my Windows 8 backup issue.

Unfortunately now my windows server 2008 backups fail when trying to backup the server image to the NAS with this setting.....! arrrrgh.
If I remove the setting then the Server backup works fine (but obviously the Windows 8 backup doesn't...)

Anyone else seen this behaviour?

The event log message isn't very helpful on the Server backup fail:
Backup started at '25/05/2014 20:00:15' failed with following error code '2155348010' (One of the backup files could not be created.). Please rerun backup once issue is resolved.