Tomato needs a fix for external SMB/CIFS shares. (-nobrl)

Discussion in 'Tomato Firmware' started by RichtigFalsch, Dec 16, 2013.

  1. RichtigFalsch

    RichtigFalsch Networkin' Nut Member

    Hi, Tomato folks!

    As suggested by koitsu in the tomato RAF thread, i hereby open a Thread regarding the data corruption problem i occured using recent tomato-Shibby builds on my Netgear 3500Lv2.

    I'll quote myself:
    The CIFS Mount Option needs the '-nobrl' parameter added, otherwise it'll corrupt data written by Tomato's FTP Server to SMB locations on a PC using Vista or higher!

    For example, I have the situation that my VSFTP on Tomato shall have it's root directory on a SMB/CIFS Share on my Windows8.1-equipped Notebook. All files I put on that FTP Server remotely would become corrupted, usually bearing wrong filesize, and won't be executable/decompressable afterwards. After some reading I found that using the '-nobrl '-parameter could help against this and tried it, using some scripts through Tomato's WebIF. This worked out functionally, but leaving me with even more scripts in my anyways excessive configuration. so it would be really great, having the -nobrl parameter in cifs mount configuration per default, or alternative, if this could cause any disadvantage, an option for enabling this parameter if needed.

    Thank you for attention :)
  2. RichtigFalsch

    RichtigFalsch Networkin' Nut Member


    I've experienced that in recent Tomato Build (Shibby 116) this still isn't working.

    Could you please have a look at this? I think it'd just make very little effort, for fixing some very big annoyance!

    Thank you :)
  3. koitsu

    koitsu Network Guru Member

    For developers: the nobrl (enn oh bee arr ELL) mount.cifs option is documented here:

    The issue has to do with byte range locking on a file (i.e. the client normally tells the server "I want to lock 128 bytes starting at offset 19394" so that no other CIFS client/user can modify that part of the file while the person has it locked). As described this doesn't always work/has problems, so it doesn't surprise me that nobrl fixes the problem for some people.

    I would suggest making this into a checkbox labelled something like "Disable byte-range locking", where the default value should be checked. Alternately just make it a text input row where you can enter flags/options yourself ("Extra mount.cifs options", with a link to the aforementioned web page, so people would know what's available, with an example of something like gid=1234,nobrl where the firmware itself prepends the necessary -o argument in front of that).
  4. shibby20

    shibby20 Network Guru Member

    mount.cifs is a symlink of BUSYBOX, not samba.
  5. koitsu

    koitsu Network Guru Member

    I took the time to review the source code.

    I'm not exactly sure how Busybox fits into the picture, but I do see code in busybox/util-linux/mount.c that has UNC references. But that code just seems to call mount(2), which means the kernel (or a kernel module) must be handling the CIFS support.

    I don't see anything in mount for nobrl as a supported argument (ex. -o nobrl), but I did not review the code thoroughly to see if it would blindly pass other arguments on to mount(2) for parsing by the kernel.

    I did find that /sbin/mount-cifs (note the hyphen, not period) is a symlink to /sbin/rc, and review of that code turns up cifs.c which has a call to modprobe("cifs") when mount-cifs -m is used. Sure enough, on an router I do in fact have /lib/modules/, which implies the CIFS support is part of the Linux kernel.

    The module details contain this:

    description=VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
    author=Steve French <>

    I found the source code in linux/linux/fs/cifs which confirms all that.

    Within the source there (esp. connect.c) I see code that supports nobrl. It's even mentioned in the README too.
  6. RichtigFalsch

    RichtigFalsch Networkin' Nut Member


    I don't really know how Tomato is handling the settings the user has set in the gui, but i assume that it probably is using the usual mount command for mounting the configure paths, isn't it?

    And if it's using the mount command, there should be the possibility for adding the needed parameter to that string.
    For example I use the following string for mounting my shares at the moment:

    mount -t cifs -o username=username,password=password -o nobrl // /cifs1/
    So wouldn't it be possible to add that '-o nobrl' to the default command line that is generated by the Tomato script when it's processing the CIFS configuration?

    Koitsus suggestion for integrating this optionally sounds like a good way for solving this.

    I see this as a major problem, yet, because there's reliable destruction of files at the current state.

    Thank you for support, koitsu and shibby :)
    Last edited: Feb 10, 2014
  7. mstombs

    mstombs Network Guru Member

  8. koitsu

    koitsu Network Guru Member

    nobrl works just fine on Tomato. Want proof? Here you have it, from my own system talking to a FreeBSD-based Samba system on the same LAN:

    root@gw:/tmp# mkdir foo
    root@gw:/tmp# mount -t cifs -o username=user,password=pass,nobrl // /tmp/foo
    root@gw:/tmp# mount | grep cifs
    // on /tmp/foo type cifs (rw,unc=\\\mp3,username=user,posixpaths,rsize=16384,wsize=57344)
    Same can be accomplished using multiple -o arguments if needed (as @RichtigFalsch shows).

    Proof that nobrl is being passed to the mount(2) call can be verified using strace:

    root@gw:/tmp# strace -s 256 mount -t cifs -o username=user,password=pass,nobrl // /tmp/foo
    mount("//", "/tmp/foo", "cifs", MS_SILENT, "username=user,password=pass,nobrl,unc=\\\\\\mp3,ip=") = 0
    I already looked at the mount code for Busybox on Tomato -- it doesn't need to support the individual option, it simply passes it along to the underlying mount(2) call, which then gets handled by the cifs.ko module (this is not Samba, this is the Linux CIFS/SMB client kernel module). It DOES manipulate some of the options, such as turning certain syntaxes like //ipaddr/share into unc=\\ipaddr\share and the like.

    And as I indicated the cifs.ko module does support nobrl. (If it didn't, that mount call would fail in some manner, probably some errno like Operation not permitted).

    If folks really want me to verify that byte range locking isn't used at the CIFS/SMB layer I can do that via packet captures, but the above is a pretty damn good indicator that nobrl is at least being passed to the cifs.ko module.
  9. mstombs

    mstombs Network Guru Member

    Which explains why BusyBox folk didn't see it as their problem!

    Can you use the tomato custom option using the nvram var "cifs_opts" to add this?

  10. koitsu

    koitsu Network Guru Member

    Two things:

    1. Based on that code I would say you could do nvram set cifs_opts=nobrl && nvram commit and the nobrl option would be included in the automatic CIFS client mount feature in the GUI, I believe. It would also apply to all CIFS mounts defined there universally. However...

    2. With the current version of Busybox, outside of using strace, there's no way to confirm the existence of nobrl being used. I tried looking through the Busybox code, and there's two spots that caught my eye (the MS_xxx definitions near the top, and the array filled with null-terminated strings around line 1283). The latter (~1283) seems to be for NFS only, so I'm not exactly sure where the strings are coming from -- maybe from cifs.ko itself (I haven't looked there yet). For example "posixpaths" in my above example (see first code block) isn't mentioned anywhere in the Busybox mount.c code, yet it obviously shows up.
    Last edited: Feb 11, 2014
    Ped Man likes this.
  11. RichtigFalsch

    RichtigFalsch Networkin' Nut Member


    Is there something going on with this? If you need help with testing i could do that.
  12. Ped Man

    Ped Man Networkin' Nut Member

    Using the command "nvram set cifs_opts=nobrl" fixed my problem that myself and RichtigFalsch was experiencing.
    RichtigFalsch likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice