psychofaktory
-
Posts
90 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by psychofaktory
-
-
10 hours ago, Holmesware said:
I'd just like to point out that the posted fix in the dedicated channel for this issue does work.
That's not right!
I applied the mentioned fix and the problems are still there, as I already wrote.
17 hours ago, dlandon said:AD is not a main stream Unraid feature and unfortunately, doesn't get the attention that users expect. It is noted in our system as an issue, but is not a high priority at this point because it doesn't affect as many users as other issues.
What kind of reasoning is that, please???
When we chose Unraid, one of the most important criteria was support for AD connectivity.
As far as I can tell from the documentation, there is no mention anywhere that this is a feature that is being neglected and may not work.
If a feature is offered, then a developer should also make sure that it works. Otherwise at least a clear marking would be appropriate that it is an experimental feature or something similar.
To distance oneself from it afterwards is a slap in the face for all those who - like us - relied on this feature.17 hours ago, dlandon said:Changing the backend is not as simple as just changing one setting. Our research has shown there is more to it than that. We don't want to create more problems than we fix.
I can't understand the logic behind this statement.
Are you telling us that the problem will not be fixed for the time being because it will be very difficult to fix, even though you know that it is a serious problem that affects enterprise customers in particular?
Seriously?Shouldn't bugs be fixed primarily based on their severity?
It may be that the AD feature is only used by a minority compared to the other features. But this minority are usually customers from the enterprise segment for whom a bug in this area is particularly critical.
And even though it may be a minority compared to the other features, the absolute number of people affected is probably still quite high. The feedback here in the forum alone shows that. -
The error still occurs with the current version 6.11.5.
also extremely annoying:
After every Unraid System Update the permissions on all share folders under /mnt/user/ are reset to 0777 (owner "administrator", group "domain-admins"). This causes problems especially with Nextcloud Docker every time!On 11/13/2022 at 11:07 AM, JorgeB said:Not sure what you mean, latest Unraid release uses Samba 4.17.2 which is the latest Samba release currently available.
I guess @Luke_Starkiller doesn't mean that an EOS version of samba was used, but if the developers have already commented on why Unraid uses an outdated way of SMB configuration to map AD users, even though it has been explicitly unsupported by samba for more than 5 years.
-
1
-
-
Even with the new version 6.11.2 the problems persist 😒
-
11 minutes ago, Frank1940 said:
Remember that MS is still updating SMB and often Samba will require an update to keep current with those changes...
As far as I can tell, this problem was not caused by a Microsoft update, but by the upgrade to Unraid 6.10.2, which led to the discovery of some Samba configuration problems in Unraid.
Furthermore, there are other projects that currently use Samba in a domain environment and do not have such problems.
I therefore see the ball not in Microsoft's or the Samba developers' court, but rather in the court of the Unraid devs.
-
1
-
-
10 hours ago, CallOneTech said:
a workaround/semi-fix like we have now
There is a workaround, but it did not solve the problem in all cases.
In my case, the problem still exists. It has been going on for over 2 months now. For the business sector (where I would place Active Directory), this is an unacceptably long period of time.I very much welcome the fact that the topic of Active Directory now seems to be receiving more attention with the new forum area.
However, I think it is more important to fix the urgent, still open problems instead of putting energy into new topics. -
Multichannel is turned off here and was turned off all the time.
-
Unraid OS v6.11.1 -> still the same behaviour.
-
So there seems to be no difference to my configuration here.
But why it isn't working as expected here?By the way, the problem still exists with the new Unraid 6.11 and Samba 4.17.0.
-
1
-
-
I still don't know what relevance it has that "getent group" only shows local Unraid groups, but because of this I have investigated further.
I went through the tests as described in this article and found out that the Kerberos authentication does not seem to work:
kinit Scan kinit: Configuration file does not specify default realm when parsing name ScanBased on this error message, I searched further and found that the default realm should be entered in the Kerberos configuration file under /etc/krb5.conf as described here.
Could this be a potential solution?
-
On 9/19/2022 at 9:15 PM, Holmesware said:
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-4000000000So basically this is the same solution approach as presented here in the thread.
I applied it like this. But that didn't solve my problem.
On 9/19/2022 at 9:15 PM, Holmesware said:* CAUTION * Making these changes you will have to re-apply all permissions on files/folder that are Domain related
The adjustments had even affected all share folders.
How does Unraid differentiate between domain-related and non-domain-related? -
I don't know if it helps, since I don't know how this in Unraid behind the scenes works....
But I have noticed that
getent groupdisplays only local Unraid groups.
However, if the group is specifically requested, it is found and the ID is also displayed correctly:
getent group lehrer lehrer:x:11132:Conversely, the group membership can be displayed for a user with the id command:
id Scan uid=11325(scan) gid=10513(domänen-benutzer) groups=10513(domänen-benutzer),11325(scan),1001(BUILTIN\users) -
1 hour ago, Geoff Bland said:
It's a long shot but does "smbstatus -S" show anything unexpected?
No, theres nothing unexpected.
1 hour ago, Geoff Bland said:I can't see an error in your set-up. All looks correct.
Thanks, that at least confirms that the error is not on my side.
1 hour ago, Geoff Bland said:I should also mention the Samba mailing list https://lists.samba.org/mailman/listinfo/samba
It was the guys on this mailing list that helped me work out what was going on and gave some great advice - all I learnt and posted above was based on responses I got from this mailing list - I got fairly quick responses from the list and the guys on this list know far more than I about Samba.
I agree with @R.M.H here.
This is a feature that by its nature is aimed at business customers and is actually part of the standard functionality of the software for which we have paid a licence fee.The experiences described here show that this is not an isolated case, but rather a general software problem on the part of Unraid.
Accordingly, it should be the task of the developers to search for errors and, if necessary, make use of the Samba mailing list.
-
2 minutes ago, dlandon said:
Has anyone tried 6.11-rc5? Samba is updated to 4.16.5.
I don't want to test this since I have to work with my Unraid server in a productive environment.
-
When trying to access a share with an (actually) authorised user, the following appears in the log:
smbd[7353]: chdir_current_service: vfs_ChDir(/mnt/user/Lehrer) failed: Permission denied. Current token: uid=11284, gid=10513, 10 groups: 11284 10513 11317 11132 11131 11324 1003 1004 1005 1001With "wbinfo -n", "wbinfo -s" and "id -u" I checked the IDs for the user in question and the group that should have full access according to Windows.
The user in question has the ID 11284.
He is a member of the group with the ID 11132 ("Lehrer"), which should have full access.getfacl /mnt/user/Lehrer/ getfacl: Removing leading '/' from absolute path names # file: mnt/user/Lehrer/ # owner: administrator # group: users user::rwx user:domänen-admins:rwx user:lehrer:rwx user:scan:r-x group::rwx group:users:rwx group:administrator:rwx group:domänen-admins:rwx group:lehrer:rwx group:scan:r-x mask::rwx other::rwx default:user::rwx default:user:administrator:rwx default:user:domänen-admins:rwx default:user:lehrer:rwx default:group::--- default:group:users:--- default:group:administrator:rwx default:group:domänen-admins:rwx default:group:lehrer:rwx default:mask::rwx default:other::---According to
wbinfo --gid-info 10513the group with ID 10513 is "domain-user".
The test user is also in this group, but it does not have access to the share in question.
Where is the error here and what would a permitted access attempt look like?
-
7 hours ago, Geoff Bland said:
This should be your fully qualified domain name - unless LOCAL is your top level domain as set on your domain server & DNS?
Yes, the domain suffix is indeed .local.
7 hours ago, Geoff Bland said:The range here should be as you set it in the SMB config smb-extra.conf file. The range should be 10000-4000000000 and not 1938817024 - 4000000000. From the wbinfo you can see that the range applied is adding 10000 so it doesn't match up with the testparm reported SMB settings. I am not sure why this would be so if the settings are there in the smb-extra.conf file.
You are right.
I had accidentally posted the old configuration with @GrantEs adjustments.
In fact, the smb-extra.conf already looked like this yesterday:#unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end hide unreadable = yes access based share enum = yes [global] # Override unraid's use of the broken idmap_hash plugin for mapping AD SID -> uid. idmap config * : backend = tdb idmap config * : range = 1000-7999 idmap config GSR-L : backend = rid idmap config GSR-L : range = 10000-40000000007 hours ago, Geoff Bland said:One other thing I have is
server min protocol = SMB2This is not a setting I have set anywhere on UNRAID, I see you have this set to NT1 - I am not sure what effect this would have.
After my post yesterday ist set netbios to off to do some further testing.
Now testparm looks like this:
testparm Load smb config files from /etc/samba/smb.conf lpcfg_do_global_parameter: WARNING: The "null passwords" option is deprecated Loaded services file OK. Weak crypto is allowed Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions # Global parameters [global] disable netbios = Yes disable spoolss = Yes ldap ssl = no load printers = No logging = syslog@0 multicast dns register = No ntlm auth = ntlmv1-permitted null passwords = Yes printcap name = /dev/null realm = <domain>.LOCAL security = ADS server min protocol = SMB2 server multi channel support = No server string = xxxxxxxxxx show add printer wizard = No unix extensions = No winbind use default domain = Yes workgroup = <domain> idmap config <domain> : range = 10000-4000000000 idmap config <domain> : backend = rid idmap config * : range = 1000-7999 idmap config * : backend = tdb access based share enum = Yes acl allow execute always = Yes acl group control = Yes aio read size = 0 aio write size = 0 dos filemode = Yes hide unreadable = Yes include = /etc/samba/smb-shares.conf inherit acls = Yes inherit permissions = Yes invalid users = root map acl inherit = Yes map archive = No use sendfile = Yes wide links = Yes
But practicaly that didn't made a difference.
-
Thank you for the new input.
I have carried out new tests based on this.
First I restarted Unraid, and immediately afterwards I left the domain, which also worked.
Apparently the domain join function is related to the start of the array. At that point, it had not yet been started.Then I removed the created entries from smb-extras.conf and restarted Unraid again.
I then added the entries again. This time, however, I used your example @Geoff Bland instead of the adjustments described by @GrantE.
Then I rejoined the domain and restarted Unraid again.For the domain join, I did not use the administrator this time, but a Unraid user without special rights that I had created especially for this purpose.
After the domain join, the UNIX permissions for all share folders were again user:administrator; group:domain-admins; 0777.
I adjusted this to user:administrator; group:users; 0777.
getfacl /mnt/user/Lehrer getfacl: Removing leading '/' from absolute path names # file: mnt/user/Lehrer # owner: administrator # group: users user::rwx group::rwx other::rwxHere is the configuration of my smb-extra.conf:
#unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end hide unreadable = yes access based share enum = yes [global] # Override unraid's use of the broken idmap_hash plugin for mapping AD SID -> uid. idmap config * : backend = tdb idmap config * : range = 1000-7999 idmap config <DOMAIN> : backend = rid idmap config <DOMAIN> : range = 10000-4000000000
That was the output of testparm:
testparm Load smb config files from /etc/samba/smb.conf lpcfg_do_global_parameter: WARNING: The "null passwords" option is deprecated Loaded services file OK. Weak crypto is allowed Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions # Global parameters [global] disable spoolss = Yes ldap ssl = no load printers = No logging = syslog@0 multicast dns register = No ntlm auth = ntlmv1-permitted null passwords = Yes os level = 100 printcap name = /dev/null realm = <DOMAIN>.LOCAL security = ADS server min protocol = NT1 server multi channel support = No server string = xxxxxxxxxxxxxxx show add printer wizard = No unix extensions = No winbind use default domain = Yes workgroup = <DOMAIN> idmap config <domain> : range = 1938817024 - 4000000000 idmap config <domain> : backend = rid idmap config * : range = 1000-7999 idmap config * : backend = tdb access based share enum = Yes acl allow execute always = Yes acl group control = Yes aio read size = 0 aio write size = 0 dos filemode = Yes hide dot files = No hide unreadable = Yes include = /etc/samba/smb-shares.conf inherit acls = Yes inherit permissions = Yes invalid users = root map acl inherit = Yes map archive = No use sendfile = Yes wide links =
Then, from Windows, I set the permissions again as desired.
Once again, Windows confirmed access in the effective permissions.Under getfacl it now looked like this:
getfacl /mnt/user/Lehrer getfacl: Removing leading '/' from absolute path names # file: mnt/user/Lehrer # owner: administrator # group: users user::rwx user:lehrer:rwx user:scan:r-x group::rwx group:users:rwx group:administrator:rwx group:lehrer:rwx group:scan:r-x mask::rwx other::--- default:user::rwx default:user:administrator:rwx default:user:lehrer:rwx default:group::--- default:group:users:--- default:group:lehrer:rwx default:mask::rwx default:other::---I have also checked the user assignment in Unraid:
wbinfo -n Scan S-1-5-21-19xxxxxxxx-29xxxxxxxx-31xxxxxxxx-1325 SID_USER (1) wbinfo -s S-1-5-21-19xxxxxxxx-29xxxxxxxx-31xxxxxxxx-1325 <DOMAIN>\scan 1 id -u Scan 11325
But when it came to the practical test, there was disappointment again:
The users who should have access according to the permissions only see the error message from the screenshot in the opening post.Only when I set the UNIX permissions back to 0777, and thus release access for "everyone", is access possible again.
-
12 hours ago, Geoff Bland said:
You may be able to get to the bottom of it using the wbinfo and getfacl commands to see what is going on.
In my previous tests, I had already read out this information and everything looked good so far.
Originally I simply followed these instructions and the experiences from this post.
I had already noticed that something must have changed, as the instructions could no longer be used in this way.
In contrast to the instructions, I first had to manually change the owner to the Windows user with which I manage the permissions.After I had set the authorisation via Windows as desired, I checked the "effective authorisations" via Windows and tested whether the authorisations were effective.
There I was shown that the access exists.I used getfacl to cross-check the permissions from Unraid. Everything looked good there too.
In the practical test, however, I could not access the share with the user for whom the effective permissions were displayed as "full access".
The same error message was displayed as in your initial post.During further tests, I then found that access from Windows is only possible for users if either "everyone" has access rights or the Windows user is a member of the UNIX group of the share.
The problem is, however, that I can only store one UNIX group.
However, I have different groups that should have different access rights.
I also have a Nextcloud docker that also uses the share via the "External Storage" plugin. And for this, the UNIX group must be set to "users".In itself, this should work. Unfortunately, it does not work at all.
What can I do to find the cause of the fault and be able to rectify it?
To be honest, I'm a bit helpless here. -
20 minutes ago, Geoff Bland said:
This is probably as expected. As mentioned after the fix I posted above all permissions need to be reset.
For a brand new share the owner would be set as the SMB settings Initial Owner and group set as the SMB settings Initial Group (this defaults to the account used for SMB settings and the user group set to Domain Users I think).This surprises me, as I had made the adjustments to the range mentioned by @GrantE.
There it said that there was no need to reset the file permissions.21 minutes ago, Geoff Bland said:Did you try to use UNRAID created users to set the permissions on the share?
No, I had reset the permissions as you described in your post after I noticed that something had changed here.
I then adjusted the security permissions for the shares from Windows.
However, although the share permissions were adjusted, I could not access the share with the users who were now authorised to do so according to Windows.
Unfortunately, this is still exactly the same error as before.I only created the local Unraid user for testing purposes.
In the process, I noticed that after the adjustment of the smb-extra.conf described here, I can no longer access shares with a previously created Unraid user, and I can no longer create new Unraid users.28 minutes ago, Geoff Bland said:The only way I found to leave and rejoin the domain was to reboot UNRAID, obviously not great.
I had read about the workaround.
However, the Unraid server was restarted directly before...-
1
-
-
Hello,
unfortunately I also had massive problems with the SMB shares after joining the domain.
I have already posted files about this here and here.
The fix mentioned by @Geoff Bland with the additions by @GrantE unfortunately did not solve the access problems, but made them even worse:
-
the UNIX share permissions of all directories were changed to owner:administrator and group:domain-admins.
Also those of the appdata directory. - before, despite the domain connection, I could create local Unraid users and give them permissions on the share. However, after the adjustment, the locally created users no longer had access to the shares.
- when I then wanted to remove a locally created user and add it again, I unfortunately found that the user could no longer be added.
- I then wanted to leave the domain again in order to be able to rejoin it. However, I discovered that I could no longer leave the domain because the "Leave" button had no function.
- after resetting the permissions as recommended by @mgutt I discovered that the permissions of the share folders under /mnt/user (without inheritance to the subfolders) were reset to owner:administrator and group:domain admins without my intervention.
The server was set up with Unraid 6.10.3, so unfortunately I have no experience with earlier Unraid versions.
I really hope that the Unraid developers take care of this in a timely manner.
Share permissions are one of the essential components of a file server, and it is precisely because of the AD connection that mainly companies are affected by the error.
In my case, a small school, which leads to considerable problems in the process there.-
1
-
the UNIX share permissions of all directories were changed to owner:administrator and group:domain-admins.
[6.10.3] Intermittent SMB Issues After 6.10.2 Upgrade
in Stable Releases
Posted
Yes, unfortunately, absolutely nothing has changed in the matter.
@unraidster has worked out that there is a second error pattern, which I had already described here in the thread, that seems to overlap with the error pattern from the initial post here.
I really hope that the Unraid team finally takes care of the matter!