Mounting Samba Share

I have mounted a remote Samba share using the following fstab entry:

//Server/Transfer /srv/Transfer/ smbfs credentials=/etc/samba/credentials/Transfer 0 0

Now every time the Server re-boots the mounted share has to be re-mounted afterwards. Is there a way to keep this resistent?

Best Regards
Marcus

Perhaps it’ll work by adding it to /etc/samba/smbfstab and issue chkconfig smbfs on**

Note the slightly different layout.**

Hello
I tried wat Chrysantine suggests, let me know if it works – I couldn’t kmake it work.
For fstab you use cifs instead of smbfs in openSUSE. Check the syntax here:
Samba: HowTo Mount a CIFS Network Share [AKA Map Network Drive] in openSUSE 10.2, 10.3

Swerdna is right on the money here - I didn’t notice it myself either - smbfs is deprecated and you should use cifs.

/slap self.

Yes, use cifs instead of smbfs - there are some funny bugs with smbfs.

Also, for cifs, your credentials file should have:

username=putyourusernamehere
password=putyourpasswordhere

Make sure there is a newline at the end of your password.

To have the share mount upon startup every time, make sure the system service smbfs is enabled for runlevels 3 and 5.

g

Just to be clear here, with respect, so others don’t get confused: Smbfs isn’t an option in openSUSE which comes with the more modern implementation of smbfs called cifs.

smbfs IS an option for openSUSE, you just have to re-compile the kernel and turn it on.

To the thread starter, smbfs was depreciated in openSUSE (and I believe most other distributions will follow, or have followed) because of security issues. However, there is the default option and direct replacement called cifs.

so do:

sudo mount -t cifs //yourserver/share /your/mountpoint -o username=yourusername

(you can do password=yourpassword, but I don’t recommend that since, it is then left in your bash history and can be comprimised if someone gets a hold of your machine etc etc).

@eclipseagent Of course, you are quite right, but I’ll add two extra cautionary points:

Recompiling the kernel as a way to replace cifs with a deprecated filesystem is hardly an ideal “option”, or even a practical one. I would recommend against that.

Your recommendation to mount from the CLI will get MarcusMoeller tempoary access to the remote data, but may I suggest to use an entry in fstab instead because that was used in the opening post, suggesting a need for permanent access, like the several I suggested in the link:
Samba: HowTo Mount a CIFS Network Share [AKA Map Network Drive] in openSUSE 10.2, 10.3
Oh and BTW MarcusMoeller don’t forget the option _netdev in the fstab entry.

smbfs was dropped not only for security reasons, but for weird bugs. One
that took me a week to solve: when copying a driectory with thousands of
files of a smbfs share, every 39th file (maybe it was 41st) would fail to
copy with no warnings at all. Luckily, when my brain had all but exploded,
cifs was already under development and had replaced smbfs (I didn’t know it
at the time.)

One thing - the init script for openSUSE is called ‘smbfs’ not ‘cifs’. It
looks at the fstab and will mount any smbfs or cifs share. To use it from
the command line (as root):

‘rcsmbfs start’ (or stop/restart/etc.)

That would be just the pits.

One thing - the init script for openSUSE is called ‘smbfs’ not ‘cifs’. It
looks at the fstab and will mount any smbfs or cifs share. To use it from
the command line (as root):

‘rcsmbfs start’ (or stop/restart/etc.)

Thanks for that. Does that have anything to do with smbfstab? I’ve not yet been able to mount a share using smbfstab to cause it to mount at boot time (or any time) and can’t find out why. Is that a cause?

I am not too familiar with /etc/samba/smbfstab; but, it looks like it may have been superceded by just using the normal /etc/fstab and the init script ‘smbfs’. (Someone tell me I am right/wrong.)

However if you use the ‘credentials’ option in the fstab (my preferred method), as in:

credentials=/etc/mysmbpassword

make sure to set the file permissions as 600 so no one else on the system but root can view/modify it.

g