Hi,

I had issues whenever a new file was created in unraid the permissions and owner were not set to nobody:users rather it could be the unique user who was the owner resulting in some access issues when using multiple different users to access files on shares.

 

I solved this by setting the smb conf global section:

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

 

The problem i notice now is that programs like sonarr and radarr which actually need execute permissions on files are unable to do their job properly. Is there anyway to tell unraid to set 666 to all files except in a particular area/share?

 

If that answer is no, then my second question is, would it be safe to set the smb permissions conf to this instead to solve the problem or would that result in massive security risk for whatever reason i dont know?

 

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

 

Thanks.

 

Edited June 6, 20224 yr by je82

Why are you forcing the permissions?  I can understand the user and group.  (I am assuming that sonarr and radarr work with the default permissions setup.)

 

Now, I can remember about 50 years ago when I had a course in UNIX, that we had to change the permissions on Shell scripts so that they could be executed.  So these permissions on what are considered to be 'data' files are nothing new. 

 

I do believe that you could do what you want to do on individual shares by putting the permissions under the [share] section (found in smb-share.conf) rather than under [Global].  However, I am going to grab a bit of code from the smb.conf file to indicate a potential (?) problem:
 

# hook for user-defined samba config
include = /boot/config/smb-extra.conf

# auto-configured shares
include = /etc/samba/smb-shares.conf

 

Notice that smb-extra.conf is called before smb-shares.conf and this may prevent you from being able to add these to the individual shares using the smb-extra.conf that are created in smb-shares.conf.   (You may want to test this approach to see what actually happens.  It may work fine.  The shell script that combines everything may not do any error checking until the entire smb.conf script is processed.)

 

IF you find this to be a problem, you might want to generate a Bug Report.

 

EDIT:  Another dim memory.  The reason given at the time was that there were no default extensions (or any extension for that matter) in UNIX that defined that files with certain extensions as being executable-- unlike many other OS's!  So the files had to be marked as executable so that the shell actually would process them as executable item.

Edited June 6, 20224 yr by Frank1940

19 hours ago, Frank1940 said:

Why are you forcing the permissions?  I can understand the user and group.  (I am assuming that sonarr and radarr work with the default permissions setup.)

 

I had issues when running rsync from another server that everytime that was done the folders were changing permissions making it impossible for other users who are also accessing the shares to access them. Not sure how to resolve this any other way as i tried to set the umask and user/group in rsync command and it only worked for files, not for folders. 

Example: rsync -avu --chown=nobody:users --chmod=Du=rwx,Dg=rwx,Do=rwx,Fu=rw,Fg=rw,Fo=rw

 

Anyway turns out the changes made to SMB wasn't the issue here, the container running qbittorrent had changed umask setting, maybe an update did something and this caused permission issues but it occured somewhat close to me messing with smb configuration so i defaulted to thinking this was the cause.