I just installed unraid yesterday and am trying to create some shares, mount them on my various devices and move all my data over to the unraid server. Permissions (NFS or SMB) are not acting how I expected they would. Below are my steps, and results. What am I doing wrong?

 

Create new share called "testshare"

Enable SMB

Set as exportable

Security is "Secure"

Apply

Set SMB user access as andrew with R/W

Apply

 

ssh into unraid server

cd /mnt/user/testshare
root@unraid:/mnt/user/testshare# ll
total 0
drwxrwxrwx 1 nobody users 18 May 31 15:05 ./
drwxrwxrwx 1 nobody users  6 May 31 14:19 ../

Seems good, directories have the correct permissions

 

root@unraid:/mnt/user/testshare# touch testfile
root@unraid:/mnt/user/testshare# ll
total 0
drwxrwxrwx 1 nobody users 22 May 31 15:14 ./
drwxrwxrwx 1 nobody users  6 May 31 14:19 ../
-rw-rw-rw- 1 root   root   0 May 31 15:14 testfile

 

Seems good again, correct permissions for files as well

Back to client machine

 

1. I create the following entry in fstab

//unraid/testshare   /media/unraid/testshare   cifs   username=andrew,password=mypass,uid=nobody,gid=users,iocharset=utf8   0       0

Proceed to mount all shares

andrew@desktop:/media/unraid/testshare$ cd /media/unraid/testshare
andrew@desktop:/media/unraid/testshare$ ll
total 4.0K
drwxr-xr-x 2 nobody users    0 May 31 15:14 ./
drwxrwxrwx 9 root   root  4.0K May 31 14:57 ../
-rwxr-xr-x 1 nobody users    0 May 31 15:14 testfile*

The permissions of testfile are different and my "andrew" user does not have write permission either.

I've also set NFS security to "Public", with the following fstab entry:

unraid:/testshare        /media/unraid/testnfs            nfs     defaults        0       0

and I get the following error:

mount.nfs: access denied by server while mounting unraid:/testshare

 

Edited June 1, 20197 yr by Arindrew

13 hours ago, Arindrew said:

drwxrwxrwx 1 nobody users 22 May 31 15:14 ./
drwxrwxrwx 1 nobody users  6 May 31 14:19 ../
-rw-rw-rw- 1 root   root   0 May 31 15:14 testfile

 

Seems good again, correct permissions for files as well

Not quite!  In you look in   /etc/samba/smb.conf , you will find the following:

 

        # misc.
        invalid users = root

So there should not be any files (or directories) in a share with the user or group named 'root'.   The 'New Permissions' tool was developed just to fix this ownership/permissions problems.  (If you run this tool, CAREFULLY read the instructions as there are some shares that should NOT be included!!!) 

Edited June 1, 20197 yr by Frank1940

It’s a brand new share. Does that tool have to be run each time a share is created? 

 

The testfile permissions are correct (rw), but the ownership is root because I created it with the local root account. Right?

 

Regardless of hat individual file, I still can’t write any other files with my “andrew” account.

Right, you have to create all files in the user shares (or disk shares) from either the GUI or accessing the shares using SMB, NFS or AFP and you won't have that problem.  The owners and groups will correct.  If you are logged as 'root' (either through the console or SSH session), you should not be creating share files/directories and user shares.  It has been many, many years since I did much work with the Linux/UNIX file systems at the command line level BUT the ownership and group are very important in who has access to any resource and what access they have.  User 'root' (or users with root privileges) are the exception to this.  (They can do anything they want regardless of ownership and permissions attached to that resource.  That is the reason 'root' is denied access via SMB-- it is too big a security risk!)   By the same token, your user 'andrew' can't gain access to and files or directories with ownership or group is 'root'.  When your user 'andrew' writes to a Secure share that he has access to the owner/group/permissions in the Linux file system are still the same.  The access that you apply for SMB are only enforced at the SMB level. 

 

It has been so long since I even thought about NFS that I can't recall the in's-and out's of setting that part up. 

 

Any time you are logged as 'root', you have better be aware of the type of power that you have. You are God as far as Linux is concerned.  Your instructions will be obeyed regardless of the havoc they cause!  And most of the time, you won't even get a warning!  

 

Final thought:   I was assuming that you were using SMB to do your access to these files.  Is this correct?  Or are you using NFS?

This is all through SMB. I only tried with NFS to see if that worked instead. I did get it working. I still don't understand why creating that file with root prevented my remote user from having write permissions.

 

I deleted the testfile created by the local root account and ran the New Permissions tool again (on an empty share). Played with my fstab entry some more and got it to work. For the record, here is my /etc/fstab file

//unraid/testshare   /media/unraid/testshare   cifs username=andrew,password=mypass,uid=nobody,gid=users,noperm 0 0

How do I mark as solved?

Edited June 1, 20197 yr by Arindrew

Because your remote user is not 'root' nor a member of the 'root' group. Your user 'andrew' is a member of the 'nobody' group and thus will have those permissions granted to 'andrew'. if you look carefully at your NFS parameters, you will see that 'andrew's uid and gid assignments.  You can see what is going on at the Linux level with the following command. 

cat /etc/passwd

If you really want more information, you should google   uid  and gid  This whole subject is rather complex and until you understand it, you (and most of the rest of the world) will be confused as to its inner workings. 

 

To mark it solved, you edit the first post in this thread and change the title of the thread.  

I get how all that works (at least I think I do). What I don't understand it why having a single file in the directory that andrew doesn't have permissions to (because the owner and group are both root) prevents the whole directory from being writable.