Jump to content

nogroup setting on newly copied files


Recommended Posts

I was wondering why my newly copied media files are being set to nobody:nogroup instead of nobody:users ?

This is a problem because then I can't play the videos unless I manually change the permissions or via the web Utils-->New Permissions

 

I obviously don't want to have to do this every time I copy new TV shows or movies.

Where is the proper location and proper method to tell the system to create nobody:users 660 (in the go file?)?

 

And it should be a solution which remains after a reboot.

Thanks for anyone's help.

 

Link to comment

Describe in detail exactly how these files are being 'copied' to your server.  When this issue crops up, it is usually because the files are being generated by application that sets its own permissions or from a computer which has user credentials enabled. 

Link to comment

Simply copying with samba connection as a network share.

I have a user on my PC which I also created on unRaid server and both have the same password.

 

Did you map the server share as a local drive on the PC?  Or are you getting to the share by clicking on 'Network', then selecting the server and the share name? 

Link to comment

Never heard of Credential Manager before, but I looked into and the 2 unRaid servers were not in there although my two media streamer units were listed.

I added the 2 servers with the user name I created on the server and the password, so I'll test it out and see if that helps with the nogroup problem.

 

Link to comment

Another question which I probably should have asked earlier.  How did you create  the users on the server.  Did you do it from the command line or use the GUI interface.  The reason for the question is that your user 'names' should have been assigned to the 'users' group.  I can't quite understand where this 'nogroup' group came from. 

Link to comment

Try this command in a Telnet session:

 

      cat /etc/group

 

This was my ouput:

 

root@Rose:~# cat /etc/group
root:x:0:root
bin:x:1:root,bin
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:
disk:x:6:root,adm
lp:x:7:lp
mem:x:8:
kmem:x:9:
wheel:x:10:root
floppy:x:11:
mail:x:12:mail
news:x:13:news
uucp:x:14:uucp
man:x:15:
dialout:x:16:uucp
audio:x:17:
video:x:18:
cdrom:x:19:
games:x:20:
slocate:x:21:
utmp:x:22:
smmsp:x:25:smmsp
tape:x:26:
mysql:x:27:
rpc:x:32:
sshd:x:33:sshd
gdm:x:42:
shadow:x:43:
ftp:x:50:
oprofile:x:51:
apache:x:80:
messagebus:x:81:
haldaemon:x:82:
plugdev:x:83:
power:x:84:
netdev:x:86:
pop:x:90:pop
scanner:x:93:
nobody:x:98:nobody
nogroup:x:99:
users:x:100:
console:x:101:
avahi:x:214:
avahi-autoipd:x:62

:

 

Notice these two lines near the end:

 

nobody:x:98:nobody
nogroup:x:99:

 

Do you have different users?  (Format, as I recall, is 'group name':x:'group number':'user name(s)'  )

 

Link to comment

Pretty sure I added user 'nmt' from the web gui, in order to make sure it stayed persistent after reboots.

 

Looking at /etc/group I don't see 'nmt' added to group 'users'.

However now when I copy files the same way I always do, the permissions on the server for the new files are

nmt:users instead of nobody:nogroup

 

and since the permission is 660 I believe this will be ok to access the files without permission problems.

I will add user 'nmt' to the /etc/group file under users just to be sure.

 

If that does indeed work as expected, the question now is:

How do I change the web gui option Utils-->New Permissions to set files to nmt:users instead of nobody:users ?

It may not be necessary but worth doing for consistency.

 

Link to comment

If you type 'groups nobody' at the command prompt, you should see that that nobody is a member of the 'nobody' and 'users' groups.  See my output in the code box below:

 

root@Rose:~# groups nobody
nobody : users nobody

 

Check and see what groups your user 'nmt' is a member of.  If 'nmt' is a member of users, I believe everything will work OK. (Otherwise, he would not have access to files owned by 'nobody'.)  If that is the case, there is no need to change 'new permissions'  script to make all the owner:group listings alike.  The file system is designed to work with different owners  and group members to have access rights to files as defined.  (By the way, the owner does not have to be a member of the the group. But in that case, he would not have access to any other file in the group unless he owned it.)  In this case with 660, the owner has read and write permissions and the members of the group have read and write permission.  (And no one else who is not a member of the group is permitted any access.)  Since 'nobody' is a member of the users group, anyone should have total access to the files that are in the 'users' group. 

 

Link to comment

It is odd that I don't have the same setting as you since I never messed around with group ownership, unless one of the plugins did.

 

#  groups nobody

nobody : nogroup nobody

#  groups nmt

nmt : users

 

And nmt:users is because I added it today to the /etc/group file.

 

I can live with this solution.

Thanks for all your help on this.

 

Link to comment

The only question that I have is that 'nobody' is not a member of your 'users' group.  This would normally imply that 'nobody' can not see a file that has nmt:users credentials.  (On both of my unRAID servers, the user 'nobody' is a member of both the 'nobody' group and the 'users' group.)

 

This whole 'nobody' and 'nogroup' usage in Linux is extremely confusing and I haven't found a good explanation that truly explains the entire situation.  (Perhaps, it is because every favor of Linux uses the two users in its own unique way.)  I can understand that concept of using an anonymous user with limited privileges as a security measure.  I am hoping someone can jump in and either explain how it is implemented and really works, or point me to a good explanation of it. 

 

dwwoods99--- check and see that everything on your system has the type of access required for those files with nmt:users credentials.  The nobody:users concept (as implemented in unRAID) is designed to provide unlimited and hassle-free (no login required) access to all files with both read and write privileges.  You may have to manually add the user 'nobody' to the 'users' group IF you have any issues. 

 

 

Link to comment

Something is wonky with the users and groups settings. There should be no need for any of these command line commands to fix group issues. You may be masking the issue without actually fixing it and it may reappear unexpectedly. Show a screenshot of the unRAID users page. Attach a syslog.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...