Write permission denied for SMB share


krixon

Recommended Posts

I am unable to write to a public SMB share (share is exported and public). I am able to read from the share.

 

I am authenticating as a guest. The output of smbstatus while authenticated is:
 

Samba version 4.11.4
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
26479   nobody       users        work-laptop (ipv4:192.168.0.65:45236)     NT1               -                    -                    
26035   nobody       users        work-laptop (ipv4:192.168.0.65:45180)     NT1               -                    -                    
15942   (auth in progress)        192.168.0.65 (ipv4:192.168.0.65:51116)    SMB3_11           -                    -                    
15942   nobody       users        192.168.0.65 (ipv4:192.168.0.65:51116)    SMB3_11           -                    -                    

Service      pid     Machine       Connected at                     Encryption   Signing     
---------------------------------------------------------------------------------------------
IPC$         26479   work-laptop   Tue Oct 20 05:45:56 PM 2020 BST  -            -           
tv           15942   192.168.0.65  Tue Oct 20 05:59:48 PM 2020 BST  -            -           
IPC$         26035   work-laptop   Tue Oct 20 05:45:48 PM 2020 BST  -            -           

No locked files

 

The two lines using protocol version SMB3_11 are from my connection. I am unsure why (auth in progress) is there, but it never seems to finish.

 

The permissions on the share itself are:

drw-rw-r-- 1 nobody users  772 Oct 20 16:22 tv/

I *can* write a file into the root of the share. However, a subdirectory has these permissions:

 

drwxr-xr-x 1 nobody users   30 Oct 20 17:48 foo/

I *cannot* write to this subdirectory. Obviously the group write permission is missing, but I am logging in as the nobody user so that shouldn't matter. Also the execute bits are set, but again I can't see why that should matter. Edit: If I set the group write bit, I am able to write to the subdirectory.

 

So based on the above, I would expect to be able to write to this directory, however I am denied permission to do so. Is the "auth in progress" an issue here?

 

Edited by krixon
Link to comment
18 hours ago, krixon said:

*cannot* write to this subdirectory. Obviously the group write permission is missing, but I am logging in as the nobody user so that shouldn't matter. Also the execute bits are set, but again I can't see why that should matter. Edit: If I set the group write bit, I am able to write to the subdirectory.

 

In the permissions scheme for directories, the execute bit must be set in order to change (cd) to the directory.  Not have it 'set' can lead to wonky behavior.

 

There is a tool which will fix all of these problems with permissions called New Permissions.     Tools   >>>   New Permissions     (It is normally installed when you install the Fix Common Problems plugin.)  You can use the Unraid-supplied Permissions tool but you have to be careful not to run it on certain system files/directories used by such things are Docker and VM's.  (I understand that it will normally exclude these directories but I have not have occasion to use it for many years so I can't speak from experience.)

 

Most of the time, the reason that folks end up with wrong permissions is that there is a Docker, Plugin or VM that is setup wrong.  You should be able to figure out what application generated these files and directories and that is the place to start.

 

I am going to include a link here about SMB 'users' and the many gotcha's that folks will encounter.  The reason I am doing this is that Windows throws-up cryptic error messages when SMB issues happen. 

 

https://forums.unraid.net/topic/25064-user-share-problem/?tab=comments#comment-228392

 

 

 

 

Link to comment
18 hours ago, krixon said:

However, a subdirectory has these permissions:

 


drwxr-xr-x 1 nobody users   30 Oct 20 17:48 foo/

 

The user, nobody, is the owner of this share.    The name describes who this owner is.  As I understand, there is no 'nobody' user.  So he does not really exist except as a place holder.  So the write permissions are controlled by the Group and Other permission bits.  Since they are turned off for this directory, you will not be able to write to it.

 

Remember that Samba is running on top on Linux and your access to files is through Samba.  At the top, are your SMB permissions to the resources that Samba has access to using the Linux file permissions that are underneath the Samba layer.  If the Linux permissions deny Samba access to a resource, you can't access it regardless of your SMB permissions.   (Understand that Samba is a Linux process that provides SMB services...)

Link to comment
4 hours ago, Frank1940 said:

In the permissions scheme for directories, the execute bit must be set in order to change (cd) to the directory.

Huh, despite many years of using Linux on servers as well as for my main desktop OS, this bit of basic info has somehow passed me by! Thank you!

 

I have set the permissions on a test directory inside my share as follows:

drwxr-xr-x 1 nobody users   10 Oct 21 16:49 test/

I can read the directory via SMB, but still cannot write to it without the group write bit. I understand what you're saying about Samba ultimately being governed by the Linux filesystem permissions, but these look correct to me when authenticating as `nobody/user`. My understanding of the `nobody` user corresponds with itimpi's post - that `nobody` is just a regular user with no special semantics or magic - so I can only assume that there are SMB-level permissions, or I'm not actually authenticating as `nobody` somehow, but that's contrary to `smbstatus`.

 

I will read through your link and also run the permission fixer tool to see if it produces any different permissions that those I've set myself or are being set by docker containers.

 

The simple workaround is obviously to just set the group write bit, but I'd like to understand what's happening if possible.

 

Thanks for your help.

 

Edited by krixon
Link to comment

I'm using Ubuntu. From the file manager, I navigate to `Other Locations -> Networks -> My Server` and am prompted to authenticate. I choose "Guest" and do not provide any other credentials. I'm presented with my unraid shares at this point. If I then run `smbstatus` on the server, it shows a new connection from my client machine with the username `nobody` and group `users`.

Edited by krixon
Link to comment
6 minutes ago, krixon said:

My understanding of the `nobody` user corresponds your your last post - that `nobody` is just a regular user with no special semantics or magic - so I can only assume that there are SMB-level permissions, or I'm not actually authenticating as `nobody` somehow, but that's contrary to `smbstatus`.

I would suggest that you google    linux user nobody    and read the various posts.  As I understand it, if you access the server without a valid password, you are given 'guest' access privileges and not assigned the user name of 'nobody'.  (In fact, I would suspect that you have less privileges than 'nobody'.  Be sure to read that link that I provided where LimeTech goes through much of what is happening behind the scenes. ) 

 

I understand that this 'guest' type of access can be turned off but doing so would require that you have to log on to have even read access on SMB shares.  LimeTech has choose not to impose the restriction as it would really break a lot of simple file sharing setups!

 

Furthermore if you look at the members of the group 'users', you will find that the user, nobody, is not a member of that group.

 

You have to understand that all of these 'conventions' have been developed over many years and with much careful thought put into them by a great many people.  What us casual users have to do is to understand the rules and not expect things to work as how we would want them to.  Unraid expects to find that all SMB files will have the following owner/group and permissions assigned to every file:

-rw-rw-rw- 1 nobody users

And the following to each directory:

drwxrwxrwx 1 nobody users

If it differs from the pattern, you can expect to have issues at some point.

Link to comment
2 minutes ago, Frank1940 said:

Unraid expects to find that all SMB files will have the following owner/group and permissions assigned to every file:


-rw-rw-rw- 1 nobody users

And the following to each directory:


drwxrwxrwx 1 nobody users

 

And this is what Tools - New Permissions does when it fixes permission problems. The permissions you should be concerned with are those given by the SMB Security Settings of the particular User Share. There is no reason for you to mess with the linux permissions.

  • Like 1
Link to comment
13 minutes ago, krixon said:

I'm using Ubuntu. From the file manager, I navigate to `Other Locations -> Networks -> My Server` and am prompted to authenticate. I choose "Guest" and do not provide any other credentials. I'm presented with my unraid shares at this point. If I then run `smbstatus` on the server, it shows a new connection from my client machine with the username `nobody` and group `users`.

I am not a real-dyed-in-the-wool- Linux Guru but I suspect that what you are seeing the Samba process running on the Unraid server.  Samba is running as the user  nobody   in the   users   group. 

Link to comment
7 minutes ago, trurl said:

And this is what Tools - New Permissions does when it fixes permission problems. The permissions you should be concerned with are those given by the SMB Security Settings of the particular User Share. There is no reason for you to mess with the linux permissions.

Thanks, I've run the tool and configured my containers to set the same permissions on new files and directories. This fixes the problem, though I'm still interested to understand why the `nobody` user can't write to its owned files with the previous permissions given the SMB security setting is `Public`.

Link to comment
15 minutes ago, Frank1940 said:

I am not a real-dyed-in-the-wool- Linux Guru but I suspect that what you are seeing the Samba process running on the Unraid server.  Samba is running as the user  nobody   in the   users   group. 

I don't think that's the case. From my client:

$ smbclient \\\\server.local\\tv
Enter WORKGROUP\xyz's password: 
Try "help" to get a list of possible commands.
smb: \>

On the server:

smbstatus --resolve-uids

Samba version 4.11.4
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
<snip>         
24988   xyz          users        192.168.0.65 (ipv4:192.168.0.65:46782)    SMB3_11           -                    partial(AES-128-CMAC)

smbd itself is running as root:

$ ps aux | grep smb
root      6109  0.0  0.2  52532 14872 ?        S    16:49   0:00 /usr/sbin/smbd -D
root      6487  0.0  0.2  60972 15128 ?        S    16:50   0:00 /usr/sbin/smbd -D
root      6507  0.0  0.2  52496 13964 ?        S    09:22   0:00 /usr/sbin/smbd -D
root      8159  0.0  0.0   3904  2256 pts/0    S+   18:10   0:00 grep smb
root     12677  0.0  0.3  53064 15856 ?        S    17:26   0:00 /usr/sbin/smbd -D
root     15099  0.0  0.2  52984 14928 ?        S    17:27   0:00 /usr/sbin/smbd -D
root     24988  0.0  0.2  52344 14076 ?        S    18:05   0:00 /usr/sbin/smbd -D
root     25570  0.0  0.2  52292 15076 ?        Ss   Oct20   0:00 /usr/sbin/smbd -D
root     25573  0.0  0.1 1072772 9212 ?        S    Oct20   0:14 /usr/sbin/smbd -D
root     25574  0.0  0.1  50336  7284 ?        S    Oct20   0:00 /usr/sbin/smbd -D

 

Edited by krixon
Link to comment

I, personally, am not a Samba programming Guru.  I only want to know the rules of what works.  I know a lot of the rules.  I will play using those rules...  That is the limit of my expertise.

 

IF you want to know more, you will have to start googling and reading what true experts know.  You should probably be going to the Samba support forums and the Samba software development group to ask your questions.  You should first realize that there is a SMB security layer on top and a Linux security layer on the bottom and the Samba layer is in between.   (The same can be said of the files systems.  And these two file systems don't really map one-to-one.  If you know where to look, you can find some real issues--- starting with Linux being case sensitive and Windows not being so!)

Link to comment
  • 10 months later...

hi all- I have linuxserver qbittorrent docker downloading files to my Downloads user share (which has SMB read/write access setup correctly to my Windows VM). When I try to edit said downloaded files in that Share in Windows SMB, it gives me the error "You require permission from Unix User\nobody to make changes to this file". Is this maybe related to the qBt docker not giving proper permissions for full read/write to files being created through it? If so, is there something I need to do to the docker container template / actual config files to enable this? I need it specifically for some post-processing that a Windows program does to downloaded files, which I can't do otherwise through Krusader etc. (normally, I use Krusader to otherwise move/copy files instead of SMB).

 

The only thing I was able to find online so far is someone on this forum recommending to set extra parameters of the qBt container to "-e UMASK_SET=000". Does this sound right / is it safe? I ask because I'm seeding tons of files and don't want to mess up anything by hastily setting a parameter that I'm not 100% familiar with.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.