With the current model (call it a limitation of windows or Unraid's improvident security measure) once my user "ami" puts his credentials to access his "allowed Audio Video" share he is given full access to all of the other shares as well.

 

Hi Sammy,

 

As I'm not currently in front of my system to test, I cannot say for sure, but as far as I remember, the above statement is not entirely accurate.

 

The way I thought it worked (flawed though it is), is that if your Super User were to sign into one share, the rest of the shares become available to anyone (in the manner you describe above), while if a limited user (such as Ami) signs in to one share (that he has been granted access to), any share that he is not authourized to access becomes unconnectable until reboot, or fancy cmd prompt disconnecting (Even to Super User!!), as the lower access signing is 'already in the system'....

 

I haven't tested in awhile, so perhaps this model has changed... Though I can't see how as it is a Windows issue, or so I understood.... Does anyone else have some insight?

With the current model (call it a limitation of windows or Unraid's improvident security measure) once my user "ami" puts his credentials to access his "allowed Audio Video" share he is given full access to all of the other shares as well.

 

Hi Sammy,

 

As I'm not currently in front of my system to test, I cannot say for sure, but as far as I remember, the above statement is not entirely accurate.

 

The way I thought it worked (flawed though it is), is that if your Super User were to sign into one share, the rest of the shares become available to anyone (in the manner you describe above), while if a limited user (such as Ami) signs in to one share (that he has been granted access to), any share that he is not authourized to access becomes unconnectable until reboot, or fancy cmd prompt disconnecting (Even to Super User!!), as the lower access signing is 'already in the system'....

 

I haven't tested in awhile, so perhaps this model has changed... Though I can't see how as it is a Windows issue, or so I understood.... Does anyone else have some insight?

 

What is above should be correct.  If a "lower class" user logs in and the security is set up properly then they should not be able to gain access to the "locked down" share.

First off, Windows will not pop-up the creditials box each time you access a share. This is not an unRAID problem so you will have to figure out some other way around it.

 

Secondly, your screen captures show that the admin test acount has been given full read/write access to every share. Why would you expect this user to not be allowed to access every share?

 

Thirdly, you just claimed that the share only has options to give users either read/write or read-only permissions. If this is true, then the "no access" option is missing. I suggest you contact Limetech and/or post in the beta thread about this issue. You have to be able to deny users access when setting up security.

 

The odd thing is that this thread does say that there is a "no access" option even though you say there is not one.

 

Peter

 

lionelhutz it does have no access option ........ I am now experimenting with multiple users with different permissions and will report if it works the way it should ........ I didnt experiment with the combination of "No Access" part. I think I might be able to achieve with this option .....

Well, you certainly can't restrict a user from access if the user is given read/write permissions on every share.

 

Also from the other post;

 

Note that once you login to the server using some other username than your windows username, windows will use that username to access all shares on the server.

 

Peter

 

A private share will provide the "no access" function.

OK friends, I have some success with the, "No Access" part. But I need a quick ans to this doubt.

 

If I run some access command from telnet on to my server say for example chmod -R 777 or find /mnt/user -type d -exec chmod 755 {} \; , would this override the access rights given to a user via WebGUI.  Reason is this that I was experimenting with my "ami" user and though I managed to restrict him to have read only access to only 2 shares, what is happening is he can not access the files at all. I mean he can log in to the share via his credentials (which is good), but cannot play them (if it an mp3 file) can not download them as well. He can only open them and view them.He has Read Only access. I think read only should atleast give him the access to play/download the file. He can not write on the disk i.e upload or delete any file ...... am I not right in here ...????

 

Now I remember running find /mnt/user -type d -exec chmod 755 {} \; command via telnet as I was not able to view my files via ftp. I always run this comand to be able to view my files via ftp. Could this be the reason for the above behavior. This is almost the last hinderence in this Share Security part.

 

Regards

Sammy

 

PS :: I am also not able to download files via ftp. I get 550 failed to open file. I can only view them that too after running the 755 command ...

Do a google search on chmod to figure out what you did to fubar the permissions on the files.  You probably need to run the new perms script to fix the permissions.

 

If you write a file to the server while logged in as root, then ONLY root will be able to access it as that is who the file belongs to.  You need to set up your FTP login to log in under one of the other users (ami perhaps) or change the permissions on the file after you copy it over.  I use WinSCP to copy files over and then change the file permissions and group ownership.  I very rarely copy over FTP though, so I have not bothered to set up vsftpd "properly"

Do a google search on chmod to figure out what you did to fubar the permissions on the files.  You probably need to run the new perms script to fix the permissions.

 

If you write a file to the server while logged in as root, then ONLY root will be able to access it as that is who the file belongs to.  You need to set up your FTP login to log in under one of the other users (ami perhaps) or change the permissions on the file after you copy it over.  I use WinSCP to copy files over and then change the file permissions and group ownership.  I very rarely copy over FTP though, so I have not bothered to set up vsftpd "properly"

 

well seems I did something terribly wrong, its not only ami its me as admin as well who cannot open the files, even if I set the share to PUBLIC ... ..... So does this mean that command run off the command line override the permissions which we give via WebGUI.? I dont remember which chmod I used except "find /mnt/user -type d -exec chmod 755 {} \; " which I always use to view file on ftp. Man this is confusing.

 

If you write a file to the server while logged in as root, then ONLY root will be able to access it as that is who the file belongs to

 

IS this true only for ftp or normal copying as well via explorer to my server shares... I think you mean via ftp only .... Anyway I will troubleshoot the ftp issue later.

 

First I need to get this right, I am not able to open files on any of my shares, even if set to public. I thik I need to reset the default permissions given by Unraid when you install 5.0. How do we do that.  perm scripts ...? what and how do we get these run ......Apologies for messing this, but this is the part n parcel of the learning curve of something totally new to you. Hope you understand ....

 

Regards

Sammy

I'm not really sure what this issue is but I suspect your permissions are wrong.

 

I think you need to post the current permissions and owner of some of the files you are trying to access. Just do an "ls -l" of the directory on the server. I believe it should be "-rwxr-xr-x" and the owner is listed after the permissions.

 

You can run the New Permissions available on the Utils tab to change everything the way it should be.

 

Peter

 

I'm not really sure what this issue is but I suspect your permissions are wrong.

 

I think you need to post the current permissions and owner of some of the files you are trying to access. Just do an "ls -l" of the directory on the server. I believe it should be "-rwxr-xr-x" and the owner is listed after the permissions.

 

You can run the New Permissions available on the Utils tab to change everything the way it should be.

 

Peter

 

 

Ok running the new permissions brought back the things, but now I can not again view files on my ftp. On 4.7 I used to run "find /mnt/user -type d -exec chmod 755 {} \;" on root all the time to get the view-ability on ftp. I have to run this command everytime I copy any new files on the server to view them via ftp. .....was this command the culprit, after upgrade...... if yes then what is the correct way to be able to view files via ftp.

Write some files to the share and compare their permissions to files written via ftp. Then set the user and umask for ftp to match. You'll need to add the changes to the ftp config in the go file.

 

If you get this to work please post the modifications in the announcement thread.

Write some files to the share and compare their permissions to files written via ftp. Then set the user and umask for ftp to match. You'll need to add the changes to the ftp config in the go file.

 

If you get this to work please post the modifications in the announcement thread.

 

Ok the files written directly on the share have "-rw-rw----" permission and the files written via ftp (user root) have "-rw-------", BUT how so ever I write the file on the share, directly or via ftp, .............. if I log to ftp with root it does not see the files unless I run the 755 command I shared above.

 

How do we set the user and unmask for ftp. I did some google and it says to update the ftp config file. I could not find any ftp config file in the go part of the web gui. I found a vsftpd config via telnet under /etc , but I am not sure what to change. Here the contents of the same

 

root@SamTower:/etc# cat vsftpd.conf

# vsftpd.conf for unRAID

#

write_enable=YES

connect_from_port_20=YES

#

# No anonymous logins

anonymous_enable=NO

#

# Allow local users to log in.

local_enable=YES

local_umask=077

local_root=/mnt

check_shell=NO

#

# All file ownership will be 'root'

guest_enable=YES

guest_username=root

anon_upload_enable=YES

anon_other_write_enable=YES

anon_mkdir_write_enable=YES

#

# Logging to syslog

syslog_enable=YES

log_ftp_protocol=NO

xferlog_enable=NO

#

# Misc.

dirmessage_enable=NO

ls_recurse_enable=YES

root@SamTower:/etc#