SuSE 8.2 samba mount no permissions when in fstab
Hi, I upgraded my SuSE 8.1 box to SuSE 8.2 over the weekend. The box has a samba mount that must be permanently up. The entry is in fstab en worked fine since SuSE 8.0 on the box. Now, the share in mounted, but I don't have any write permissions. When I do the mount from the command line with the exact options that is in fstab (copy and pasted them), it works correct, but when I let mount do it using the fstab entry, I have no write permissions. It is not practical to manually mount the share, as the share is used for backups, and the system need to mount the share automatically on boot. I have seen a similar post, in the archives, but no solution yet. Does anybody have a solution? Thanks -- Andre Truter Software Engineer Registered Linux user #185282 ICQ #40935899 AIM: trusoftzaf http://www.trusoft.za.net <-------------------------------------------------> < The box said: Requires Windows 95 or better... > < So I installed Linux > <-------------------------------------------------> Disclaimer and Confidentiality Warning This message is intended for the addressee only. If you are not the intended recipient of this message, you are notified that any distribution, use of or copying of this communication is strictly prohibited. If you have received the communication in error, please notify the sender immediately. The views and opinions expressed in this message are those of the individual sender of this message and do not necessarily represent the views and opinions of ATIO. Consequently, ATIO does not accept responsibility for such views and opinions and this message should not be read as representing the views and opinions of ATIO without subsequent written confirmation. Each page attached hereto must also be read in conjunction with this disclaimer.
<snip>
Now, the share in mounted, but I don't have any write permissions. When I do the mount from the command line with the exact options that is in fstab (copy and pasted them), it works correct, but when I let mount do it using the fstab entry, I have no write permissions.
It is not practical to manually mount the share, as the share is used for backups, and the system need to mount the share automatically on boot.
I have seen a similar post, in the archives, but no solution yet.
Does anybody have a solution?
Thanks
I have the same issue. I *think* it comes from root mounting the share upon boot. Like you, if I mount the share (as user), then it works as expected. I haven't tried having the system run a script upon login to mount the share. But it might be worth a try. I wish I knew what file I would have to modify for the on-boot method to work correctly. Maybe others on this list are more knowledgeable about such things. -- Marshall "Nothing is impossible, we just do not have all the anwsers to make the impossible, possible."
On Wed, 2003-06-25 at 13:06, Marshall Heartley wrote: --<snip>--
I have the same issue. I *think* it comes from root mounting the share upon boot. Like you, if I mount the share (as user), then it works as expected. I haven't tried having the system run a script upon login to mount the share. But it might be worth a try. I wish I knew what file I would have to modify for the on-boot method to work correctly. Maybe others on this list are more knowledgeable about such things.
I don't think root is the problem, as I mounted it manually as root and root also don't have write access when it is mounted from fstab. I have also thought of writing an init script to do the mounting, if all else fails. You basically only need to create a script that contain the smbmount command as you would enter it on command line. Then you place the script in /etc/init.d and use the runlevel editor to assign the script to runlevel 2,3,5. (I think those runlevels should be fine) You should actually add the integration for 'start', 'stop' and 'restart' also. I will write a script later on when I have time, as I must still see what rc functions SuSE use and how they work. But I would prefer to have it work the correct way - with fstab. -- Andre Truter Software Engineer Registered Linux user #185282 ICQ #40935899 AIM: trusoftzaf http://www.trusoft.za.net <-------------------------------------------------> < The box said: Requires Windows 95 or better... > < So I installed Linux > <-------------------------------------------------> Disclaimer and Confidentiality Warning This message is intended for the addressee only. If you are not the intended recipient of this message, you are notified that any distribution, use of or copying of this communication is strictly prohibited. If you have received the communication in error, please notify the sender immediately. The views and opinions expressed in this message are those of the individual sender of this message and do not necessarily represent the views and opinions of ATIO. Consequently, ATIO does not accept responsibility for such views and opinions and this message should not be read as representing the views and opinions of ATIO without subsequent written confirmation. Each page attached hereto must also be read in conjunction with this disclaimer.
I don't think root is the problem, as I mounted it manually as root and
root also don't have write access when it is mounted from fstab.
I still believe that root is the source of the issue. To the best of my knowledge, when the system is brought up, root will mount the necessary partitions that are in the fstab. Try this. Unmount the share that you want to have mounted. Su to root and remount it. If you had rw before, you don't have it now even if you specified it at mount time. So there is something about having root mount that share that is causing it. Now if you did not get the same results, then it might have been an issue on the two machines that I use here at the house. Here is what I get when I mount a share on my server to a mount point on my machine. As user my mount point directory has the following permissions. drwxr-xr-x with marshall as the owner and users as the group. Now as root mounting it. drwxr-xr-x with root being both owner and group. Here is where the permissions have changed. Now you do not have w permission anymore even though you logged into the share with the proper credentials!
I have also thought of writing an init script to do the mounting, if all else fails.
You basically only need to create a script that contain the smbmount command as you would enter it on command line. Then you place the script in /etc/init.d and use the runlevel editor to assign the script to runlevel 2,3,5. (I think those runlevels should be fine)
You should actually add the integration for 'start', 'stop' and 'restart' also. I will write a script later on when I have time, as I must still see what rc functions SuSE use and how they work.
But I would prefer to have it work the correct way - with fstab.
So would I. Could you see if you get the same results as me so I will know if it is my machines please? I have been trying to fight this silly issue for a while.
On Wed, 2003-06-25 at 14:28, Marshall Heartley wrote:
I don't think root is the problem, as I mounted it manually as root and
root also don't have write access when it is mounted from fstab.
I still believe that root is the source of the issue. To the best of my knowledge, when the system is brought up, root will mount the necessary partitions that are in the fstab. Try this. Unmount the share that you want to have mounted. Su to root and remount it. If you had rw before, you don't have it now even if you specified it at mount time.
No, this is not true in my case. The options of the smbmount command set the permissions with fmask, dmask and gid,uid options. In my case the mount only needs to be used by root, so it is mounted by root, but root still don't have write permissions if it is mounted with the fstab settings
So there is something about having root mount that share that is causing it. Now if you did not get the same results, then it might have been an issue on the two machines that I use here at the house.
Here is what I get when I mount a share on my server to a mount point on my machine.
As user my mount point directory has the following permissions. drwxr-xr-x with marshall as the owner and users as the group. Now as root mounting it. drwxr-xr-x with root being both owner and group. Here is where the permissions have changed. Now you do not have w permission anymore even though you logged into the share with the proper credentials!
In my case the mounted directory's permissions do not change when mounting/unmounting. --<snip>--
So would I. Could you see if you get the same results as me so I will know if it is my machines please? I have been trying to fight this silly issue for a while.
Your problem might be due to something else. Try adding the 'users' option in the fstab entry, also try gid=<your group id>,uid=<your user id>. My entry in fstab is: //ccprodb/Andre /remote/backups smbfs rw,username=<xxxx>,fmask=644,dmask=755,uid=0,gid=0,ip=<xxx>,debug=0,workgroup=<xxx> 0 0 So, I force the user and group settings to root, but due to the dmask and fmask settings, other users also have permissions. HTH -- Andre Truter Software Engineer Registered Linux user #185282 ICQ #40935899 AIM: trusoftzaf http://www.trusoft.za.net <-------------------------------------------------> < The box said: Requires Windows 95 or better... > < So I installed Linux > <-------------------------------------------------> Disclaimer and Confidentiality Warning This message is intended for the addressee only. If you are not the intended recipient of this message, you are notified that any distribution, use of or copying of this communication is strictly prohibited. If you have received the communication in error, please notify the sender immediately. The views and opinions expressed in this message are those of the individual sender of this message and do not necessarily represent the views and opinions of ATIO. Consequently, ATIO does not accept responsibility for such views and opinions and this message should not be read as representing the views and opinions of ATIO without subsequent written confirmation. Each page attached hereto must also be read in conjunction with this disclaimer.
<snip>
No, this is not true in my case. The options of the smbmount command set the permissions with fmask, dmask and gid,uid options. In my case the mount only needs to be used by root, so it is mounted by root, but root still don't have write permissions if it is mounted with the fstab settings
That throws a monkey wrench into things. Sorry I must not have picked up on you using the settings as stated above. <snip>
As user my mount point directory has the following permissions. drwxr-xr-x with marshall as the owner and users as the group. Now as root mounting it. drwxr-xr-x with root being both owner and group. Here is where the permissions have changed. Now you do not have w permission anymore even though you logged into the share with the proper credentials!
In my case the mounted directory's permissions do not change when mounting/unmounting.
Understandable.
--<snip>--
So would I. Could you see if you get the same results as me so I will know if it is my machines please? I have been trying to fight this silly issue for a while.
Your problem might be due to something else. Try adding the 'users' option in the fstab entry, also try gid=<your group id>,uid=<your user id>.
My entry in fstab is: //ccprodb/Andre /remote/backups smbfs rw,username=<xxxx>,fmask=644,dmask=755,uid=0,gid=0,ip=<xxx>,debug=0,workgroup=<xxx> 0 0
So, I force the user and group settings to root, but due to the dmask and fmask settings, other users also have permissions.
HTH
Well it might be because I gave users on the system the ability to mount the Samba share by setting the SUID bit. I know that this is not secure but I am the only one using the machine. In my instance, I was mounting from the console. There is no entry in the fstab. Well I will quiet down now. Looks like my theory was shot down :( Oh well. Thanks for the tip on the masks, I will file that one away for future reference. Sorry that I was not any help :( -- Marshall "Nothing is impossible, we just do not have all the anwsers to make the impossible, possible."
On Wed, 2003-06-25 at 15:17, Marshall Heartley wrote: --<snip>--
Well it might be because I gave users on the system the ability to mount the Samba share by setting the SUID bit. I know that this is not secure but I am the only one using the machine. In my instance, I was mounting from the console. There is no entry in the fstab. Well I will quiet down now. Looks like my theory was shot down :( Oh well. Thanks for the tip on the masks, I will file that one away for future reference.
I also have smbmount SUID, so that I can use LinNeighbourhood for non-permanent Samba mounts. This works fine for me. It seems that there is only a problem if the mount is done at boot from fstab. My version of samba-client (if it helps): samba-client-2.2.7a-72
Sorry that I was not any help :(
No, don't feel sorry. Every response helps, as it might spark off thoughts in other people and it get me to think about other options that I would not have thought. Thanks -- Andre Truter Software Engineer Registered Linux user #185282 ICQ #40935899 AIM: trusoftzaf http://www.trusoft.za.net <-------------------------------------------------> < The box said: Requires Windows 95 or better... > < So I installed Linux > <-------------------------------------------------> Disclaimer and Confidentiality Warning This message is intended for the addressee only. If you are not the intended recipient of this message, you are notified that any distribution, use of or copying of this communication is strictly prohibited. If you have received the communication in error, please notify the sender immediately. The views and opinions expressed in this message are those of the individual sender of this message and do not necessarily represent the views and opinions of ATIO. Consequently, ATIO does not accept responsibility for such views and opinions and this message should not be read as representing the views and opinions of ATIO without subsequent written confirmation. Each page attached hereto must also be read in conjunction with this disclaimer.
participants (2)
-
Andre Truter
-
Marshall Heartley