Hangs !!! Accessing fuse filesystem in Windows through Samba

Thu Mar 12 12:57:17 MDT 2015

On Thu, Mar 12, 2015 at 11:23 AM, Raj Kumar Sanpui
<raj.kumar.sanpui at gmail.com> wrote:
> Hi Richard,
>
> Thanks, as i pointed out in fuse forum as well, moving the blocking call to
> read( ) instead of open( ) together with using the AIO interface in Samba
> 4.1 solved the issue.
>
> However, we noticed the following, after we used the openSUSE Samba 4.1 RPMs
> on SLES (sles latest official release is 3.6 which has no AIO support):
>
> 1) I had mapped 2 CIFS mounts through Linux, and when i tried mapping the
> same share in Windows, i got a core dump, which didn't used to happen
> earlier.
>      Not sure, if the core is really due to dual mapping of Windows + Linux
> of same share, which should not be the case.
>
>     Here is the stack trace:
>
>     [2015/03/12 17:57:55.150088,  0]
> ../lib/util/become_daemon.c:124(daemon_ready)
>   STATUS=daemon 'smbd' finished starting up and ready to serve connections
> [2015/03/12 18:06:41.292473,  0]
> ../source3/smbd/smbXsrv_session.c:1353(smbXsrv_session_logoff)
>   smbXsrv_session_logoff(0x1a8a958e): failed to delete global key
> '1A8A958E': NT_STATUS_NOT_FOUND
> [2015/03/12 18:06:41.292563,  0]
> ../source3/smbd/smbXsrv_session.c:1462(smbXsrv_session_logoff_all)
>   smbXsrv_session_logoff_all: count[1] errors[1] first[NT_STATUS_NOT_FOUND]
> [2015/03/12 18:06:41.292580,  0]
> ../source3/smbd/server_exit.c:158(exit_server_common)
>   Server exit (termination signal)

Hmmm, smbXsrv_session_logoff_all failed ... I don't have the time to
look into why. Maybe someone else does. Howevver, you could also pull
that source and check and maybe build a new RPM with some extra
debugging in it.

> [2015/03/12 18:06:41.292596,  0]
> ../source3/smbd/server_exit.c:161(exit_server_common)
>   exit_server_common: smbXsrv_session_logoff_all() failed
> (NT_STATUS_NOT_FOUND) - triggering cleanup
> [2015/03/12 18:06:41.292765,  0] ../source3/lib/util.c:788(smb_panic_s3)
>   PANIC (pid 24942): smbXsrv_session_logoff_all failed
> [2015/03/12 18:06:41.293414,  0] ../source3/lib/util.c:899(log_stack_trace)
>   BACKTRACE: 21 stack frames:
>    #0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7f03e35c327a]
>    #1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x2b) [0x7f03e35c334b]
>    #2 /usr/lib64/libsamba-util.so.0(smb_panic+0x3a) [0x7f03e542db7a]
>    #3 /usr/lib64/samba/libsmbd-base-samba4.so(+0x16fbbb) [0x7f03e5020bbb]
>    #4 /usr/lib64/samba/libsmbd-base-samba4.so(+0x16fe1e) [0x7f03e5020e1e]
>    #5 /usr/lib64/samba/libsmbd-shim-samba4.so(exit_server_cleanly+0x12)
> [0x7f03e2f82b42]
>    #6 /usr/lib64/samba/libsmbd-base-samba4.so(+0x138940) [0x7f03e4fe9940]
>    #7 /usr/lib64/libtevent.so.0(tevent_common_check_signal+0x258)
> [0x7f03e2021448]
>    #8 /usr/lib64/libsmbconf.so.0(run_events_poll+0x23) [0x7f03e35d8fc3]
>    #9 /usr/lib64/libsmbconf.so.0(+0x3a5e7) [0x7f03e35d95e7]
>    #10 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f03e201de4d]
>    #11 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b)
> [0x7f03e201deeb]
>    #12 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_process+0x7cb)
> [0x7f03e4fee5eb]
>    #13 /usr/sbin/smbd(+0x8395) [0x7f03e5a8a395]
>    #14 /usr/lib64/libsmbconf.so.0(run_events_poll+0x28b) [0x7f03e35d922b]
>    #15 /usr/lib64/libsmbconf.so.0(+0x3a68e) [0x7f03e35d968e]
>    #16 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f03e201de4d]
>    #17 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b)
> [0x7f03e201deeb]
>    #18 /usr/sbin/smbd(main+0x1422) [0x7f03e5a8bd62]
>    #19 /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f03e1cc1c36]
>    #20 /usr/sbin/smbd(+0x6879) [0x7f03e5a88879]
> [2015/03/12 18:06:41.293539,  0] ../source3/lib/dumpcore.c:318(dump_core)
>   dumping core in /var/log/samba/cores/smbd
>
>
> 2) When copying file in Windows from Samba share, we got this error:
>
> "An unexpected error is keeping you from copying the file. If you continue
> to receive this error, you can use the error code to search for help with
> this problem.
> Error 0x80070021: The process cannot access the file because another process
> has locked a portion of the file"
>
> However, the above error got resolved when we used: kernel oplocks = no in
> smbd.conf
>
> 3) Although, it works fine without any issues currently with AIO, but 1 out
> of 15 tries, still sometime the Windows Samba share still becomes
> unresponsive.
>      Is there any way to optimize the performance further?
>
>
> This is how our smb.conf file looks like:
>
> [global]
>        guest account = myinsite
>        kernel oplocks = no
>        oplocks = no
>        msdfs root = yes
>        workgroup     = MYINSITE-CIFS
>        server string = "MyInSite CIFS Archive"
>        security      = user
>        map to guest = Bad User
>        syslog        = 0
>
>        max smbd processes = 15
>        interfaces = eth* lo
>        bind interfaces only = no
>
>
> [DCCAArchive]
>         comment = Archive File System
>         path = /opt//fuse-mount/ifm
>         read only = No
>         case sensitive = yes
>         public = yes
>         writeable = yes
>         create mask=0777
>         guest ok = Yes
>         aio read size = 1
>         aio write size = 1
>
>
> Please suggest.
>
> Thanks in advance.
>
> kingsmasher1
>
>
> On Tue, Mar 3, 2015 at 8:35 PM, Richard Sharpe <realrichardsharpe at gmail.com>
> wrote:
>>
>> On Tue, Mar 3, 2015 at 2:44 AM, Raj Kumar Sanpui
>> <raj.kumar.sanpui at gmail.com> wrote:
>> > Hello Everyone,
>> >
>> > Thanks for the response.
>> > I added these parameters to our smb.conf, and also as Richarde and
>> > Miklos
>> > (the fuse developer) suggested, moved the blocking part from open( ) to
>> > read( ), but with no difference in behaviour, now i am afraid if these
>> > aio
>> > parameters added (as shown below) are really working.
>> > I checked the Samba log (log.smbd) in /var/log/samba/, but could not get
>> > any
>> > clue.
>> >
>> > Is there any way to find out, if the new parameters added for AIO are
>> > really
>> > working?
>> >
>> > {{{
>> > [FUSEAArchive]
>> >         comment = Fuse Archive File System
>> >         path = /opt/myinsite/fuse-mount/ifm
>> >         read only = No
>> >         case sensitive = yes
>> >         public = yes
>> >         writeable = yes
>> >         create mask=0777
>> >         guest ok = Yes
>> >         aio read size = 0
>> >         aio write size = 0
>> >         aio write behind = /*/
>> >
>> > }}}
>> >
>> > Here are my Samba version:
>> >       # rpm -qa | grep samba
>> >             samba-32bit-3.6.3-0.18.3
>> >             yast2-samba-client-2.17.21-0.5.186
>> >             yast2-samba-server-2.17.13-0.7.5
>> >             samba-client-32bit-3.6.3-0.18.3
>> >             samba-3.3.4-0.1.146
>> >              samba-client-3.3.4-0.1.146
>>
>> Whoa, what is it with all these people still running Samba 3.6.3.
>>
>> That version does not support the aio open parameter.
>>
>> My next suggestion is that you don't wait for the whole file to
>> transfer but start responding to read requests once you have enough
>> data.
>>
>> Either that or shift to a more modern version of Samba, but even there
>> there is a limit to how long you can hold off Windows, I believe.
>>
>> --
>> Regards,
>> Richard Sharpe
>> (何以解憂？唯有杜康。--曹操)
>
>

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)