[opensuse] cifs files always created as owner root
I mount this share on a client: [users] comment = home folders inherit acls = Yes path = /home read only = No using this: mount -t cifs //192.168.1.2/users /home -o rw,setuid I then login as a user on the client authenticated via ldap. No problem. It takes me to the mounted folder and I can see my files. When I create a file it creates it as owner root:root. Not what I want! How can I create files on the mount as user:group no matter who logs in? Thanks. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/11/2011 8:57 AM, lynn wrote:
I mount this share on a client:
[users] comment = home folders inherit acls = Yes path = /home read only = No
using this:
mount -t cifs //192.168.1.2/users /home -o rw,setuid
I then login as a user on the client authenticated via ldap. No problem. It takes me to the mounted folder and I can see my files. When I create a file it creates it as owner root:root. Not what I want!
How can I create files on the mount as user:group no matter who logs in? Thanks. L x
I fought this battle some years ago, and the problem, as best I can recall was that the normal cifs mount of a samba share would have the client trying to set permissions and uids. This only works when uids are matched among all workstations (the NFS mindset). I found it necessary to force the mount commands to not allow the local workstation to attempt to manage permissions and UIDs of files it creates on a server share. I believe the noperm and nosetuids parameters were the key to this, but that was at a site which I no longer manage, so I can't check on this for you. Man mount.cifs sees to suggest this is the approach needed to allow the samba server to manage permissions and ownership. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday 11 Oct 2011 21:47:18 John Andersen wrote:
On 10/11/2011 8:57 AM, lynn wrote:
I mount this share on a client:
[users]
comment = home folders inherit acls = Yes path = /home read only = No
using this:
mount -t cifs //192.168.1.2/users /home -o rw,setuid
I then login as a user on the client authenticated via ldap. No problem. It takes me to the mounted folder and I can see my files. When I create a file it creates it as owner root:root. Not what I want!
How can I create files on the mount as user:group no matter who logs in? Thanks. L x
I fought this battle some years ago, and the problem, as best I can recall was that the normal cifs mount of a samba share would have the client trying to set permissions and uids. This only works when uids are matched among all workstations (the NFS mindset).
I found it necessary to force the mount commands to not allow the local workstation to attempt to manage permissions and UIDs of files it creates on a server share.
I believe the noperm and nosetuids parameters were the key to this, but that was at a site which I no longer manage, so I can't check on this for you. Man mount.cifs sees to suggest this is the approach needed to allow the samba server to manage permissions and ownership.
Thanks. I tried mounting with the nosetuids and noperm but still I get root:root ownership. The thing is, the [homes] share ought to do this without me doing anything according to the stuff I've read. Anyway, will join the samba list and see what they say. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2011-10-11 at 17:57 +0200, lynn wrote:
I mount this share on a client:
[users] comment = home folders inherit acls = Yes path = /home read only = No
using this:
mount -t cifs //192.168.1.2/users /home -o rw,setuid
I then login as a user on the client authenticated via ldap. No problem. It takes me to the mounted folder and I can see my files. When I create a file it creates it as owner root:root. Not what I want!
How can I create files on the mount as user:group no matter who logs in? Thanks. L x
I don't like the solution, but I added this to the options when I mount CIFS volumes: uid=someLinuxUser This also means that all existing files on the CIFS volume will belong to someLinuxUser. At least they do not belong to root. I would really like each user's activity to belong to them. I have never gotten that to work. If you ever figure that out, please tell me. This is especially an issue with shares that are common to many users. Our CIFS volumes are from a MS server, not a SAMBA server. BTW, what do you mean by "It takes me to the mounted folder"? Who takes you there? Was it just mounted when you logged in? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 12 Oct 2011 07:59:10 Roger Oberholtzer wrote:
On Tue, 2011-10-11 at 17:57 +0200, lynn wrote:
I mount this share on a client:
[users]
comment = home folders inherit acls = Yes path = /home read only = No
using this:
mount -t cifs //192.168.1.2/users /home -o rw,setuid
I then login as a user on the client authenticated via ldap. No problem. It takes me to the mounted folder and I can see my files. When I create a file it creates it as owner root:root. Not what I want!
How can I create files on the mount as user:group no matter who logs in? Thanks. L x
I don't like the solution, but I added this to the options when I mount CIFS volumes:
uid=someLinuxUser
This also means that all existing files on the CIFS volume will belong to someLinuxUser.
At least they do not belong to root. I would really like each user's activity to belong to them. I have never gotten that to work. If you ever figure that out, please tell me. This is especially an issue with shares that are common to many users.
Our CIFS volumes are from a MS server, not a SAMBA server.
BTW, what do you mean by "It takes me to the mounted folder"? Who takes you there? Was it just mounted when you logged in?
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them. "It takes me to the mounted folder": T the login prompt it asks for the username and then prompts for a password for that user. Giving those two pieces of information and then, e.g. typing ls, gives me a list of files in the users folder. He has been placed in his own folder as if he were a local user. ldap and/or samba must have done that since there are no user accounts on the client. Still trying. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root? With no users defined, what possible other choice would there be. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2011-10-12 at 11:28 -0700, John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I suspect there are local users. I know that if an openSUSE box has joined an ActiveDirectory, you can have it so that when a person logs in with their ActiveDirectory credentials, an account and $HOME are automatically created if they do not already exist. Their $HOME is in /home/$WORKGROUP. It really works great. I know the original poster said they were authenticated with LDAP. Perhaps in that case this does not happen (automatically making a local account and $HOME). But unless all these folk run as root, there must be a local account. If the LDAP method did not set it up automatically, then someone had to do it by hand in advance. Indeed, I think we are not getting the complete picture. Lynn, what does a user get if they type: whoami and echo $HOME in a terminal window? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 13 Oct 2011 08:10:17 Roger Oberholtzer wrote:
On Wed, 2011-10-12 at 11:28 -0700, John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I suspect there are local users. I know that if an openSUSE box has joined an ActiveDirectory, you can have it so that when a person logs in with their ActiveDirectory credentials, an account and $HOME are automatically created if they do not already exist. Their $HOME is in /home/$WORKGROUP. It really works great.
I know the original poster said they were authenticated with LDAP. Perhaps in that case this does not happen (automatically making a local account and $HOME). But unless all these folk run as root, there must be a local account. If the LDAP method did not set it up automatically, then someone had to do it by hand in advance.
Indeed, I think we are not getting the complete picture.
Lynn, what does a user get if they type:
whoami
and
echo $HOME
in a terminal window?
There are no local users on the client. On the client, authenticated via ldap: whoami lynn echo $HOME /home/lynn I created lynn as an ldap user on the server using yast just taking the default values so I don't think this is an ldap problem. I think it's a samba/cifs problem as my current lan works fine using nfs/nis. Thanks for your patience. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2011-10-13 at 11:22 +0200, lynn wrote:
On Thursday 13 Oct 2011 08:10:17 Roger Oberholtzer wrote:
On Wed, 2011-10-12 at 11:28 -0700, John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I suspect there are local users. I know that if an openSUSE box has joined an ActiveDirectory, you can have it so that when a person logs in with their ActiveDirectory credentials, an account and $HOME are automatically created if they do not already exist. Their $HOME is in /home/$WORKGROUP. It really works great.
I know the original poster said they were authenticated with LDAP. Perhaps in that case this does not happen (automatically making a local account and $HOME). But unless all these folk run as root, there must be a local account. If the LDAP method did not set it up automatically, then someone had to do it by hand in advance.
Indeed, I think we are not getting the complete picture.
Lynn, what does a user get if they type:
whoami
and
echo $HOME
in a terminal window?
There are no local users on the client. On the client, authenticated via ldap:
whoami lynn
echo $HOME /home/lynn
I created lynn as an ldap user on the server using yast just taking the default values so I don't think this is an ldap problem. I think it's a samba/cifs problem as my current lan works fine using nfs/nis.
Just to be sure: The client is an openSUSE system? The server is a SAMBA system? There is no lynn entry in /etc/passwd? Wouldn't your mount command, which was: mount -t cifs //192.168.1.2/users /home -o rw,setuid mount all the users on the local system? It is the '/home' that I wonder about. Wouldn't it have to be '/home/lynn' if you were only mounting lynn's home with this command? What does 'mount' tell? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 13 Oct 2011 12:11:07 Roger Oberholtzer wrote:
On Thu, 2011-10-13 at 11:22 +0200, lynn wrote:
On Thursday 13 Oct 2011 08:10:17 Roger Oberholtzer wrote:
On Wed, 2011-10-12 at 11:28 -0700, John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I suspect there are local users. I know that if an openSUSE box has joined an ActiveDirectory, you can have it so that when a person logs in with their ActiveDirectory credentials, an account and $HOME are automatically created if they do not already exist. Their $HOME is in /home/$WORKGROUP. It really works great.
I know the original poster said they were authenticated with LDAP. Perhaps in that case this does not happen (automatically making a local account and $HOME). But unless all these folk run as root, there must be a local account. If the LDAP method did not set it up automatically, then someone had to do it by hand in advance.
Indeed, I think we are not getting the complete picture.
Lynn, what does a user get if they type: whoami
and
echo $HOME
in a terminal window?
There are no local users on the client. On the client, authenticated via ldap:
whoami lynn
echo $HOME /home/lynn
I created lynn as an ldap user on the server using yast just taking the default values so I don't think this is an ldap problem. I think it's a samba/cifs problem as my current lan works fine using nfs/nis.
Just to be sure:
The client is an openSUSE system?
Yes, 11.4
The server is a SAMBA system?
Yes, 11.4
There is no lynn entry in /etc/passwd?
No on neither client nor server.
Wouldn't your mount command, which was:
mount -t cifs //192.168.1.2/users /home -o rw,setuid
mount all the users on the local system? It is the '/home' that I wonder about. Wouldn't it have to be '/home/lynn' if you were only mounting lynn's home with this command?
yes. It does indeed mount all users on the local system. That's what I want. I want ALL my users to be able to login, not just lynn.
What does 'mount' tell?
Here is mount on the client: devtmpfs on /dev type devtmpfs (rw,relatime,size=242856k,nr_inodes=60714,mode=755) tmpfs on /dev/shm type tmpfs (rw,relatime) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) /dev/sda3 on / type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) /dev/sda1 on /boot type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered) //192.168.1.2/users/ on /home type cifs (rw,relatime,unc=\\192.168.1.2\users,username=root,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.2,posixpaths,serverino,acl,rsize=16384,wsize=57344,actimeo=1) Thanks for your time. Lx -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2011-10-13 at 12:56 +0200, lynn wrote:
On Thursday 13 Oct 2011 12:11:07 Roger Oberholtzer wrote:
On Thu, 2011-10-13 at 11:22 +0200, lynn wrote:
On Thursday 13 Oct 2011 08:10:17 Roger Oberholtzer wrote:
On Wed, 2011-10-12 at 11:28 -0700, John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I suspect there are local users. I know that if an openSUSE box has joined an ActiveDirectory, you can have it so that when a person logs in with their ActiveDirectory credentials, an account and $HOME are automatically created if they do not already exist. Their $HOME is in /home/$WORKGROUP. It really works great.
I know the original poster said they were authenticated with LDAP. Perhaps in that case this does not happen (automatically making a local account and $HOME). But unless all these folk run as root, there must be a local account. If the LDAP method did not set it up automatically, then someone had to do it by hand in advance.
Indeed, I think we are not getting the complete picture.
Lynn, what does a user get if they type: whoami
and
echo $HOME
in a terminal window?
There are no local users on the client. On the client, authenticated via ldap:
whoami lynn
echo $HOME /home/lynn
I created lynn as an ldap user on the server using yast just taking the default values so I don't think this is an ldap problem. I think it's a samba/cifs problem as my current lan works fine using nfs/nis.
Just to be sure:
The client is an openSUSE system?
Yes, 11.4
The server is a SAMBA system?
Yes, 11.4
There is no lynn entry in /etc/passwd?
No on neither client nor server.
Wouldn't your mount command, which was:
mount -t cifs //192.168.1.2/users /home -o rw,setuid
mount all the users on the local system? It is the '/home' that I wonder about. Wouldn't it have to be '/home/lynn' if you were only mounting lynn's home with this command?
yes. It does indeed mount all users on the local system. That's what I want. I want ALL my users to be able to login, not just lynn.
I suspect that is the problem. If each user's directory is mounted for that user, then Linux can give that mount point permissions. I think that is because CIFS does not have true per-file permissions. At least it does not appear they are used (if they exist at all) by the Linux CIFS file system. There is only the permissions for the while mount point. In your mount, I see that you have uid=0. There you have it. Linux will make all files appear to belong to root. This is at the mount level. I doubt some other layer can change that. I think that you will need to have each user's directory mounted for that user, not a common mount for all. I think it will also be a requirement that the user has a Linux uid/gid, as that is what controls the permissions and would be needed by mount. I don't know what LDAP is doing in this respect. Since the whole shebange is mounted once, and the client and server are Linux, why CIFS? Why not a file system that has a concept of per-file ownership? This business of mounting CIFS stores automatically at login and with correct permissions is something I have not sorted out either. I 'only' have the ActiveDirectory user/password and automatic account stuff working. If the user does not exist, is LDAP assigning some sort of permanent uid/gid to each account? Meaning that if you get a uid/gid one time, would you get the same one the next time? What is printed in the UID column for this command (change lynn the current user): ps -lnU lynn If you change the uid= in your mount command to that, the files will belong to lynn. And only lynn... Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 13 Oct 2011 14:50:18 Roger Oberholtzer wrote:
On Thu, 2011-10-13 at 12:56 +0200, lynn wrote:
On Thursday 13 Oct 2011 12:11:07 Roger Oberholtzer wrote:
On Thu, 2011-10-13 at 11:22 +0200, lynn wrote:
On Thursday 13 Oct 2011 08:10:17 Roger Oberholtzer wrote:
On Wed, 2011-10-12 at 11:28 -0700, John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote: > Hi. Thanks. As you say, 'somelinuxuser' is better than root but > my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I suspect there are local users. I know that if an openSUSE box has joined an ActiveDirectory, you can have it so that when a person logs in with their ActiveDirectory credentials, an account and $HOME are automatically created if they do not already exist. Their $HOME is in /home/$WORKGROUP. It really works great.
I know the original poster said they were authenticated with LDAP. Perhaps in that case this does not happen (automatically making a local account and $HOME). But unless all these folk run as root, there must be a local account. If the LDAP method did not set it up automatically, then someone had to do it by hand in advance.
Indeed, I think we are not getting the complete picture.
Lynn, what does a user get if they type: whoami
and
echo $HOME
in a terminal window?
There are no local users on the client. On the client, authenticated via ldap:
whoami lynn
echo $HOME /home/lynn
I created lynn as an ldap user on the server using yast just taking the default values so I don't think this is an ldap problem. I think it's a samba/cifs problem as my current lan works fine using nfs/nis.
Just to be sure:
The client is an openSUSE system?
Yes, 11.4
The server is a SAMBA system?
Yes, 11.4
There is no lynn entry in /etc/passwd?
No on neither client nor server.
Wouldn't your mount command, which was: mount -t cifs //192.168.1.2/users /home -o rw,setuid
mount all the users on the local system? It is the '/home' that I wonder about. Wouldn't it have to be '/home/lynn' if you were only mounting lynn's home with this command?
yes. It does indeed mount all users on the local system. That's what I want. I want ALL my users to be able to login, not just lynn.
I suspect that is the problem. If each user's directory is mounted for that user, then Linux can give that mount point permissions. I think that is because CIFS does not have true per-file permissions. At least it does not appear they are used (if they exist at all) by the Linux CIFS file system. There is only the permissions for the while mount point.
In your mount, I see that you have uid=0. There you have it. Linux will make all files appear to belong to root. This is at the mount level. I doubt some other layer can change that.
I think that you will need to have each user's directory mounted for that user, not a common mount for all. I think it will also be a requirement that the user has a Linux uid/gid, as that is what controls the permissions and would be needed by mount. I don't know what LDAP is doing in this respect.
Since the whole shebange is mounted once, and the client and server are Linux, why CIFS? Why not a file system that has a concept of per-file ownership?
You mean like NFS? I have a 20 user lan with only ubuntu and opensuse boxes. NFS mounts /home from the server on /home on the clients. File permissions are taken care of automagically. NFS allows user:group ownership to be whatever it was on the server. CIFS it seems, will only allow for a single user: either the one who mounted the share or specified in uid and gid. I've managed to get rid of NIS and can now use LDAP for authentication. Soon we will have 10 more client boxes which will be dual boot win7/linux for new users who have to use excel and word. My server is an old amd sempron with only 2GB memory. Running samba and NFS seems to slow down the lan so I guessed that if I could remove nfs and just have cifs that would ease the load on the server. But it seems that I can't. .lnU >
This business of mounting CIFS stores automatically at login and with correct permissions is something I have not sorted out either. I 'only' have the ActiveDirectory user/password and automatic account stuf If the user does not exist, is LDAP assigning some sort of permanent uid/gid to each account? Meaning that if you get a uid/gid one time, would you get the same one the next time?
What is printed in the UID column for this command (change lynn the current user):
ps -lnU lynn
UID is 0 It's root, the user who mounted the share.
If you change the uid= in your mount command to that, the files will belong to lynn. And only lynn...
Yes, you can do that. But then everyone else who logs in apart from lynn also has their new files created as lynn. I've not given up yet. I suppose buying a proper server with more memory would do the trick. Or training new users how to use libreoffice. Yeah. I know what you're thinking. Same here! Thanks for all your time you've spent. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2011-10-13 at 16:31 +0200, lynn wrote:
What is printed in the UID column for this command (change lynn the current user):
ps -lnU lynn
UID is 0
It's root, the user who mounted the share.
User lynn has a uid of 0? Something sounds wrong. lynn is, effectively, root. That does not sound right at all. lynn is logged in on a client, and was validated via ldap?
Thanks for all your time you've spent.
I too am after mounting CIFS (automatically on login) and having users get their own permissions. Our company provides CIFS directories where we put lots of analysis data. The analysis machines run Linux. Managing permissions when two different users are logged in to the Linux machine at the same time, and who need their own permissions on these CIFS volumes has been a headache. They may share a CIFS volume. So, I too am looking for a solution in this area. I think YaST has done an excellent job of managing setting up joining an Active Directory. From what you have said it has done similar work for LDAP. I think the next step must be to help manage access to CIFS volumes in the way we are trying. I suspect part of the problem is CIFS itself. But I have a feeling there are capabilities that escape us that would help this to work better. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I think YaST has done an excellent job of managing setting up joining an Active Directory. From what you have said it has done similar work for LDAP. I think the next step must be to help manage access to CIFS volumes in the way we are trying. I suspect part of the problem is CIFS itself. But I have a feeling there are capabilities that escape us that would help this to work better.
I agree about yast. It is likely to make many a sysadmin redundant as it even allows people like me to setup ldap;) I tried to setup LDAP on ubuntu but it was a nightmare. Even with the ubuntu server step by step guide the learning curve was too steep for me. With yast it takes 5 minutes on the server and 5 minutes on the client. Then another 5 minutes to figure out how to make samba use ldap without having to use the silly samba passwords. But, as you say, it's not quite there yet as far as cifs goes. I'm sure it will be soon. Meanwhile I'm running nfs and samba. Thanks for replying. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lynn, what does a user get if they type:
whoami
and
echo $HOME
in a terminal window?
Hi. Some more info: /etc/samba/smb.conf users share on the server [users] comment = home folders inherit acls = Yes inherit permissions = Yes path = /home read only = No mount command on client logged in as root: mount -t cifs //192.168.1.2/users -o rw, gid=users,nosetuid using this command sets the group OK but the user remains as root. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/13/2011 05:34 AM, lynn pecked at the keyboard and wrote:
Lynn, what does a user get if they type:
whoami
and
echo $HOME
in a terminal window?
Hi.
Some more info:
/etc/samba/smb.conf users share on the server
[users] comment = home folders inherit acls = Yes inherit permissions = Yes path = /home read only = No
mount command on client logged in as root:
mount -t cifs //192.168.1.2/users -o rw, gid=users,nosetuid
using this command sets the group OK but the user remains as root.
L x
From man mount.cifs: setuids If the CIFS Unix extensions are negotiated with the server the client will attempt to set the effective uid and gid of the local process on newly created files, directories, and devices (create, mkdir, mknod). If the CIFS Unix Extensions are not negotiated, for newly created files and directories instead of using the default uid and gid specified on the the mount, cache the new file´s uid and gid locally which means that the uid for the file can change when the inode is reloaded (or the user remounts the share). nosetuids The client will not attempt to set the uid and gid on on newly created files, directories, and devices (create, mkdir, mknod) which will result in the server setting the uid and gid to the default (usually the server uid of the user who mounted the share). Letting the server (rather than the client) set the uid and gid is the default.If the CIFS Unix Extensions are not negotiated then the uid and gid for new files will appear to be the uid (gid) of the mounter or the uid (gid) parameter specified on the mount. Perhaps you have the wrong option set. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 13 Oct 2011 14:41:27 Ken Schneider - openSUSE wrote:
On 10/13/2011 05:34 AM, lynn pecked at the keyboard and wrote:
Lynn, what does a user get if they type: whoami
and
echo $HOME
in a terminal window?
Hi.
Some more info:
/etc/samba/smb.conf users share on the server
[users] comment = home folders
inherit acls = Yes inherit permissions = Yes path = /home read only = No
mount command on client logged in as root:
mount -t cifs //192.168.1.2/users -o rw, gid=users,nosetuid
using this command sets the group OK but the user remains as root.
L x
From man mount.cifs:
setuids If the CIFS Unix extensions are negotiated with the server the client will attempt to set the effective uid and gid of the local process on newly created files, directories, and devices (create, mkdir, mknod). If the CIFS Unix Extensions are not negotiated, for newly created files and directories instead of using the default uid and gid specified on the the mount, cache the new file´s uid and gid locally which means that the uid for the file can change when the inode is reloaded (or the user remounts the share).
nosetuids The client will not attempt to set the uid and gid on on newly created files, directories, and devices (create, mkdir, mknod) which will result in the server setting the uid and gid to the default (usually the server uid of the user who mounted the share). Letting the server (rather than the client) set the uid and gid is the default.If the CIFS Unix Extensions are not negotiated then the uid and gid for new files will appear to be the uid (gid) of the mounter or the uid (gid) parameter specified on the mount.
Perhaps you have the wrong option set.
Thanks, But I've tried both. It doesn't make any difference which is specified or if neither is specified. (btw: I'm sure the grammar and or punctuation is wrong for the setuids entry in the man pages. It really is misleading!) L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 12 Oct 2011 20:28:13 John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I want any user to be able to log in on any client on my lan and see and create their own files using their own permissions no matter which client box they sit at. That's one of the good points in having a server isn't it? Everything is centralised. Lan users are defined only on the server. With nfs and nis this just works: nfs mounts /home from the server as /home on the client. They authenticate using nis and all files they create are owened user:group as defined on the server. It's as if they were using the client box as a local user. It's an option you have for installing a client during the yast setup. What I thought was that I could replace nfs with cifs and nis with ldap. Ldap is working (Thank gad for yast. Don't try installing it without!). My only problem in implementing the change is the cifs user:group issue. So, any ideas anyone? What options do I need on the cifs mount to allow file creation as user:group? This has so far drawn a blank on the samba list too so I'm thinking that maybe it's not possible. But surely. . . Saludos Cheers, Lynn x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/13/2011 2:04 AM, lynn wrote:
On Wednesday 12 Oct 2011 20:28:13 John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I want any user to be able to log in on any client on my lan and see and create their own files using their own permissions no matter which client box they sit at. That's one of the good points in having a server isn't it? Everything is centralised.
Lan users are defined only on the server. With nfs and nis this just works: nfs mounts /home from the server as /home on the client. They authenticate using nis and all files they create are owened user:group as defined on the server. It's as if they were using the client box as a local user. It's an option you have for installing a client during the yast setup.
What I thought was that I could replace nfs with cifs and nis with ldap. Ldap is working (Thank gad for yast. Don't try installing it without!). My only problem in implementing the change is the cifs user:group issue.
Well this is exactly what we were doing under SLES, which used LDAP as well. Several Linux boxes logged in and their Samba home directories as well as some shared data directories were mounted by the users.*** We found that files created by these users were owned by root or some random user when we allowed the local machine to attempt to set uid/gid. (The difference between our environments was that these users had their own linux machines, or shared specific machines rather than migrating around from machine to machine so it is not exactly the environment you are dealing with). Ken quoted the man page above. Its a bit of a mess, but the first sentence in each of the two paragraphs makes sense by itself. The following sentences... not so much. It was exactly these settings that I mentioned earlier, but again I'm working from memory, and that site is a couple states away from me now. The key was to disallow the local machine from setting uid/gid on the server, and allow samba to do this via the rules in the smb.conf. We always set the smb.conf to force some things: [datashares] comment = Company Files path = /raid/....... force group = +datashare read only = No create mask = 0660 force create mode = 0660 security mask = 0770 directory mask = 0770 force directory mode = 0770 directory security mask = 0770 *** I seem to remember we created fstab entries for these files in the local machines, but set it noauto,user. And we waited to mount them until AFTER the user logged in so that samba knew who the user was. Sorry I can't be more specific, memory, like light, falls off as the square of age. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2011-10-13 at 18:07 -0700, John Andersen wrote:
The key was to disallow the local machine from setting uid/gid on the server, and allow samba to do this via the rules in the smb.conf.
We always set the smb.conf to force some things: [datashares] comment = Company Files path = /raid/....... force group = +datashare read only = No create mask = 0660 force create mode = 0660 security mask = 0770 directory mask = 0770 force directory mode = 0770 directory security mask = 0770
It seems that you have sort of focused on group permissions rather than user permissions. I suspect that this is the only approach for CIFS. Then, all users that should share a volume are a member of that volume's group. You could, I guess, have a group for each share. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/13/2011 11:42 PM, Roger Oberholtzer wrote:
On Thu, 2011-10-13 at 18:07 -0700, John Andersen wrote:
The key was to disallow the local machine from setting uid/gid on the server, and allow samba to do this via the rules in the smb.conf.
We always set the smb.conf to force some things: [datashares] comment = Company Files path = /raid/....... force group = +datashare read only = No create mask = 0660 force create mode = 0660 security mask = 0770 directory mask = 0770 force directory mode = 0770 directory security mask = 0770
It seems that you have sort of focused on group permissions rather than user permissions. I suspect that this is the only approach for CIFS. Then, all users that should share a volume are a member of that volume's group. You could, I guess, have a group for each share.
Exactly right Roger. We had to do that because we had a mix of Windows and Linux machines on the network, and folks had to share documents in a common directory. We wanted to maintain owner (creater) info, but still allow full group access (read/write, etc). For the user's server based Home directory we used different permissions of course. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 14 Oct 2011 19:18:26 John Andersen wrote:
On 10/13/2011 11:42 PM, Roger Oberholtzer wrote:
On Thu, 2011-10-13 at 18:07 -0700, John Andersen wrote:
The key was to disallow the local machine from setting uid/gid on the server, and allow samba to do this via the rules in the smb.conf.
We always set the smb.conf to force some things: [datashares]
comment = Company Files path = /raid/....... force group = +datashare read only = No create mask = 0660 force create mode = 0660 security mask = 0770 directory mask = 0770 force directory mode = 0770 directory security mask = 0770
It seems that you have sort of focused on group permissions rather than user permissions. I suspect that this is the only approach for CIFS. Then, all users that should share a volume are a member of that volume's group. You could, I guess, have a group for each share.
Exactly right Roger.
We had to do that because we had a mix of Windows and Linux machines on the network, and folks had to share documents in a common directory. We wanted to maintain owner (creater) info, but still allow full group access (read/write, etc).
For the user's server based Home directory we used different permissions of course.
The fact still remains that CIFS does not know what the the user:group permissions are of the user who has just authenticated. What is clear is that new files will be created with either: 1. The uid of the user who mounts the share. Or, 2. The uid and gid specified on the mount line. What I need is this: mount -t cifs //hh1.com/users /home -o rw,user,uid=$USER,gid=users but of course $USER is only available after the user has authenticated. Is there a script that runs immediately after the user has authenticated where I could place this line? Thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday 15 Oct 2011 09:53:05 lynn wrote:
On Friday 14 Oct 2011 19:18:26 John Andersen wrote:
On 10/13/2011 11:42 PM, Roger Oberholtzer wrote:
On Thu, 2011-10-13 at 18:07 -0700, John Andersen wrote:
The key was to disallow the local machine from setting uid/gid on the server, and allow samba to do this via the rules in the smb.conf.
We always set the smb.conf to force some things: [datashares]
comment = Company Files path = /raid/....... force group = +datashare read only = No create mask = 0660 force create mode = 0660 security mask = 0770 directory mask = 0770 force directory mode = 0770 directory security mask = 0770
It seems that you have sort of focused on group permissions rather than user permissions. I suspect that this is the only approach for CIFS. Then, all users that should share a volume are a member of that volume's group. You could, I guess, have a group for each share.
Exactly right Roger.
We had to do that because we had a mix of Windows and Linux machines on the network, and folks had to share documents in a common directory. We wanted to maintain owner (creater) info, but still allow full group access (read/write, etc).
For the user's server based Home directory we used different permissions of course.
The fact still remains that CIFS does not know what the the user:group permissions are of the user who has just authenticated. What is clear is that new files will be created with either:
1. The uid of the user who mounts the share. Or, 2. The uid and gid specified on the mount line.
What I need is this:
mount -t cifs //hh1.com/users /home -o rw,user,uid=$USER,gid=users
but of course $USER is only available after the user has authenticated. Is there a script that runs immediately after the user has authenticated where I could place this line?
Thanks.
Duh. Sorry. I would also need an environment variable for password=. Can's see how to set that although google tells me that it is available somewhere. x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
The Samba list gurus have: Confirmed as impossible to do what I want via CIFS. Confirmed that NFS will do what I want. I'll have to run both Samba and NFS on the server. I'll start another thread to ask for help with performance issues I have with this. Saludos y que tengan Vds.un buen finde... L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lynn said the following on 10/15/2011 03:17 PM:
I'll have to run both Samba and NFS on the server. I'll start another thread to ask for help with performance issues I have with this.
I do. On an old Dell single core with 512M of memory which also runs my DNS, DHCP and backup, and never seems to get a load factor over 1.5. Stuffing packets down a network is not a big job; back in the late 90s we had routers handing multiple T1s with filtering using the old '386 chips of that era; I ran an ISP with a rack of Telebit doing that; better price performance than Ciscos back then! In fact a 'headless server' can perform quite well; UNIX grew up on processors a lot less capable than we have today (think of PDP-11s) running text mode, doing things like text editing and formatting. A PDP-11/45 + 4M memory with a couple of 10M drives could support a legal department at Bell labs say 40 concurrent users. -- Opportunity is missed by most people because it is dressed in overalls and looks like work. Thomas A. Edison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 16 Oct 2011 15:40:56 Anton Aylward wrote:
Lynn said the following on 10/15/2011 03:17 PM:
I'll have to run both Samba and NFS on the server. I'll start another thread to ask for help with performance issues I have with this.
I do. On an old Dell single core with 512M of memory which also runs my DNS, DHCP and backup, and never seems to get a load factor over 1.5.
Stuffing packets down a network is not a big job; back in the late 90s we had routers handing multiple T1s with filtering using the old '386 chips of that era; I ran an ISP with a rack of Telebit doing that; better price performance than Ciscos back then!
In fact a 'headless server' can perform quite well; UNIX grew up on processors a lot less capable than we have today (think of PDP-11s) running text mode, doing things like text editing and formatting. A PDP-11/45 + 4M memory with a couple of 10M drives could support a legal department at Bell labs say 40 concurrent users.
Thanks. There may be hope yet: My server is an old amd 64bit with a 500G disk and 2Gb memory. It serves 20 opensuse and ubuntu clients. There is nothing state of the art about it. There are second hand daisy chained switches and 10 year old dell boxes as clients. My backup is 2 70 Euro each 1000Gb usb drives and I use Dropbox to save /etc from the server just in case. There is nothing on the clients apart from the operating system. I've just switched from NIS:NFS to LDAP:NFS-CIFS. There are hundreds of LDAP searches occuring every minute which is what may be slowing things down. Must get that fixed first. Any ideas most welcome. THanks L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 2011-10-15 at 10:13 +0200, lynn wrote:
Duh. Sorry. I would also need an environment variable for password=. Can's see how to set that although google tells me that it is available somewhere.
I use a permissions file. That way passwords do not show up in mount listings. I would imagine that automount must deal with per-user things like passwords. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 2011-10-15 at 09:53 +0200, lynn wrote:
The fact still remains that CIFS does not know what the the user:group permissions are of the user who has just authenticated. What is clear is that new files will be created with either:
1. The uid of the user who mounts the share. Or, 2. The uid and gid specified on the mount line.
What I need is this:
mount -t cifs //hh1.com/users /home -o rw,user,uid=$USER,gid=users
but of course $USER is only available after the user has authenticated. Is there a script that runs immediately after the user has authenticated where I could place this line?
You can only mount the remote once. So it could never have different uid= settings for each user at the same time. Maybe that is not what you need. On any client machine there will be only one user at a time? I think automount deals with this sort of thing. It is on my list to figure that out. But it seems to manage dynamically mounting disks based on user logins, and probably other events as well. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 14 Oct 2011 03:07:35 John Andersen wrote:
On 10/13/2011 2:04 AM, lynn wrote:
On Wednesday 12 Oct 2011 20:28:13 John Andersen wrote:
On 10/11/2011 11:59 PM, lynn wrote:
Hi. Thanks. As you say, 'somelinuxuser' is better than root but my client boxes do not have any users on them.
Huh? That makes no sense at all. How can you have no users defined on a client box and at the same time complain that things are mounted root:root?
With no users defined, what possible other choice would there be.
I want any user to be able to log in on any client on my lan and see and create their own files using their own permissions no matter which client box they sit at. That's one of the good points in having a server isn't it? Everything is centralised.
Lan users are defined only on the server. With nfs and nis this just works: nfs mounts /home from the server as /home on the client. They authenticate using nis and all files they create are owened user:group as defined on the server. It's as if they were using the client box as a local user. It's an option you have for installing a client during the yast setup.
What I thought was that I could replace nfs with cifs and nis with ldap. Ldap is working (Thank gad for yast. Don't try installing it without!). My only problem in implementing the change is the cifs user:group issue.
Well this is exactly what we were doing under SLES, which used LDAP as well.
(The difference between our environments was that these users had their own linux machines, or shared specific machines rather than migrating around from machine to machine so it is not exactly the environment you are dealing with).
Exactly. This is where the difference is. If I could insist that a person always used the same client box then I could setup the cifs shares no problem by setting the uid and gid to that of the person in the cifs mount in fstab. In my case I can't. A person has to be able to use any client.
[datashares] comment = Company Files path = /raid/....... force group = +datashare read only = No create mask = 0660 force create mode = 0660 security mask = 0770 directory mask = 0770 force directory mode = 0770 directory security mask = 0770
*** I seem to remember we created fstab entries for these files in the local machines, but set it noauto,user. And we waited to mount them until AFTER the user logged in so that samba knew who the user was.
Sorry I can't be more specific, memory, like light, falls off as the square of age.
At the moment I don't think it can be done. cifs cannot be made into a replacement for nfs. I will have to run both samba and nfs on my server. I wonder if anyone else here is doing that? Thanks for replying. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Anton Aylward -
John Andersen -
Ken Schneider - openSUSE -
lynn -
Roger Oberholtzer