[Write permission denied for SMB share]

No worries, I actually ran the docker-safe version to avoid touching appdata. I work with docker a lot so I'm pretty familiar with that side of things

[Write permission denied for SMB share]

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

 

[Write permission denied for SMB share]

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`.

[Write permission denied for SMB share]

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`.

[Write permission denied for SMB share]

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.

 

[Write permission denied for SMB share]

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?