0

I got a RAID mounted as /mnt/NAS. In this mount I got a folder called /mnt/nas/rec. The mount is shared with SAMBA, and guest users are assigned as the user nobody and are tied to the group nogroup, this may not be ideal, but it work pretty good for my intentions. It is woth to mention that SAMBA users can write and make as many directories as they want in the /mnt/nas/rec folder.

I now have a user hts that should be allowed to write to my /mnt/nas/rec folder, I started with adding the user to the group nogroup this went well and the user can now create folders inside /mnt/nas/rec, good. The problem arises when the user tries to enter a folder created by himself, resulting in a "Permission Denied". I tried giving the folder ownership to the group, and just to test I chmod -R 777 * /mnt/nas/rec this will make the folder hts created writable, but if I then create a new folder inside this one the same problem persist.

Why is this folder not writable by the user creating it? I guess I have to give all new files created inside /mnt/nas/rec a "writable by group" setting, but how?

I then tried ls -al which gives me the following :

drw-rwsr-x+ 2 hts users 4096 Aug 24 02:04 test1

Showing that hts is a member of the group users(?), I then ran :

root@...:/mnt/nas# usermod -g nogroup hts
usermod: no changes
root@...:/mnt/nas# usermod -G nogroup hts

And created a new folder in /mnt/nas/rec giving me this :

drw-rwsr-x+ 2 hts  users   4096 Aug 24 02:17 hehehe

Still showing "users" as the group. I'm confused. I know there is a trillion different questions concerning this / problem like this, but I feel like I have tried them all, setting umask and ACL and much more.. I'm currently at a point where I dont know what more I can try.

  • I don't get it... if your problem is in the file "hehehe" having users as group, what you need to do is chgrp nogroup hehehe. – Valmiky Arquissandas Aug 24 '14 at 1:18
  • I guess that will solve the group problem for that folder. But it still dont explain why users is the group that it is created under, as hts's primary group is nogroup. And it will happen again once the hts user creates a new folder. And either way its strange that the user hts that created the folder is not able to open it. Sorry if im beeing unclear. – chriskvik Aug 24 '14 at 1:25
  • That should probably be configured in Samba, on the server side. I don't know whether the setgid bit works; you can try running chmod g+s and see if it creates the files with the correct group. Also, it looks like you have extended ACLs in your example; can you run getfacl hehehe? – Valmiky Arquissandas Aug 24 '14 at 1:32
  • # file: hehehe # owner: hts # group: users # flags: -s- user::rw- group::rwx group:nogroup:rwx mask::rwx other::r-x default:user::rw- default:group::rwx default:group:nogroup:rwx default:mask::rwx default:other::r-x – chriskvik Aug 24 '14 at 10:06
  • Please post information updates like the above by editing your question, rather than in comments. – G-Man Says 'Reinstate Monica' Aug 25 '14 at 1:29
0

Your question is all over the place:

  • Unable to set rw permissions on a folder
  • changing usergroups on user
  • The problem arises when the user tries to enter a folder created by himself, resulting in a “Permission Denied”.
  • Why is this folder not writable by the user creating it?

I don’t see where you’ve said anything to indicate that your problem has anything to do with write permissions.  I do see:

I then tried ls -al, which gives me the following:

drw-rwsr-x+ 2 hts users 4096 Aug 24 02:04 test1

and

getfacl hehehe

# file: hehehe
# owner: hts
# group: users
# flags: -s-
user::rw-                        
group::rwx
group:nogroup:rwx
mask::rwx
other::r-x
default:user::rw-
default:group::rwx
default:group:nogroup:rwx
default:mask::rwx
default:other::r-x

To access a directory in just about any way, you need to have “execute” (x) permission to it. The owner of the test1 and hehehe directories (which is hts) doesn’t have execute permission to the directories; it has only read & write (rw-) permissions. This will prevent hts from being able to cd into the directories, or access any files contained therein.

I don’t see anything in your question that would explain why this is happening, but, if all the other users are OK, we can assume that there’s something wrong with the hts user.  The “obvious” possibility is that his umask is set wrong; e.g., 102.  (Just type umask in the shell when logged in as hts.)  It should be something like 2 or 22 (i.e., 002 or 022).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.