Numerical result out of range

Getting Help
1

Hello,

while doing a backup of a directory that is mounted via SMB from a Windows Server 2016 I get the following warning for some files:

using parent snapshot 450441a7
scan [/mnt/restic/source/data]
[4:01] 94079 directories, 629167 files, 311.562 GiB
scanned 94079 directories, 629167 files in 4:01
e[2K
warning for /mnt/restic/source/data/FILE.PDF: Listxattr: xattr.List /mnt/restic/source/data/FILE.PDF : numerical result out of range
[…]

Should I care about this message or can I safely ignore it?

Best regards,
Philipp

2

Hi!

What system are you running restic on and can you paste the full output of restic version?

As it’s a warning rather than an error, I wouldn’t be too worried, but I’m really curious what causes it.

3

It’s the binary release of restic 0.8.3 running on a debian stretch
Linux backup 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64

~#./restic version
restic 0.8.3
compiled with go1.10 on linux/386
4

Thanks!

I’m just poking around a little in order to learn. It seems to me that the warning comes from https://github.com/pkg/xattr/blob/master/xattr_linux.go#L37 (read, err := syscall.Listxattr(path, buf)), which in turn is due to https://golang.org/src/syscall/zsyscall_linux_amd64.go?s=15306:15366#L652 (r0, _, e1 := Syscall(SYS_LISTXATTR, uintptr(unsafe.Pointer(_p0)), uintptr(_p1), uintptr(len(dest)))).

Error err/e1 is number 34, ERANGE in errno(3), which means that the supplied buffer (buf and dest in the code above) is too small to hold the result from the syscall. But that’s weird, because in https://github.com/pkg/xattr/blob/master/xattr_linux.go#L35 (buf := make([]byte, size)) the buffer is supposed to be sized equally to the expected result size.

I’d love to have it reproducable locally to inspect the values in the program at runtime, curious what the expected size and buffer size is…

Could the problem be that buf in buf := make([]byte, size) is allocated in number of bytes, while the number in sz in https://golang.org/src/syscall/zsyscall_linux_amd64.go?s=15306:15366#L653 (sz = int(r0)) represents a number of some other type than bytes? Just thinking out loud.

5

Okay, this seems to possibly be the cause of the issue: https://github.com/xattr/xattr/issues/42

Thanks to the Gophers in #go-nuts on freenode for helping me understand this!

Someone is looking into submitting a fix upstream in Samba. Until then/regardless restic probably need to make the buffer buf size+1 bytes large as a workaround.

6

@philvx Can you tell us if you are experiencing this on SMB1 or SMB2? Can you try it on the other version?

7

I am experiencing this on SMB1 I suppose as ‘man mount.cifs’ says that version 1.0 is the default:

vers=
           SMB protocol version. Allowed values are:

           ·   1.0 - The classic CIFS/SMBv1 protocol. This is the default.

           ·   2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and Windows Server 2008. Note that the initial release
               version of Windows Vista spoke a slightly different dialect (2.000) that is not supported.

           ·   2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

           ·   3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.

           Note too that while this option governs the protocol version used, not all features of each version are available.

I just tested mounting the share with ‘vers=2.0’ and the warning disappears! Thank you so much for finding out, this was great work!

1 Like
8

Oh, that’s good to know, thanks for trying it with SMB2 and reporting back!

9

It’s probably going to be fixed soon in https://github.com/pkg/xattr/issues/16 - meanwhile the workaround is to mount using SMB2 instead of SMB1.

10

The mentioning of SMB has summond me from the depths!

This https://aka.ms/smb1rs3 is worth a look if you’re on the end of Windows Server and Windows Client infrastructure. The upsides of using SMB3 are worth it - one can read about it over here https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

Also please please please don’t continue using a dialect that old. If you have an application/vendor that still holds on to it you can check at https://aka.ms/StillNeedsSmb1 if the application/vendor is listed and if they plan on upgrading - if not, Ned Pyle will gladly add them to the wall of shame.

1 Like