Univention Bugzilla – Bug 49747
The windows explorer crashes, if the share security section will be accessed
Last modified: 2021-08-04 18:18:59 CEST
Created attachment 10095 [details] shows the crash A customer reported, that his windows explorer crashes, if he tries to adjust the share settings in the security section. He also mentioned, that this only occurs at the main level of the shares. He found the cause of the explorer reaction. If the directory owner is set to root, this our default when you create a share, the explorer crashes. If you set the owner to administrator you can access the security section. Please see attached git
Addtional information, the explorer also crashes, if the directory owner group is set to root. This is also an issue for win7 clients I will increase the pain level, too, because this is urgend and important for at least for two our school customers.
Two more UCS@school customers reporting the exact same issue. They also mentioned this is quite urgent to them.
Also non-@school customers are effected
The acls additionally set on the filesystem influence the behaviour too E.g. getfacl: Entferne führende '/' von absoluten Pfadnamen # file: shares/explorer # owner: Administrator # group: Domain\040Admins user::rwx user:root:rwx user:Administrator:rwx group::rwx group:root:r-x group:Domain\040Admins:rwx group:Domain\040Users:r-x group:Administrators:r-x mask::rwx other::--- default:user::rwx default:user:Administrator:rwx default:group::--- default:group:root:r-x default:group:Domain\040Admins:rwx default:group:Administrators:rwx default:mask::rwx default:other::--- These permissions for user 'root' and group 'root' also causes the explorer to crash. BUT removing them with setfacl -x u:root,g:root,d:u:root,d:g:root /shares/explorer/ the windows explorer is happy. root@master:~# getfacl /shares/explorer getfacl: Entferne führende '/' von absoluten Pfadnamen # file: shares/explorer # owner: Administrator # group: Domain\040Admins user::rwx user:Administrator:rwx group::rwx group:Domain\040Admins:rwx group:Domain\040Users:r-x group:Administrators:r-x mask::rwx other::--- default:user::rwx default:user:Administrator:rwx default:group::--- default:group:Domain\040Admins:rwx default:group:Administrators:rwx default:mask::rwx default:other::---
In Ticket#2019072621000454 are EVTX logs from the Win10-Client, probably there are hints towards the problem.
Now we have two customers, the workaround setting an other owner then root to the main level of the shares does not work. In Ticket#2019072621000454 where Nico attached the logfiles in comment 6 we have this "new" case.
happend again in a ucsschool environment → Ticket#2019090921000947
I'm unable to reproduce this: * standard UCS 4.4-2 (no @school) * share on a memberserver * I added a group to the share permissions using a Windows2016 Terminalserver
Hi this is my experience with this problem.Hope this helps with solving this issue. I had/have this problem .It appeared after a univention upgrade .I don’t know which one as I don’t change rights very often. I had a lot of sid,rid that did not exist in the active directory as my active directory was for an older setup ant there was a lot of unneeded rights setup on shares.this seems to trigger the problem. Root being one of them but any will do. My setup univention is setup as a kvm guest on a linux ubuntu 18.04 kvm server. I have duel Gb nics on the server bonded and bridged. The univention root is setup as a qcow2 on raided ssd on the kvm server so is very fast.the data is setup as qcow2 disk spinning rust drives raided mdadm on host ubuntu kvm server . The data drives are luks crypt in univention guest. I am using virtio drivers for nics and disks .the disks are setup in guest as qcow2 After I used workaround see below the shares rights work fine but it does not fix the actual issue. When I tried to set security rights up in printer shares on pc around the network the same issue happened where explorer crashes .if I disconnect pc from active directory I can again edit security setting in printer.Then if I reattach it crashes .There is a timing issue here as very rarely I can get in to printer security and it does not crash. Hope this helps +++++++++++++++ Work around for me that worked.But it does mean you have to delete all rights on all files/directories in that share you want to fix.So it is clean. wipe all rights from whole directory tree share. Be aware this will delete all rights on all files and directories of that share BE CAREFULL login to server as root in console run setfacl -b -R ./sharedirectoryroot/ in directory where share is . Login univention web interface go to share Then in univention in shares in General directory share settings directory owner from root to administrator or one that exists in active directory and directory owner group to domain admins or a group that exists in active directory I set ticks in owner read ,write ,access Then login to windows computer with rsat setup .login as administrator start computer management right click connect to another computer and select ip of ucs server then open tree .I get an error here but I ignore. Go to shared folders , shares right click properties of share .go to security tab and advanced and set permissions for all directories and files in shares you have to tick box at bottom to replace all child object permission entries with inherited permission entries from this object. it will reset permissions at you need.
Happened again in a school environment. 4.4-2
Happened again in customer environment. He transferred from SBS2011 shares by robocopy. When transferring the files without permissions no issue on the UCS shares. As soon as some Windows permissions have been copied the explorer crashes on this share. Tried to remove the ACLs through tar but running Samba seems to re-set them (could not stop Samba due to production environment). It seems not to be relevant which owner the share is (root vs. Administrator).
Antoher customer affected. No workaround seems possible as the share is on a joined Windows-Member server. Trying to access the security information from a folder within the share the Windows 7 (!) Explorer crashes.
(In reply to Christian Völker from comment #13) > Antoher customer affected. > > No workaround seems possible as the share is on a joined Windows-Member > server. > > Trying to access the security information from a folder within the share the > Windows 7 (!) Explorer crashes. To be sure: this happened with a fileserver based on Microsoft Windows? If yes I'd like to know whether this is reproducable with Microsoft Active Directory, for example if the user/group assigned to a share ACL is deleted from AD...
Created attachment 10225 [details] add unix to predefined domains
The problem is, that samba doesn't recognize unix Sids as valid and returns "INVALID_SID", which is a status not known to windows. Before ~samba4.9 "SOME_NOT_MAPPED" was returned. In my patch, I added the Unix-Sids to the predefined_domains, so that samba recognizes the Sids S-1-22* as valid.
Package: samba Version: 2:4.10.1-1A~4.4.0.201911141358 Branch: ucs_4.4-0 Scope: errata4.4-2 I built samba with the attached patch. a0f0c1430e Bug #49747: Yaml
OK - windows explorer sec tab for "root share" (win7, win10) OK - yaml
<http://errata.software-univention.de/ucs/4.4/353.html>
I have cleared up all my shares but still have problems with security setting in printers under control panel. I updates to patch level 384 the patch for this is 353 . After update and reboot it still crashes. the sid starts with s-1-15-3-1024 so i dont think it is a unix sid from what you have said I don't know where this comes from but if i delete all unknown sids by disconnecting from server deleting sids it fixes this question do you think samba themselves will fix this upstream .
(In reply to Philip Hill from comment #20) > I have cleared up all my shares but still have problems with security > setting in printers under control panel. > I updates to patch level 384 > the patch for this is 353 . > After update and reboot it still crashes. > the sid starts with > s-1-15-3-1024 so i dont think it is a unix sid from what you have said > I don't know where this comes from but if i delete all unknown sids by > disconnecting from server deleting sids it fixes this > > question > do you think samba themselves will fix this upstream . You are correct, we found several SIDs which can still cause these crashes, as they are not recognized as valid by samba. The new Bug for this problem is Bug #50601. Please do not delete SIDs of the form S-1-15*, this might cause crashes as well, since these are so-called capability SIDs. We will open a bug-report with our patch at samba, so these changes may be fixed upstream.
Patch sent upstream: https://bugzilla.samba.org/show_bug.cgi?id=14213