Hi there,

i'm using a local (windows) tdarr to encode my video files on the unraid 6.12.14 server. On the win-client it's a MS account (like: [email protected]) and on unraid server it's a private SMB share with user "alex" - so far, so good. I can read/write to the smb-share on unraid after mapping the share. But:

tdarr on the windows client runs under MS account and is no longer able to write back the encoded files to the unraid share. Annoying! Also the RW permissions on the unraid share get mixed up every time i write from the windows client to the unraid share. which causes permission errors on the server (like docker applications being unable to handle these files).  i am able to write back these files to the media shares from my windows client under my privileges given by "user password" and share mapping. But i do not want 

• guest access on unraid smb share
• lesser security than "private" or "secure"
• drop the MS account on the windows client

What is possible? This is the weirdest samba implementation i have seen in 20 years or so.

This should answer you problem. -> https://docs.unraid.net/unraid-os/release-notes/6.12.14/
I have the same Problem, but can't update to 7.0.0 becauce my parity is rebuilding.
 

In the release notes:

 

The problem is that the '@' is not an allowed character in Linux login names.  

 

Most problems with SMB access are the result of MS actions to increase security-- primarily for government and corporate customers.  If you want to read more about setting a Windows-Unraid SMB environment so that it is secure and always works, see here:

 

     https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-1011-smb-setup/#findComment-1009109

 

 

19 hours ago, AceBurn90 said:

This should answer you problem. -> https://docs.unraid.net/unraid-os/release-notes/6.12.14/
I have the same Problem, but can't update to 7.0.0 becauce my parity is rebuilding.
 

No, this is not the solution. I read that. My usernames are "@-free". See later...

17 hours ago, Frank1940 said:

The problem is that the '@' is not an allowed character in Linux login names.  

 

Still: No. It is not. See later post.

Two things turned out to be crucial for this sort of errors:

1. Unraid comes with an inferior samba implementation (at least in my user-experience): No home directories, no consistent user-management in the gui including the smb aspects and no proper rights management for new created files/directories (see following #2).
2. Every time a known and validated user (like me with my user-account without any  @ in the user-name) writes to the shares, creates files or directories the given user-rights get shaken up. This happens no matter if you go over a web interface (like creating or renaming files via filebot docker web interface) or directly from windows via file managers. So i googeled this stuff and the only fix or workaround is to add something to the smb-extra.conf in the flash-drive /config directory:

 

logging = 0
force create mode = 0666
force directory mode = 0777
force user = nobody
force group = users
create mask = 0666

 

Then hopefully every single file or directory you create like in step 1 gets the right file-mask/permissions. Otherwise you have to re-write them via "Docker Safe New Permissions" very often (which is a pain in the a..).

 

I never ever had these kind of quirky samba experience with any fileserver or nas OS i was using in the last 20+ years. OMV, TrueNAS, Koozali, Synology, Qnap - you name it. Only unraid does this kind of quirks - the main reason i would never ever trust it in a multi user windows centric environment.

 

So these additions to smb.conf don't make it flawless. But it is a start.

14 minutes ago, azche24 said:

Every time a known and validated user (like me with my user-account without any  @ in the user-name) writes to the shares, creates files or directories the given user-rights get shaken up. This happens no matter if you go over a web interface (like creating or renaming files via filebot docker web interface) or directly from windows via file managers. So i googeled this stuff and the only fix or workaround is to add something to the smb-extra.conf in the flash-drive /config directory:

Let's begin that I acknowledge that the SMB configuration that LimeTech is using is not really a standard one.  I will give you that.  I would never recommend it for a large business environment.  It might even not be suitable for a small business situation.   It lacks too many tools.  I have never tried it in an AD environment but I do know that there folks (few/many, I know don't know!!!)  who are using it in that environment and there are some issues.

 

But to be fair, Unraid was never intended for a really secure type of environment.  In fact, the biggest headache fro those of us who are attempting to assist in solving SMB issues is for Unraid users who want to use SMB using 'guest' access and SMBv1. (You know a network setup from 2010.)  With MS attempting to cut off both of these, there is a whack-a-mole battle ongoing between them and MS.  But that is another side. 

 

OK----  I don't quite understand what issues you are having.  I have two users profiles for SMB on my Unraid system--  user and smbuser   with 'user' have superuser privilege of read/write. (I do occasionally turn on read/write for smbuser when it is needed...)  All of my shares are Private and this is a screenshot  of permissions, owner and group on my Unraid server:

 

Notice that the owner is the client computer that wrote the file initially.  (The ones with the owner 'nobody' were created before I set up a more secure environment.)  Through a forensic analysis, I have determined that most Unraid access actually comes through the group permissions and that is why the group permissions have to be rw-  rather than the standard Linux r--.  (Every Share User created via the USER tab is an automatic member of the users group!) 

 

I can assure that both users can access any of these files consistent with the permissions granted them through the SMB Security settings:

 

 

It is fairly easy to set up for the average Unraid user and provides all the security that most of  them require.  By contrast, setting up thing using Windows side is a complicated task and most businesses end up hiring an IT professional with MS certification to do the job and maintain the system. 

 

If you are attempting to set permissions on Unraid files via Windows, you should be looking at the AD environment which means you have to install one of the Windows Server products. 

 

That's all fine, but underwhelming. Each and every Linux based NAS system or solution can do samba - why is this so quirky with unraid? Of course you will want to rename, move and copy file from a windows client, if there is about 20 TB data on your NAS/server. And why would you need special precautions and workarounds like "Docker Safe New Permissions" after you just renamed a few files on your server from a windows client? I don't get it. I never ever needed a windows server or IT-service for this kind of stuff before and am still hoping, that these inconsitencies get better: I (as an authenticated user) copy or rename a file on the unraid mount and after that tdarr isn't able to read/convert it any more? Really?

Edited January 14, 20251 yr by azche24

20 hours ago, azche24 said:

And why would you need special precautions and workarounds like "Docker Safe New Permissions" after you just renamed a few files on your server from a windows client?

Most of the folks who recently have needed to run New Permissions have Docker containers that are access the file system using Linux and are not setup with the proper owner (nobody), group (users) and permissions (777 for directories and 666 for files). 

 

You are the first person that I have encountered in a long time who has generated a permission issue when they are writing to an Unraid share using SMB.  I can only suspect that you are trying to manage permissions by applying permissions using Windows.  (Essentially, using Windows File Manager and right-clicking on an Unraid share, selecting 'Properties' and then the 'Security' tab.)   If this isn't what you are doing, you are going to have to provide an example (screenshot) of the problem using the Linux   ls -al  {path-to-problem}   command so that we can see what it happening to the permissions.