Debian Sarge Fs Mount Error Smbfs
smbfs Previously we've covered mounting remote filesystems using OpenSSH which works very well for most Unix servers. But when it comes to remotely mounting filesystems from Windows servers, or desktops, there's only one choice. The Samba file system module, smbfs. Much like mounting remote filesystems with OpenSSH this involves the use of a kernel module, but unlike shfs there's no need to build this from source yourself. The Debian kernel packages all come with the smbfs module built already, although if you compile your own kernel from source you might need to enable it yourself. Samba is a very well known project in the Linux world, it allows you to do a lot of different things but most noticably: Communicate with a Microsoft Windows fileserver, domain server, or printer server. Impersonate a Microsoft Windows fileserver, domain server, or printer server. Both the K desktop environment (KDE), and the GNOME desktop allow you to explore remote Samba shares, or Microsoft windows shares. However there are times when you cannot use these - for example if you wished to backup a remote machine from a shell script. For these jobs the Samba File System kernel module, and tools, are a much better fit. To mount a remote system directly upon your current system you'll need: The smbfs kernel module The smbfs package. A mountpoint - this is just an empty directory. The Name/IP address of the host to connect to. Login credentials to the remote share - both username and password. Local root privileges to do the mount, and load the kernel module. If you don't already have the smbfs package installed you'll need to install it: root@mystery:~# apt-get install smbfs When this is installed you'll also get the samba-common package. If you're not already running a Samba server the installation of this package will ask a couple of questions about your workgroup name, etc. You may safely ignore those questions and just accept the defaults. Once you have the smbfs package installed you can begin testing things. As a small example lets assume I wish to mount the "C:" drive of remote machine "recurring.my.flat" to the local machine mystery.my.flat I would begin by loading the kernel module: root@mystery:~# modprobe smbfs You can cause
error mounting windows share-but fedora does it well--help From: Siju George
(several times) and I have the same problem. When I try to use cifs to mount a share from my file server I get: mount error: cifs filesystem not supported by the system mount error(19): No such device https://www.turnkeylinux.org/forum/support/20121126/cifs-mount-problem Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) I have tried the mount from webmin and from the command line, I get the same results. The appliances I have tried are openphoto and owncloud. I have done: apt-get install samba apt-get install cifs-util apt-get install smbfs (The last should be redundant with the second, but when things don't work you try stuff ) Here is a typical command line: mount -t cifs //vixen/c /tmp -o user=genel I am prompted for my debian sarge password and then I get the error above. Without access to the files server the appliances are not of much use to me and it looks like a nice way to get some of the functionality I need. Any help would be appreciated. Gene ‹ Sudo wants www-data user password. Not running as root? Piwik (ERR_EMPTY_RESPONSE) › So you are trying to share folders between TKL appliances? Jeremy Davis - Tue, 2012/11/27 - 00:29. Firstly assuming that you debian sarge fs are trying to share folders between TKL instances then IMO Samba/CIFS is not an ideal plan. Samba is Windows file sharing and there are other better options when sharing files Linux->Linux IMO. So my answer isn't really addressing your problem/errors, but suggesting a different way of acheiving your ends. I hope it is relevant... Assuming that you are trying to share folders between TKL appliances running as OVZ containers on PVE then the best way IMO is to bind mount the folders you wish to share to the 'guest' appliance within PVE. No software to install and from within the container it appears to be part of the native filesystem. I don't recall the exact steps OTTOMH but if you search the Proxmox forums/wiki then you will find them. Be aware though that for permissions to work as you would expect, the user IDs will need to match between appliances (which AFAIK they should by default for the default users - will only potentially be an issue if you have configured additional user accounts). The other option (if they aren't both running as OVZ containers or are on different hosts - even if they are physical machines) is sshfs. You will need to install it on your guest appliance ('apt-get install sshfs') and if you aren't using the root user you will also need to configure fuse (have a google for 'sshfs' for details). Nothing needs to be configured on the host (although if