• Samba spitting out errors when I do a windows copy (Also making it not working)


    Samy
    • Solved

    Hello everyone,

     

    I use my Unraid install as my important data holder among other things, but since few days (3 days to a week), I'm not able to copy anything in it, each time I try to launch a copy, the transfer get stuck on starting for a couple of seconds, then get stuck for 10 to 20 seconds between each two files, then after a couple of files, it just stops, also, if I try to cancel the transfer, it get stuck on cancelling for around 20 seconds to a minute sometimes, before eventually cancelling.

     

    This have been for days and I have tried updating to the latest version without any results.

     

    Now the issue is becoming serious and I really need to access my files, almost everything is on my Unraid machine.

     

    When I look at the logs, each time I start a transfer, the system start spitting this error

    Apr 23 06:36:33 Burdj winbindd[13785]: [2021/04/23 06:36:33.708273, 0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
    Apr 23 06:36:33 Burdj winbindd[13785]: idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba

     

    Please help me as when what an annoyance few days ago is critical really right now, thank you very much

    burdj-diagnostics-20210423-0648.zip




    User Feedback

    Recommended Comments

    Hi there,

     

    As an FYI, I wouldn't have reported this as a "bug" just yet, as this could be something amiss with your system.  If this was a bug related to Samba, I'm fairly certain we'd have a plethora of users reporting the same thing.

     

    The first thing I'd like you to try is rebooting in safe mode.  See if you can reproduce the issue in that mode.  If so, please reattach your diagnostics after you've reproduced it in safe mode so we can review again.  Thanks.

    Link to comment
    On 4/26/2021 at 10:00 PM, jonp said:

    Hi there,

     

    As an FYI, I wouldn't have reported this as a "bug" just yet, as this could be something amiss with your system.  If this was a bug related to Samba, I'm fairly certain we'd have a plethora of users reporting the same thing.

     

    The first thing I'd like you to try is rebooting in safe mode.  See if you can reproduce the issue in that mode.  If so, please reattach your diagnostics after you've reproduced it in safe mode so we can review again.  Thanks.

    Hello,

    I'm sorry for not posting any update sooner, I was too busy trying to find ways to store my data elsewhere so I can restart my server...

     

    I just did what you told me and I still have the same issue, writing very slow then fails, but reading is perfectly normal.

    I stopped the parity check during safe mode to be sure it's not the issue.

    I also stopped the docker and the VM services, just to remove that out of the way.

     

    Please find attached the diagnostics, thank you for your help ❤️

    burdj-diagnostics-20210430-0222.zip

    Edited by Samy
    Link to comment

    Hi there and thanks for completing that task and getting the diagnostics updated.  I've honestly never seen those particular messages in a server before, so we will need to do some investigating to see what's going on.

    Link to comment
    9 hours ago, jonp said:

    Hi there and thanks for completing that task and getting the diagnostics updated.  I've honestly never seen those particular messages in a server before, so we will need to do some investigating to see what's going on.

     

    Take your time, I have some days of storage on external hard disks, even though it's a pain for me, I appreciate that somehow I managed to land on a bug or a mishap that will improve Unraid 

    Link to comment

    Hello,

     

    Is there any update ? In the worst case scenario, we can discuss a way to give you access so you can diagnose the issue directly on the machine. 

     

    Best regards,

     

    Link to comment

    My syslog server is hammered with these as well - All of the messages appear to be this:

     

    idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba

     

    I can provide the logs or diagnostics as needed.

    Link to comment

    The issue has been solved, Apparently SwOS forwarding ingress rates doesn't work correctly, in all honesty I'm suspecting Windows more than Unraid here.

    image_2021-06-14_103409.png

    Link to comment

    I have multiple servers with this exact same issue.

     

    <SERVERNAME> winbindd[21875]: idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba

     

    Not sure I understand the solution or even the problem. Which Plug-in is the issue?

     

    Plugins:

    CA

    Fix Common Problems

    Unassigned Devices

    User Scripts

    ZFS for unRAID 6

     

     

     

    Link to comment
    On 7/18/2021 at 5:11 PM, Holmesware said:

    I have multiple servers with this exact same issue.

     

    <SERVERNAME> winbindd[21875]: idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba

     

    Not sure I understand the solution or even the problem. Which Plug-in is the issue?

     

    Plugins:

    CA

    Fix Common Problems

    Unassigned Devices

    User Scripts

    ZFS for unRAID 6

     

     

     

     

    I believe Samy traced his problem to an issue with his MikroTek router, not something on Unraid himself.  I'm getting this error constantly, but I'm not using a MikroTek router, so my cause must be something else.

     

    Link to comment

    I saw that post too and reposted becuase I do not run a MikroTek router either and I have 4 unRAID boxes with the same error.

     

    This log entry is made when a connection to an SMB share is made from a windows 10 machine.

     

    Jul 27 10:39:25 <SERVER> winbindd[1428]: [2021/07/27 10:39:25.090439, 0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
    Jul 27 10:39:25 <SERVER> winbindd[1428]: idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba

     

    This log entry is made when someone goes into a shared mapped drive of an smb share and does something like copy a file or create a directory. Deleting a file will also generate this entry.

     

    Jul 27 10:23:06 <SERVER> smbd[22439]: sys_path_to_bdev() failed for path [.]!
    Jul 27 10:23:06 <SERVER> smbd[22439]: [2021/07/27 10:23:06.104268, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota)

     

    The path[.]! of the log entry will reflect the name of any actions taken in a sub folder.

     

    Jul 27 10:35:42 <SERVER< smbd[2160]: sys_path_to_bdev() failed for path [<FOLDER NAME>]!
    Jul 27 10:35:42 <SERVER> smbd[22439]: [2021/07/27 10:35:42.786276, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota)

     

    Server seems to die when a large number of people connect to it at the same time, like start of shift.

     

    I have the what, but still searching for a why.

    My logs are as clean as they have ever been tracing down all the little issus.

     

    I'm still digging though this. 

     

    Link to comment

    From the unRAID server you're having this error from; Run the command nmblookup -S <SERVER NAME> -d 5

     

    Somewhere in there look for:

    doing parameter null passwords = Yes

    WARNING: The "null passwords" option is deprecated
    doing parameter idmap config * : backend = hash

     

    Check out the /etc/samba/smb-names.conf file

    null passwords = Yes
    idmap config * : backend = hash
    idmap config * : range = 10000-4000000000

     

    This has to be related to the log entry

    winbindd[1428]: idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba.

     

    Not sure how to fix this but I think I'm on to something.

     

     

     

    Link to comment
    On 7/27/2021 at 4:38 PM, Holmesware said:

    From the unRAID server you're having this error from; Run the command nmblookup -S <SERVER NAME> -d 5

     

    Somewhere in there look for:

    doing parameter null passwords = Yes

    WARNING: The "null passwords" option is deprecated
    doing parameter idmap config * : backend = hash

     

    Check out the /etc/samba/smb-names.conf file

    null passwords = Yes
    idmap config * : backend = hash
    idmap config * : range = 10000-4000000000

     

    This has to be related to the log entry

    winbindd[1428]: idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba.

     

    Not sure how to fix this but I think I'm on to something.

     

     

     

     

    I'm not really familiar with samba at all, but based on the idmap source code here -

     

    https://github.com/samba-team/samba/blob/master/source3/winbindd/idmap_hash/idmap_hash.c

     

    And a couple of commits around it, it sounds like we shouldn't have this in our configs anymore 

     

    idmap config * : backend = hash
    idmap config * : range = 10000-4000000000

     

    That being said, I don't know what to replace it with.  It looks like it's being used to hash a AD userid to a unix userid?

     

    https://marc.info/?l=samba-technical&m=148768565527552&w=2

     

    EDIT: Ok, yes this is the problem.  I've no idea at the moment how to work around it though.

     

    See: https://www.samba.org/samba/docs/current/man-html/idmap_hash.8.html

     

     

    Edited by Clevernickname
    • Thanks 1
    Link to comment

    https://www.samba.org/samba/docs/current/man-html/idmap_tdb.8.html

    https://www.samba.org/samba/docs/current/man-html/idmap_ad.8.html

     

    One of these might be the answer.

     

    I'll test it if you can help me find a way to make changes to the smb-names.conf file that persist through a restart of the samba service.

     

    POSSIBLE SOLUTION:

    **** identify error ****

    open the syslog from the webgui of unriad and watch for the idmap error message

     

    From a windows machine command prompt:

    net use A: \\<unraid server name>\<share name>

     

    go into A: drive and dir

    Look for the idmap error in syslog

     

    go back to C drive

    net use /delete A:

     

    **** solution start ****

     

    Go the the UNRAID server add the following lines to the beginning of  /boot/config/smb-extra.conf

     

    [global]

    idmap config * : backend = tdb

    idmap config * : range = 1000-4000000000

     

    Restart Samba with the command 'samba restart'

     

    **** test solution ****

     

    open the syslog from the webgui of unriad and watch for the idmap error message

     

    From a windows machine command prompt:

    net use A: \\<unraid server name>\<share name>

     

    go into A: drive and dir

    No idmap error in log

     

    Can someone back this up? I've tested it on 2 of my servers with success.

     

     

    Edited by Holmesware
    • Thanks 1
    Link to comment
    10 hours ago, Holmesware said:

    https://www.samba.org/samba/docs/current/man-html/idmap_tdb.8.html

    https://www.samba.org/samba/docs/current/man-html/idmap_ad.8.html

     

    One of these might be the answer.

     

    I'll test it if you can help me find a way to make changes to the smb-names.conf file that persist through a restart of the samba service.

     

    POSSIBLE SOLUTION:

    **** identify error ****

    open the syslog from the webgui of unriad and watch for the idmap error message

     

    From a windows machine command prompt:

    net use A: \\<unraid server name>\<share name>

     

    go into A: drive and dir

    Look for the idmap error in syslog

     

    go back to C drive

    net use /delete A:

     

    **** solution start ****

     

    Go the the UNRAID server add the following lines to the beginning of  /boot/config/smb-extra.conf

     

    [global]

    idmap config * : backend = tdb

    idmap config * : range = 1000-4000000000

     

    Restart Samba with the command 'samba restart'

     

    **** test solution ****

     

    open the syslog from the webgui of unriad and watch for the idmap error message

     

    From a windows machine command prompt:

    net use A: \\<unraid server name>\<share name>

     

    go into A: drive and dir

    No idmap error in log

     

    Can someone back this up? I've tested it on 2 of my servers with success.

     

     

     

    Edit: 0 errors in the last 8 hours on both of my unraid servers after making this change;  I'd say this did it.  I used to get hundreds or thousands of these messages a day.  All my file shares still work, and AD security is being respected as well.  

     

    ----

     

    Alright, this seems to have done the trick for me as well.

     

    I get a lot of these through out the day, so I'll check my log file again tonight.

    Edited by Clevernickname
    check logs after 8 hours
    Link to comment

    Working for me too.

     

    Now the only error in my logs is this one.

     

    Jul 29 20:21:53 <SERVER> smbd[16622]: sys_path_to_bdev() failed for path [.]!
    Jul 29 20:21:53 <SERVER> smbd[16622]: [2021/07/29 20:21:53.567047, 0]../../source3/lib/sysquotas.c:565(sys_get_quota)

     

    The path[.]! will refect what ever path the connected user it in. I get tons to these as well.

    Link to comment
    11 hours ago, Holmesware said:

    Working for me too.

     

    Now the only error in my logs is this one.

     

    Jul 29 20:21:53 <SERVER> smbd[16622]: sys_path_to_bdev() failed for path [.]!
    Jul 29 20:21:53 <SERVER> smbd[16622]: [2021/07/29 20:21:53.567047, 0]../../source3/lib/sysquotas.c:565(sys_get_quota)

     

    The path[.]! will refect what ever path the connected user it in. I get tons to these as well.

     

    Interesting.  I just checked my logs and I don't have any instances of those.  I wonder if our setups are different enough that it doesn't occur for me?  My logs only go to back 7/16/2021, but I don't have that error message at all.

     

    I have a 2019 AD server with failover to a secondary;  Both unraid boxes are joined to the AD server and all share access is managed by AD.

     

    Both are setup to log to seq (https://datalust.co/seq) with seq running the syslog plugin.

    Link to comment

    I'm using the ZFS plugin on my unRAID boxes with Zentyal (ubuntu) for my AD. AD is also managing access via Security Groups. My setup is SUPER cheap (no monthly fee) for a domain setup that can manage Windows 10 machines and be Managed from Windows Domain Management Tools. Works with O365 with very little hassel. Passwords don't sync to O365 but so what. If they don't line up, somethings amiss and needs to be looked at anyway.    <squirrel>

     

    It's something to do with smb shares on ZFS volumes. BTRFS and XFS generate the similar errors when a user is mapped to a sub folder of an smb share. Something to do with the entry not being in the fstab file which is where smbd is looking for quota information apparently.

     

    One solution was to add the entries of the mapped subfolders to the fstab but i'm sharing the \usershares folder and mapping P: to \usershares\<username> so that means an entry is needed for each user. I haven't been able to make this work anyway.

     

    I'll make another post once I get some more testing done and I'm able to form the right question, but it's not going as well.

    From what I found with the idmap error, it looks like the Samba part of unRAID may need a little attention.

    Edited by Holmesware
    Link to comment

    I know this is an old thread, but I had to drop a huge thanks for @Clevernickname for this. I have been having issues for a while but only recently had time to dive in to them. I think this was the root of it all. I only found this was happening due to the need to move a huge file from my windows file server (which unraid was meant to decommission over a year ago) to the unraid array. Thanks a ton. Now, lets see if this resolves any of my issues around Plex. 👏

    On 7/28/2021 at 10:06 PM, Clevernickname said:

     

    I'm not really familiar with samba at all, but based on the idmap source code here -

     

    https://github.com/samba-team/samba/blob/master/source3/winbindd/idmap_hash/idmap_hash.c

     

    And a couple of commits around it, it sounds like we shouldn't have this in our configs anymore 

     

    idmap config * : backend = hash
    idmap config * : range = 10000-4000000000

     

    That being said, I don't know what to replace it with.  It looks like it's being used to hash a AD userid to a unix userid?

     

    https://marc.info/?l=samba-technical&m=148768565527552&w=2

     

    EDIT: Ok, yes this is the problem.  I've no idea at the moment how to work around it though.

     

    See: https://www.samba.org/samba/docs/current/man-html/idmap_hash.8.html

     

     

     

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.