I am having real problems with ACLs based on Active Directory domain.

[j.lanham]

I have a file share with a bunch of downloads in it that has an AD account as owner, an AD group as group owner. The owner has an ACL full access. The AD group has an ACL of Full Access. And an AD User group has read access. When I connect to it through a user in the primary group and try to delete anything, errors are generating in the log

chdir_current_service: vfs_ChDir(xxx) Permission denied. Current token: uid=23601, gid=20515, 5 groups: 23601 20515 90000005 90000012 90000017

and the display when I go to edit the permissions in the gui shows:

I know for a fact that both User and Group with the ! above exist in active directory, but it will not pick them up. Active Directory is showing as healthy.

It seems to gain then lose active directory groups. This was completely stable under Core. What could be going wrong?

Please, I really need some guidance.

 

[morganL]

I have a file share with a bunch of downloads in it that has an AD account as owner, an AD group as group owner. The owner has an ACL full access. The AD group has an ACL of Full Access. And an AD User group has read access. When I connect to it through a user in the primary group and try to delete anything, errors are generating in the log

chdir_current_service: vfs_ChDir(xxx) Permission denied. Current token: uid=23601, gid=20515, 5 groups: 23601 20515 90000005 90000012 90000017

and the display when I go to edit the permissions in the gui shows:

View attachment 62036

I know for a fact that both User and Group with the ! above exist in active directory, but it will not pick them up. Active Directory is showing as healthy.

It seems to gain then lose active directory groups. This was completely stable under Core. What could be going wrong?

Please, I really need some guidance.

Please document version of SCALE.... is both Angelfish and Bluefin causing the issue?

 

[j.lanham]

Core 13 to Angelfish 22.02.0 to Bluefin 22.12.02. Hints of problems with Angelfish, Bluefin initially appeared to fix it, then noticed errors as referenced in NAS-119390 and installed the version of Samba referenced in the note. I have one purely smb share that I've been testing with and no matter what I do it won't allow me to delete files (it shows they are deleted initially but the above error shows in the log) then if you back out of the directory, and go back in the files show as still being there. Then if you try to delete the directory, it doesn't get removed and the above errors are generated in log.smbd.

 

[morganL]

Core 13 to Angelfish 22.02.0 to Bluefin 22.12.02. Hints of problems with Angelfish, Bluefin initially appeared to fix it, then noticed errors as referenced in NAS-119390 and installed the version of Samba referenced in the note. I have one purely smb share that I've been testing with and no matter what I do it won't allow me to delete files (it shows they are deleted initially but the above error shows in the log) then if you back out of the directory, and go back in the files show as still being there. Then if you try to delete the directory, it doesn't get removed and the above errors are generated in log.smbd.

The initial fixes seem to be in 22.12.1 - due in Feb. If you had a test system, a nightly could be used to confirm, but we don't recommend using a production system.

 

[j.lanham]

The initial fixes seem to be in 22.12.1 - due in Feb. If you had a test system, a nightly could be used to confirm, but we don't recommend using a production system.

I'm still having problems with basic authorities. I have reset up the Downloads file share multiple times resetting acls multiple times. My domain controller says my user profile has all of the authority it needs, but whenever I try to delete a file, it disappears as if deleted and upon refresh comes back. The log every time I try to delete a file shows:

vfs_ChDir(/mnt/NASVOL1/Downloads) failed: Permission denied. Current token: uid=23601, gid=20515, 5 groups: 23601 20515 90000005 90000012 90000017

When I try to delete a directory, it doesn't disappear but similar logs are generated in the smbd.log. No error message on the client side. Just doesn't go away.

I know the numbers won't mean anything, but rest assured one of the groups has been given full access. This occurs consistently, every time. Does anyone have any idea what's happening?

 

[j.lanham]

The initial fixes seem to be in 22.12.1 - due in Feb. If you had a test system, a nightly could be used to confirm, but we don't recommend using a production system.

BTW, I did say that I updated Samba to the referenced version in the replacement_samba_packages.zip file referenced in the issues report. So the referenced error in the issue is no longer occurring in my logs. So, even upgrading to a daily wouldn't make a difference in the error I'm trying to solve.

 

[anodos]

Code:

chdir_current_service: vfs_ChDir(xxx) Permission denied. Current token: uid=23601, gid=20515, 5 groups: 23601 20515 90000005 90000012 90000017

This means that user associated with uid 23601 does not have permissions to chdir into the path you are trying to share. The most common reason for this is that the user in question lacks execute permissions on some intermediate path to that location.

You can figure out precisely which user that is by typing the command id 23601.

 

[j.lanham]

Code:

chdir_current_service: vfs_ChDir(xxx) Permission denied. Current token: uid=23601, gid=20515, 5 groups: 23601 20515 90000005 90000012 90000017

This means that user associated with uid 23601 does not have permissions to chdir into the path you are trying to share. The most common reason for this is that the user in question lacks execute permissions on some intermediate path to that location.

You can figure out precisely which user that is by typing the command id 23601.

That's my computer account. Why would it be trying to use my computer account for authentication?

 

[anodos]

That's my computer account. Why would it be trying to use my computer account for authentication?

Can't really tell from our logs, because that's something happening client-side. Best guess is that it's a system process (like Windows Defender) trying to do things over SMB. The local SYSTEM account gets mapped to the computer account once it hits the network.

 

[j.lanham]

Can't really tell from our logs, because that's something happening client-side. Best guess is that it's a system process (like Windows Defender) trying to do things over SMB. The local SYSTEM account gets mapped to the computer account once it hits the network.

That would mean any domain connected computer running a virus scanner or anything similar would be using the System authority when trying to change the file system? Wouldn't that affect windows servers as running file sharing as well?

 

[anodos]

That would mean any domain connected computer running a virus scanner or anything similar would be using the System authority when trying to change the file system? Wouldn't that affect windows servers as running file sharing as well?

Well, you can run a PCAP of your traffic to another windows server and see. This is client-specific behavior (outside of scope of SMB server). I'm just explaining the line you highlighted from your logs.

 

[anodos]

If endpoint security on your client is trying to use the local system account to perform operations on a remote SMB share, that is most likely a bug on their end (the security application developer) since there's no strong guarantee that the account will have read or write access to a share.

 

[j.lanham]

Well, you can run a PCAP of your traffic to another windows server and see. This is client-specific behavior (outside of scope of SMB server). I'm just explaining the line you highlighted from your logs.

And I appreciate that. Thinking aloud via keyboard.

Well a thought a minute and I realized there's a default everyone that built by windows server and I think that's the reason, so I added @Everyone traverse. That fixed the security problem, but now I have another error popping up.

ixnas_get_native_dosmode: Realtek/Install_Win7_7065_11232012.zip: open() failed: Permission denied

Do you know what that could be referring to in terms of authentication?

 

[anodos]

You can try granting the "domain computers" group READ access and see if that clears it up.

Hmm.... I think unprivileged user should be able to get DOS attributes so I'll wrap this in a become_root() directive in failure path on EPERM, but generally speaking you're eventually going to hit access issues if application on client is trying to do ops as the wrong account.

 

[j.lanham]

I don't understand why this exact same setup worked under core but doesn't under scale. I didn't have to do this under core. Why all of a sudden do computer account authorities become and issue. I did give domain computers authority, I didn't get the error but it still didn't delete the file or the directory. This is driving me batty.

 

[j.lanham]

You can try granting the "domain computers" group READ access and see if that clears it up.

Hmm.... I think unprivileged user should be able to get DOS attributes so I'll wrap this in a become_root() directive in failure path on EPERM, but generally speaking you're eventually going to hit access issues if application on client is trying to do ops as the wrong account.

I don't understand why this exact same setup worked under core but doesn't under scale. I didn't have to do this under core. Why all of a sudden do computer account authorities become and issue. I did give domain computers authority, I didn't get the error but it still didn't delete the file or the directory. This is driving me batty.

 

[morganL]

I don't understand why this exact same setup worked under core but doesn't under scale. I didn't have to do this under core. Why all of a sudden do computer account authorities become and issue. I did give domain computers authority, I didn't get the error but it still didn't delete the file or the directory. This is driving me batty.

There are two major differences between CORE and SCALE:

1) FreeBSD and linux are very different. The way they handle file systems permissions are different. TrueNAS tries to mitigate those differences, but there are no guarantees. Millions of lines of code are different.

2) SCALE Bluefin is a .0 release with much less deployment time than 13.0. There may be bugs yet to be found. Complex use cases, such as this one are more likely to find untested pieces of code. There are billions of potential configurations.

If the use case doesn't allow time to troubleshoot and fix, we recommend CORE to users.

 

[anodos]

I don't understand why this exact same setup worked under core but doesn't under scale. I didn't have to do this under core. Why all of a sudden do computer account authorities become and issue. I did give domain computers authority, I didn't get the error but it still didn't delete the file or the directory. This is driving me batty.

I didn't really say that this is what is causing the issue that you were seeing. I have just been speculating based on a blurred-out screenshot and a single line of a logfile. I explained what the logfile line means in the context of an SMB server and AD in general, but have not established that this is the root cause of the behavior difference you're seeing. There is a plausible scenario where it could be the root cause, but as I mentioned it's just speculation based on what I have seen so far. SCALE and CORE are different operating systems (Linux vs FreeBSD) and different Samba versions (4.15 vs 4.17) with a whole host of other differences between them as well. For the most part configuration should transfer directly between the two.

Most migration issues I have seen are related to custom auxiliary parameters people put in their SMB servers or changes they made post-migration (but didn't at first report that they made them). If you post the output of testparm -s then maybe I will see something that can help further.

 

[j.lanham]

I didn't really say that this is what is causing the issue that you were seeing. I have just been speculating based on a blurred-out screenshot and a single line of a logfile. I explained what the logfile line means in the context of an SMB server and AD in general, but have not established that this is the root cause of the behavior difference you're seeing. There is a plausible scenario where it could be the root cause, but as I mentioned it's just speculation based on what I have seen so far. SCALE and CORE are different operating systems (Linux vs FreeBSD) and different Samba versions (4.15 vs 4.17) with a whole host of other differences between them as well. For the most part configuration should transfer directly between the two.

Most migration issues I have seen are related to custom auxiliary parameters people put in their SMB servers or changes they made post-migration (but didn't at first report that they made them). If you post the output of testparm -s then maybe I will see something that can help further.

I would like to apologize for prior tone. It's just that it seemed to work for a day after migration, then things just kind of got worse. Thank you as always for your help.

Load smb config files from /etc/smb4.conf
lpcfg_do_global_parameter: WARNING: The "syslog only" option is deprecated
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_DOMAIN_MEMBER

** The rest is in the file **

 

[j.lanham]

@anodos I just noticed when looking at the share parameters page that all of the advanced options are greyed out except "allow guest access" and "legacy AFP Compatibility". I seem to remember that being the case when I deleted and readded the share while troubleshooting the ACL problems I'm having. Is that normal for Scale?