Hello - I have a private share setup and a user account with RW access to it. I am connecting to the share via SMB on a windows 10 client. The account name is NOT the same as my windows username. 

 

When I attempt to delete files, I get the common "You require permission from tower\NOBODY to make changes to this file.". I have tried:

 

1. Ran docker safe new perms (via Fix Common problems plugin)
2. Ran the regular new perms utility (excluded appdata)
3. deleted anything for the unraid server in Credential manager on the windows client and restarted. Also ran

   net use * /delete

If someone would be able to assist I would greatly appreciate it. Diagnostics are attached

watchtower-diagnostics-20211108-1130.zip

OK, let's start to have a look at your problem.  I set up a share on my Test Bed server as follows:

The share was setup so as no use the cache drive, so the files were written directly to the array.  My login to this server is as smbuser. 

 

The following is a copy from the terminal session showing the    permissions,  owner and    group    for the files that I copied over  to play around with:

root@Rose:~# ls -al /mnt/user0/Test
total 9672
drwxrwxrwx 1 nobody  users     263 Nov  8 13:29 ./
drwxrwxrwx 1 nobody  users      75 Nov  8 13:26 ../
-rw-rw-rw- 1 smbuser users  617414 Nov  4 08:49 2021\ 11\ News\ RM.pdf
-rw-rw-rw- 1 smbuser users  155592 Oct 21 19:07 315911750.pdf
-rw-rw-rw- 1 smbuser users  627065 Nov  1 10:30 November\ 2021\ newsletter\ draft.pdf
-rw-rw-rw- 1 smbuser users  403972 Oct  1 12:00 October\ 2021\ NEWSLETTER.pdf
-rw-rw-rw- 1 smbuser users   33072 Sep 11 11:07 Upgrading_from_Version_5_to_Version_6_of_unRAID-rev2.pdf
-rw-rw-rw- 1 smbuser users  641515 Aug 30 10:12 cmoc\ news\ letter.pdf
-rw-rw-rw- 1 smbuser users  105445 Nov  3 18:49 cpd56384.pdf
-rw-rw-rw- 1 smbuser users 7303393 Sep 30 17:27 cpd56386.pdf
root@Rose:~#

 I had no problems deleting a file in this share.

 

I now went looking for the case which you described:  Look at this capture:

root@Rose:~# ls -al /mnt/user0/Backup/Frank_Backups
total 320
drwxrwxrwx 1 nobody  users  281 Nov  1 08:00 ./
drwxrwxrwx 1 nobody  users  331 Nov  1 07:57 ../
drwxrwxrwx 1 nobody  users 4096 Dec  7  2013 Backup-2013-12-07/
drwxrwxrwx 1 nobody  users 4096 Dec  3  2014 Backup-2014-12-03/
drwxrwxrwx 1 nobody  users 4096 Dec  1  2015 Backup-2015-12-01/
drwxrwxrwx 1 nobody  users 4096 Apr  1  2016 Backup-2016-04-01/
drwxrwxrwx 1 nobody  users 4096 Aug  2  2016 Backup-2016-08-02/
drwxrwxrwx 1 nobody  users 4096 Oct 19  2016 Backup-2016-10-18/
drwxrwxrwx 1 nobody  users 4096 Dec  1  2016 Backup-2016-12-01/
drwxrwxrwx 1 nobody  users 4096 Jan  2  2017 Backup-2017-01-02/
drwxrwxrwx 1 nobody  users 4096 Feb  1  2017 Backup-2017-02-01/
d

 

Here are the settings on this Share:

 I had no problem deleting an entire directory/folder using Windows Explorer that was owned by 'nobody'.  (By the way, initially, I had the permission for 'smbuser' set to "read-only" and I got a very similar error massage that I needed permission from 'nobody' to perform the delete operation!) 

 

Double check that you have all of the Share permissions set up correctly and the SMB Users have the right permissions. 

 

There is always confusion about what user ends up logged onto an SMB server.   This may be your problem.  It is my understanding that the Windows Credential Manager entry takes precedence followed by the Windows user login.  And both of these can happen in the background depending on the Security level of the share first being accessed.  (If it has any public access, any login credential is accepted.  Once a user is logged in, the 'net use' command is the only way out.  And you are only basically allowed one login from each client computer to each server.  Furthermore, the Windows error messages are usually useless in figuring out what is really going on. 

 

IF you want a bit more information, you might want to download and read the PDF file in this thread:

 

      https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/?tab=comments#comment-1009109