SMB private read/write working, just can't paste folders (only files)

[Brammer]

I'm having a weird permissions issue with my samba shares. I have my samba shares configured as private with read/write rights for my account. This is working fine. I can access the shares from my Fedora 37 laptop and Android 12 phone (using my credentials), create/delete/rename folders and do the same for files. Doesn't matter if I've put the there manually via smb or if they have been put there by transmission/radarr/sonarr/...ect. But I can't paste folders somehow... not on any of the shares. Not in the root of the share and not in sub directories.

 

I can overwrite folders that have been created manually via smb.
Example (assume the root can be the root of the share or a sub folder; makes no difference):
 

755 nobody users  ./
755 nobody users  ../
755 nobody users ./existing-folder
755 nobody users ./folder-created-from-docker-container
755 myusername users ./folder-created-via-smb

 

Pasting a folder named "existing-folder" or "folder-created-from-docker-container" will result in a "Permission Denied" error.

Pasting a folder named "non-existing-folder-in-share" will result in a "Permission Denied" error

Pasting a folder named "folder-created-via-smb" will work as expected without any errors

 

 

For example.. I've just added nginx as a docker container. Freshly installed I can paste all the files I want to the /mnt/user/appdata/nginx/www directory . But I'm getting a "Permission denied" for the folders I'm simultaneously pasting from my Fedora 37 laptop. I've tried to do the same from my Android 12 phone with the exact same result.

 

I've been trying to figure out what's going wrong here for two days. I also did run the Tools -> New Permissions script without it making a difference. Hopefully someone here can help me figuring this out?

 

Edit: I've just figured out that I can create folder, but I also can't paste folders into the folders I've created manually.

OS: Unraid 6.11.0 

Client: Fedora 37

Edited September 28, 2022 by Brammer

[Frank1940]

Looking at what you have posted up is confusing at this point.  I am going to post what should be the permissions for directories for SMB to work correctly.

 

Notice that all of the directories from /mnt/user down the tree have to have 777 permissions.    (The last listing a actually a file.  this is indicated by the fact that the first character is a '-'.  For a  directory, it will be a 'd'.)    You can run the Docker Safe New Permission tool to fix this.  You can also use the New Permissions tool but you have to exclude the 'appdata' and 'CommunityApplicationsAppdataBackup' shares as these shares often have different owners, groups and permissions assigned to them!

 

Neither of these tools will fix the directories in /mnt/user so this has to be done manually.

Edited September 28, 2022 by Frank1940

[Frank1940]

Quote

Directory permissions:
Permissions are a bit different for directories:

• read allows a user to view the directory's contents
• write allows a user to create new files or delete files in the directory. 
• execute determines if the user can enter (cd) into the directory or run a program or script.

If you want all group members to be able to write, edit, or delete files you would type at the prompt (in the correct directory): chmod g+w (All group members can write to the file. (Caution -  This means that a user with write privileges in the DIRECTORY can delete files even if he/she does NOT have write permissions for the FILE!)  If you want to create a group of users whose access can be controlled by the group permissions, consult with your system administrator. The system administrator usually has to set up the group.

EDIT:  Changed to a quote as I copied and pasted it from another web page.   Not sure about the chmod command.  One should consult the man page for more details on this command. 

Edited September 28, 2022 by Frank1940

[je82]

sounds like smb issues, i had these too, i fixed them by modifying the smb configuration on unraid:

 

in settings > smb > smb extra configurations added:

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

 

These will make sure all files/folders created via smb on unraid no matter what user is making them it ends up with permissions and owner nobody:user which is how unraid likes to operate.

 

Since you had smb issues chance is a lot of files have weird permissions, you might wanna run Tools > New Permissions on all your shares after adding that to your smb configuration, then all files will have the correct permissions and all new files created via smb will also have the correct permissions going foward.

Edited September 28, 2022 by je82

[Frank1940]

1 hour ago, je82 said:

sounds like smb issues, i had these too, i fixed them by modifying the smb configuration on unraid:

 

in settings > smb > smb extra configurations added:

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

 

Looks like an interesting approach to the problem,

 

I know that on my Private shares that the 'owner' ends up being the Unraid share access user rather than 'nobody'.  While I have not encountered any problems to date, I can see where it might in the future.  (The 'group' is still 'users' which is good.)   

 

The only issue I see with this approach is that it only addresses those files which are generated through SMB.  Files/Directories being added to the server via Linux Dockers are also a problem.  Many of them have to make provision similiar owner/user/permission settings but apparently not all Dockers are strictly developed to be used in the Unraid environment but in a larger Unix environment and their default values are not always compatible with Unraid.

 

I hope some other folks ( @limetech,  @dlandon, @Geoff Bland, @bonienl, @JorgeB )  will jump in and add their two cents in a discussion about your suggestions.  

Edited September 28, 2022 by Frank1940

[Brammer]

10 hours ago, Frank1940 said:

 

Looks like an interesting approach to the problem,

 

I know that on my Private shares that the 'owner' ends up being the Unraid share access user rather than 'nobody'.  While I have not encountered any problems to date, I can see where it might in the future.  (The 'group' is still 'users' which is good.)   

 

The only issue I see with this approach is that it only addresses those files which are generated through SMB.  Files/Directories being added to the server via Linux Dockers are also a problem.  Many of them have to make provision similiar owner/user/permission settings but apparently not all Dockers are strictly developed to be used in the Unraid environment but in a larger Unix environment and their default values are not always compatible with Unraid.

 

I hope some other folks ( @limetech,  @dlandon, @Geoff Bland, @bonienl, @JorgeB )  will jump in and add their two cents in a discussion about your suggestions.  

 

Thanks all for the input! 

I'm wondering... which umask should a docker container use? I see a mix of 002 and 022 by default. Some suggest using 000. I'm not sure if this could influence the described behavior and which umask I should use (or never use).

[Frank1940]

7 hours ago, Brammer said:

I'm wondering... which umask should a docker container use? I see a mix of 002 and 022 by default. Some suggest using 000. I'm not sure if this could influence the described behavior and which umask I should use (or never use).

 

Let me be by saying that I am not a Linux Guru.  I often say I know enough to make me really dangerous.   I did a bit of googling before I wrote this to verify some of my presumptions.

 

But let's start from this premise that @limetech intends that all of the files on the array should have the following permissions:

-rw-rw-rw- 1 root    root            0 Sep 29 09:07 test.txt

(I created this file from the command line using the   touch    command  so the owner and group are 'root'.) and directories should have the following permissions:

drwxrwxrwx 9 nobody  users        4096 Jul  9  2020 appdata/

 

A umask of 002 would remove the write permission from the 'others' category for both new directories and files.  Similarly, a umask of 022 would remove write permissions for 'group' and 'others' category for all new files and directories.  I will now make another assumption that this umask setting is for files/directories that are to be written to the Unraid array.  I will make a further assumption that LimeTech really wants all files written to the array to have the 666 permissions for file and 777 permissions for directories. 

 

Using this line of reasoning, the umask for files to be written to the Unraid array by a Docker Container should be 000. 

Edited September 29, 2022 by Frank1940

[Frank1940]

I have been thinking about, researching, and running some tests on SMB shares for the past few days.  The results were not quite what I thought they might be.

 

First thing, the owner and group are not important in having access to any file in a SMB share using a Windows 10 client computer!   I created both files and directories using the GUI terminal and had no problem with any read/write/delete function from a WIN 10 client using SMB! 

 

I also found that Unraid always creates files with 666 permissions and directories with 777 permissions from either the command line or via SMB using a standard WIN10 client.  When using the command line, the owner will be root and the group will be root.   When using the client to create either using SMB, the owner will be the <Shares_Access_User> and the group will be users.   Note that the owner could be  nobody if the share is Public with the intend to provide read/write access for 'guest' users.

 

So why are people having problems?  I think it is a combination of factors.   Let's look at a few possibilities. 

 

I believe the primary problems for the vast remainder of us is with permissions.   Windows and Unraid get along fine in this situation with the default setting using SMB.   Other OS's and devices which use SMB may have an issue.  For this situation, the solution could well be this advise from  @je82:

 

On 9/28/2022 at 5:37 PM, je82 said:

in settings > smb > smb extra configurations added:

force create mode = 0666
force directory mode = 0777

For what these two parameters do, see this document from samba.org:

 

           https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

 

(This document can be a valuable reference for parameters both to explain what the one that you find in smb.conf and its include files do, and to figure out if there is a way to address a problem by changing the way SMB is working.)

 

This will probably not work if you are connecting with NFS.   I have no experience with using this protocol in the past fifteen years of so.  The little research that I did seemed to indicate that the permissions for most users was often set to be 644 for file creation and 755 for directories.  (This is being done for security reasons.)  These will not work for SMB Unraid!  You will have to find the solution to getting NFS setup to provide the proper permissions.  (google can often be your friend here!)   However, I suspect that the group may be important for NFS. 

 

Dockers are another important area to be considered. First thing is to know what Dockers are going to be writing data to your array.  Make sure that the umask for any writes to the Uraid array is 0000 if you expect other services (SMB) and devices to be to access and work with the files that the Docker is writing.

 

Other area is the problem of Active Directory (AD).   For those who may not be familiar with this term, it is a component of Microsoft's Domain networking software product line.   If you have not heard of it, you have no reason to be concerned about it.   (It authenticates and authorizes all users and computers in a Windows domain type network, assigning and enforcing security policies for all computers.)   It appears to have issues in interfacing with the Unraid server.   (I have no insight into addressing any of those problems as I have no experience with AD.)   There is a group who have been working toward a solution and you can find information here if you have AD  issues:

 

        https://forums.unraid.net/bug-reports/stable-releases/6103-intermittent-smb-issues-after-6102-upgrade-r2028/

 

One final note.  This post was written in response to an access problem from a non Windows device.  If you are having a Windows problem be sure that you have properly configured both Unraid and your Windows Client computer.  You can find a PDF in the first post of this thread on how to do that here:

 

      https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/

 

 

[Brammer]

54 minutes ago, Frank1940 said:

I have been thinking about, researching, and running some tests on SMB shares for the past few days.  The results were not quite what I thought they might be.

 

First thing, the owner and group are not important in having access to any file in a SMB share using a Windows 10 client computer!   I created both files and directories using the GUI terminal and had no problem with any read/write/delete function from a WIN 10 client using SMB! 

 

I also found that Unraid always creates files with 666 permissions and directories with 777 permissions from either the command line or via SMB using a standard WIN10 client.  When using the command line, the owner will be root and the group will be root.   When using the client to create either using SMB, the owner will be the <Shares_Access_User> and the group will be users.   Note that the owner could be  nobody if the share is Public with the intend to provide read/write access for 'guest' users.

 

So why are people having problems?  I think it is a combination of factors.   Let's look at a few possibilities. 

 

I believe the primary problems for the vast remainder of us is with permissions.   Windows and Unraid get along fine in this situation with the default setting using SMB.   Other OS's and devices which use SMB may have an issue.  For this situation, the solution could well be this advise from  @je82:

 

For what these two parameters do, see this document from samba.org:

 

           https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

 

(This document can be a valuable reference for parameters both to explain what the one that you find in smb.conf and its include files do, and to figure out if there is a way to address a problem by changing the way SMB is working.)

 

This will probably not work if you are connecting with NFS.   I have no experience with using this protocol in the past fifteen years of so.  The little research that I did seemed to indicate that the permissions for most users was often set to be 644 for file creation and 755 for directories.  (This is being done for security reasons.)  These will not work for SMB Unraid!  You will have to find the solution to getting NFS setup to provide the proper permissions.  (google can often be your friend here!)   However, I suspect that the group may be important for NFS. 

 

Dockers are another important area to be considered. First thing is to know what Dockers are going to be writing data to your array.  Make sure that the umask for any writes to the Uraid array is 0000 if you expect other services (SMB) and devices to be to access and work with the files that the Docker is writing.

 

Other area is the problem of Active Directory (AD).   For those who may not be familiar with this term, it is a component of Microsoft's Domain networking software product line.   If you have not heard of it, you have no reason to be concerned about it.   (It authenticates and authorizes all users and computers in a Windows domain type network, assigning and enforcing security policies for all computers.)   It appears to have issues in interfacing with the Unraid server.   (I have no insight into addressing any of those problems as I have no experience with AD.)   There is a group who have been working toward a solution and you can find information here if you have AD  issues:

 

        https://forums.unraid.net/bug-reports/stable-releases/6103-intermittent-smb-issues-after-6102-upgrade-r2028/

 

One final note.  This post was written in response to an access problem from a non Windows device.  If you are having a Windows problem be sure that you have properly configured both Unraid and your Windows Client computer.  You can find a PDF in the first post of this thread on how to do that here:

 

      https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/

 

 

Thank you for your elaborate answer Frank! I'm going to make sure all docker containers that create files that can be accessed using samba create them with umask 000. And I will apply the suggested samba configuration. I'm pretty sure this isn't the correct solution from a security perspective, but that doesn't really matter in this case.

 

I'm a dedicated Linux desktop and server user for more then 20 years, and a software developer. Working with permissions from these different perspectives (os, docker instances, smb server and client, nfs, web hosting and file servers... and especially those services combined on one server) can still throw me off. In this case the user rights are being managed automatically by the os, which makes it even less transparent.

 

I'm taking the easy way out in this instance, since it's just my home server, and use the solutions you (and others) suggested.

 

Thanks a bunch!

Edited September 30, 2022 by Brammer

[Ernest V]

On 9/28/2022 at 4:37 PM, je82 said:

sounds like smb issues, i had these too, i fixed them by modifying the smb configuration on unraid:

 

in settings > smb > smb extra configurations added:

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

 

These will make sure all files/folders created via smb on unraid no matter what user is making them it ends up with permissions and owner nobody:user which is how unraid likes to operate.

 

Since you had smb issues chance is a lot of files have weird permissions, you might wanna run Tools > New Permissions on all your shares after adding that to your smb configuration, then all files will have the correct permissions and all new files created via smb will also have the correct permissions going foward.

 

 

Thanks This fixed my SMB file permission issues. Are there any down sides to doing this forced setting this? Private shared are no longer private etc...

Edited February 3, 2023 by Ernest V

[Frank1940]

6 hours ago, Ernest V said:

Thanks This fixed my SMB file permission issues. Are there any down sides to doing this forced setting this? Private shared are no longer private etc...

 

I believe there are real security issues if you are using NFS to access your files or you have allowed access directly to the Array from a Docker or VM.  (More simply put, in any situation where you are allowing access to the files on the array and not using SMB.)