Holmesware

Win 10 update (KB5028166) - uninstall and re-apply - Fixed all my issues Note: uninstalling the update then rebooting the system triggered installing the update before the login screen. FALSE - This did not happen. The update was removed and stayed removed, but it looks like it will reinstall on the next Windows Update. This has to do with a SAMBA bug in the Zentyal Domain Controller world. https://forum.zentyal.org/index.php/topic,35598.0.html - Unraid mounting an SMB share on a Window 10 Workstation - Remote Assistance now works when initiated remotely - Shared bi-directional USB laser printer now works from remote workstations The Actual Samba Bug - https://bugzilla.samba.org/show_bug.cgi?id=15418 Solved-ish - Until there is a Samba fix for my domain controller I will not be able to reapply KB5028166 to my workstations. SOLVED - Patch for Ubuntu 18.04 LTS Bionc - https://launchpad.net/~ahasenack/+archive/ubuntu/samba-kb5028166/

This happens from 2 different Unraid servers (6.11.5 and 6.12.2) to any Windows 10 Domain connected computer. Mounting a Windows Share <REMOTE COMPUTER> from an Unraid <SERVER> no longer works. Has been working for close to 2 years until now. <SERVER> kernel: CIFS: Attempting to mount \\<REMOTE COMPUTER>\ServerData <SERVER> kernel: CIFS: Status code returned 0xc000018d STATUS_TRUSTED_RELATIONSHIP_FAILURE <SERVER> kernel: CIFS: VFS: \\<REMOTE COMPUTER> Send error in SessSetup = -5 <SERVER> kernel: CIFS: VFS: cifs_mount failed w/return code = -5 <SERVER> unassigned.devices: SMB 3.1.1 mount failed: 'mount error(5): Input/output error The mounting script goes through SMB 3.0, 2.0 and 1.0 with the same error. Lookup up this error: 0xc000018d STATUS_TRUSTED_RELATIONSHIP_FAILURE Comes up with this description. The logon request failed because the trust relationship between this workstation and the primary domain failed. Removing any of these computers from the domain and rejoining it doesn't fix this. The same <REMOTE COMPUTER> (Windows 10) can connect to the an Unraid SMB share with no issues. Trying to manually make the connection from the command line generate the same error. Domain Controller is Zentyal 6.1.6 on Ubuntu 18.04.6 LTS. I have posted this issue in their forums as well. Other things that have stopped working at roughly the same time. - WIndows Remote Assistance - unless it's initiated from the end user with a file or email link. - Shared USB printers that require bi-directional communication. - Basic Kyocera Laser printer - no longer working. - Zebra Label printer - Works fine.

@CallOneTech I'd just like to point out that the posted fix in the dedicated channel for this issue does work. I have 5 Unraid systems with this fix applied in a environment of 70+ users. I know your fustration with this. I had random users loose access to files multiple times daily. Was driving me nuts. This issue with the fix can't be overstated enought: You have to re-apply all the permission to your file structure - this can be rather grizzly but if you planned out your permission structure it shouldn't be that hard. If not, now is the time to get your permissions in order. I learned this lesson hard long ago. @dlandon You may not realize how many people use uraid in an enterprise environment. In my tech circle I'm seeing a movement back to self hosting data for small to medium sized companies especially ones with sensitive data. I use unraid with ZFS in a Zentyal domain controller for Windows 10 worktations. VM for terminal servers and application servers. Docker for FTP service, PiHole, MySQL and whatever else I may need. I've been on the developer side of things. Most projects like this take on a form of their own after a while and go in a direction you did not intend.

ok, just spit balling here.... This issue is for an unraid box connected to a domain. I've been having issues with Windows Store apps being corrupted and having to reinstall them (calculator, snip & sketch, etc.) as the affected user with admin permissions Real pain. Been digging around on this and found that there are updates to GPO templates that will fix this. https://social.technet.microsoft.com/Forums/en-US/aa006d8f-9f01-44bb-bf90-ac0456a42153/group-policy-breaks-start-menu-modern-apps?forum=win10itprosecurity https://www.microsoft.com/en-us/download/confirmation.aspx?id=103667 I'm running Zentyal for a Domain Controller for many reasons including cost, but this issue sounds like it affects Windows and Linux based domains. Could this be part of the problem? I'm trying it out myself but not really confidient I'm going to get it right. Anyone else been down this path?

I manually edited the smb-settings.conf file to what it should be, restarted samba and *something* put it back at the bottom fully commented out. I've only seen it at the top like this. I'll try it again after hours and post video if needed. [global] #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end [usershares] path = /pool/usershares hide unreadable = yes guest ok = yes writeable = yes read only = no create mask = 0770 directory mask = 0770 vfs object = recycle,shadow_copy2 recycle:repository = .recycle recycle:keeptree = yes recycle:versions = yes shadow: snapdir = .zfs/snapshot shadow: sort = desc shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M shadow: localtime = yes [it] path = /pool/it guest ok = yes writeable = yes read only = no create mask = 0775 directory mask = 0775 vfs object = recycle,shadow_copy2 recycle:repository = .recycle recycle:keeptree = yes recycle:versions = yes shadow: snapdir = .zfs/snapshot shadow: sort = desc shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M shadow: localtime = yes [shares] path = /pool/shares hide unreadable = yes browseable = yes guest ok = yes writeable = yes read only = no create mask = 0775 directory mask = 0775 vfs object = recycle,shadow_copy2 recycle:repository = .recycle recycle:keeptree = yes recycle:versions = yes shadow: snapdir = .zfs/snapshot shadow: sort = desc shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M shadow: localtime = yes [AVMTEST] path = /pool/AVMTEST browseable = no guest ok = no writeable = yes read only = no create mask = 0775 directory mask = 0775 [interchange] path = /pool/interchange hide unreadable = yes browseable = yes guest ok = yes writeable = yes read only = no create mask = 0770 directory mask = 0770 #unassigned_devices_start #Unassigned devices share includes # include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end

My one machine with multichannel on was the affected machine, turning it off didn't help. I have a funny bug now with Unassigned Devices putting it's config at the bottom of the smb-extra.conf file and fully commenting it out. My other machines don't do this. There is nothing in the smb-setting.conf file but this started after I removed teh multichannel setting from smb-extra.conf. I'm down to just my own account being the only one that my affected server can't recognize so I'm able to live this with. Oct 6 13:50:50 <SERVERNAME> smbd[22464]: check_account: Failed to convert SID S-1-5-21-2194464868-3260781856-949890820-1145 to a UID (dom_user[<DOMAIN>\<USERNAME>])

Yep, add me to the list a affected users now too. Zentyal 6.1 as a domain controller Windows 10 workstations Multiple Unraid Machines with ZFS Only the heavily used Fileserver (smb) being affected for the last 5 days. Starts with me (the heaviest user) getting forgotten about first, then it forgets some groups, then it's end user chaos. Reach out to me if you want a test environment of 60 users.

WONDERFUL! THANK YOU! This syslog entry has been a real pain when trying to troubleshoot a server for other issues. So much more makes sense now. Patching that samba code to get right of the syslog entry would be really helpful. edit: oh, kernel recompiling... Thank you again.

This is the definitive answer and solution to this issue. If you have an unraid server joined to a samba domain and are getting repeated entries in your syslog: <TIMESTAMP> <SERVERNAME> winbindd[6589]: [<TIMESTAMP>, 0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize) <TIMESTAMP> <SERVERNAME> winbindd[6589]: 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 * CAUTION * Making these changes you will have to re-apply all permissions on files/folder that are Domain related * CAUTION * All Unraid servers in your Domain will need the same exact settings Modify your /boot/config/smb-extra.conf file like this: idmap config * : backend = tdb <-- Used to be hash> idmap config * : range = 3000-7999 <-- Range enough for local users> idmap config <SHORTDOMAINNAME> : backend = rid idmap config <SHORTDOMAINNAME> : range = 10000-4000000000 The following is a paraphrase of an explanation of how this works. Link below for source. All Domain users, groups and computers have a SID. The last part of the 'SID' is called the 'RID' and these are all unique and are set when the object is created and normal users etc usually start at 1000 (though this will be different depending on which DC they are created on). You cannot rely on the RID to identify what the object is, '1000' could be a user, '1001' could be a group, but, if that is the case, there will never be a user with the RID '1001'. To put it another way, RID's are issued consecutively to the next object, no matter what it is. Now you know how Windows issues ID's, how does Samba map them to Unix users and groups ? This can be done by winbind and the 'rid' idmap backend (there are other backends). If you do use the 'rid' idmap backend, it uses this formula: ID = RID + LOW_RANGE_ID 'ID' is the required Unix ID 'RID' is the Windows user or group ID 'LOW_RANGE_ID' is the number set in smb.conf (which is '10000' in the example I supplied). So, if the RID was '1000', the calculation would become: ID = 1000 + 10000 So the 'ID' is '11000' and always will be, even on other Samba fileservers, provided you use the same basic smb.conf Rowland - https://www.spinics.net/lists/samba/msg175409.html Thank you Rowland.

The Whole Picture: On Server ZFS Data set = pool/data Mount Point = /pool/data 1. Make sure sharenfs=off (zfs set sharenfs=off pool/data) 2. edit /etc/exports, add line "/pool/data" -async,no_subtree_check,fsid=111 *(sec=sys,rw,no_root_squash,no_all_squash)" Note: fsid has to be a unique number for each share. Unraid starts them at 100 3. restart nfsd (/etc/rc.d/rc.nfsd restart) Make a script that inserts the line in step 2 into the /etx/exports file on boot. On Client Use the Unraid GUI on the Main tab to mount and NFS share Yes it connects My Issue: Permissions of files and folders on Client (all files 777 nobody:users) do not reflect those on the Server (770 <user name>:domain users> Is this something NFSv4 can solve? Making it an SMB share has the same issue with permissions. Both Client and Server connected to the same domain.

I'll give this a try on Thrusday when I stay after work to do server updates. It may solve an issue with VM's in Unraid not responding to logitech wireless keyboard and mouse when the monitor goes to sleep. The current solution is to move the usb receiver to a different port on the usb hub and they system wakes up and responds. This also happens intermittantly so it's been hard to troubleshoot.

It a 5 desktop system for in a helicopter hangar. We needed a mobile, small foot printer with as few wires as possible. WiFi sucks around large metal objects. So I came up with this. It has 1 power cord and 1 ethernet cord. The Techs working on the helicopter can have their workstation with manuals, drawings, our managment software, email, etc. all right next to whichever aircraft they are working on. The UPS allows them to unplug and move without powering down, the printer is right there too. I've got a second one running with the USB Manager plugin and now the guys can plug in their camera's and phones to get pics off them as well. It's really working well.

It would definatly be used becuase I've got 5 VM's with a 4 Port USB 3.0 hub each, 2 mappings per port = 40 mapped ports. I also found that if you have more than say 8 ports mapped, the unRAID gui button for going to the top of the page interfears with the X to remove the mapping on the last mapping entry. It's still able to be selected, you just need very fine mouse control. See if you can replicate this. Thanks.

Wow, thanks. This wasn't a critizism BTW. Just how I got it to work.

I have the Hydra2 machine in my office and plugged a USB 3.0 card in the open PCIe slot. It came up on it's own IOMMU group. I can now confirm that all PCIe slots come up in their own IOMMU group. Testing the Video Card issue in this slot that I was having before. Trying to disable the auto SLI bridging in the BIOS. UPDATE: can not get passthrough to work with video cards in both PCIe x16 slots. Motherboard trys to run both cards in SLI mode. Solution: run anything but a video card in the second PCIe x16 slot.

The plugin USB Manager is AWESOME for this setup. I used orico MH4PU-P USB 3.0 hubs, mapped the USB 2.0 and 3.0 devices for each port on a hub to a VM and it's works amazing. You can't just map the hub, you have to map each port. Plug one hub in at a time and use the "Empty Ports" switch at the top of the USB page to make it easier.

The direct answer to your question is the range is SID range on the local unraid box is used by Samba to map domain users and groups to local file ownership. There is FAR more to this that I've been meaning to add. I have 2 test machines and 10+ production unraid boxes that I manage myself and third parties. There are different ways to map domain users to the local SID's on in Samba. By default Unraid uses idmap_hash and it specifically says DO NOT USE THIS BACKEND https://www.samba.org/samba/docs/current/man-html/ I don't know why Unraid did this is. Someone please post so we all can know. You end up with all those log entries, but things seem to work fine for the most part. Makes it hard to troubleshoot when you have something obvioulsy wrong in the log files. I learn by trial and error so I went though the man pages and tried each type of Backend listed here. One thing I did learn is you need to set the starting range above the highest SID of local users on the Unraid box. Look at the file /etc/passwd and look for the number after the second : eg. scans:x:1092:100:ftpuser 1092 is what you need to start above. If you don't, file ownership get screwed up. DomainUser1 gets assigned the SID 1092 and command line file level viewing is impossible to understand. A file for DomainUser1 is now shown as belonging to local user scans. The domain knows the SID on that file is for DomainUser1 and the ownership functions for that user as expected, but it is also assigned to the matching local user SID from the view of the Unraid box which could cause an issue. The fix for this was changing the starting range, reboot, reassign all permission. Not fun in some cases. I had one instance where switching to the tbd backend did mess up file ownership after a reboot but only for domain accounts. Any local accounts below the starting range were not affected and none of the ACL's were not affected. This *MAY* of been caused but the owner of this unraid box adding a user at the same time I was working on it. Generally this fix works as long as the range is set correctly OR you don't use any local accounts on your unraid box beyond the ones it comes with. If I'm wrong on any of this someone please correct me, but I'm speaking from results of things I've actually done. EDIT: setting the starting range to 1000000-2000000 did work for me in all instances.

Here is my output from the Tools > PCI Devices and IOMMU Groups I'm pretty sure each PCIe slot is in it's own IOMMU group and I'm NOT using the ACS patch. Note that due to something with the motherboard BIOS, I'm unable to pass through the video cards in the PCIe x16 slots to different VM's. Something to do with and auto SLI system in the BIOS. I have another unit with the same motherboard that I'm trying to repeat the process with. If I figure out how to disable the auto SLI feature I'll let you know. I was having success with having an AMD video card and nVidia card in these slots becuase they shouldn't be SLI compatible but it caused more errors than just having another nvidia card in the second PCIe x16 slot and not using it. My current setup has been so stable that I forget about it most of the time. IOMMU group 0: [1022:1482] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 1: [1022:1483] 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 2: [1022:1482] 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 3: [1022:1482] 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 4: [1022:1483] 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 5: [1022:1483] 00:03.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 6: [1022:1482] 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 7: [1022:1482] 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 8: [1022:1482] 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 9: [1022:1484] 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 10: [1022:1482] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 11: [1022:1484] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 12: [1022:790b] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61) [1022:790e] 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) IOMMU group 13: [1022:1440] 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 0 [1022:1441] 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 1 [1022:1442] 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 2 [1022:1443] 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 3 [1022:1444] 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 4 [1022:1445] 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 5 [1022:1446] 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 6 [1022:1447] 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 7 IOMMU group 14: [1022:57ad] 01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse Switch Upstream IOMMU group 15: [1022:57a3] 02:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge IOMMU group 16: [1022:57a3] 02:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge IOMMU group 17: [1022:57a3] 02:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge IOMMU group 18: [1022:57a3] 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge IOMMU group 19: [1022:57a3] 02:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge IOMMU group 20: [1022:57a3] 02:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge IOMMU group 21: [1022:57a4] 02:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:1485] 09:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:149c] 09:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] 09:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller IOMMU group 22: [1022:57a4] 02:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:7901] 0a:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) IOMMU group 23: [1022:57a4] 02:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:7901] 0b:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) IOMMU group 24: [144d:a808] 03:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 IOMMU group 25: [10de:128b] 04:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) [10de:0e0f] 04:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) IOMMU group 26: [10de:128b] 05:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) [10de:0e0f] 05:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) IOMMU group 27: [10de:128b] 06:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) [10de:0e0f] 06:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) IOMMU group 28: [8086:1539] 07:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) IOMMU group 29: [10de:128b] 08:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) [10de:0e0f] 08:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) IOMMU group 30: [10de:128b] 0c:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) [10de:0e0f] 0c:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) IOMMU group 31: [1002:6779] 0d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:aa98] 0d:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235X OEM] IOMMU group 32: [1022:148a] 0e:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 33: [1022:1485] 0f:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 34: [1022:1486] 0f:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP IOMMU group 35: [1022:149c] 0f:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller IOMMU group 36: [1022:1487] 0f:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller

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.

Changed Status to Solved

SOLUTION 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'

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.

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.

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 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.