Hi all,

I try
sudo mount -t vfat -o smb://192.xxx.x.xx/devices/C85E-21BE /mnt/rpi

and i get

mount: special device smb://192.xxx.x.xx/devices/C85E-21BE does not exist

--
Now 192.xxx.x.xx/devices/C85E-21BE does exist and i can ssh onto it

Thanks for your help!

vfat is not a networked filesystem. likely what you are looking for is "cifs". And it isn't specified by smb://... which looks more like a URL and not a windows share.

However, it looks like the path you have is not a windows path, but a linux path - which would be NFS instead.

Whatever, check the manpage for mount for examples.

thanks for your reply

indeed it is a drive on another linux machine
so you are saying I cannot use smb to mount a dive from another machine?
in that case is there an easy way set up nfs

If its another linux system, wouldn't it be a Linux filesystem, or is it definitely vfat or NTFS.?
You can use nfs or smb/cifs for Linux to linx; which is best depends on the situation.
Can you tell use which OS+version and which fs are at each end?
This manual covers both types of mounts http://www.linuxtopia.org/online_boo...ion/index.html

No - just that it requires both systems to translate to/from Windows authentication methods, and translate Linux based file access into windows access methods and then from windows access methods back into Linux access methods. It also requires the server to be running Samba to provide the CIFS network support.
Not that hard. The following link is for configuring a NFS server for RH - most distributions are the same: http://www.centos.org/docs/4/html/rh...er-export.html
Setting up a client (basic): http://www.tldp.org/HOWTO/NFS-HOWTO/client.html

Depending on which distribution you are using there can be some firewall configurations that need to be set, some auxilary services (to support older clients mostly), but for that I'll have to refer you to your distribution documentation.

Hi -- thanks again for your help

I am giving nfs a chance but still not very successfully.

This is what I am getting

sudo mount -v 192.168.1.13:/v1 /media/raspbmc/
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Sat Oct 5 15:17:12 2013
mount.nfs: trying text-based options 'vers=4,addr=192.168.1.13,clientaddr=192.168.1.4'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=192.168.1.13'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.13 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.13 prog 100005 vers 3 prot UDP port 57355
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.1.13:/v1

Looks like the NFS server isn't exporting the /v1 directory.

This is what i get:

Export list for 192.168.1.13:
v1 192.168.1.4
/media/C85E-21BE 192.168.1.4

Can you post a copy of your /etc/exports file from 192.168.1.13 and verify that nfsd is running? Also, do you know what version of NFGS you are running (NFSv3 or NFSv4)?

Here is the exports files on *.13

# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/media/C85E-21BE 192.168.1.4(rw,sync)
v1 192.168.1.4(rw,sync)

Then i restarted the nfs server

sudo /etc/init.d/nfs-kernel-server restart
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
[....] Exporting directories for NFS kernel daemon...exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "192.168.1.4:/media/C85E-21BE".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x

exportfs: /etc/exports [2]: Neither 'subtree_check' or 'no_subtree_check' specified for export "192.168.1.4:v1".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x

. ok
[ ok ] Starting NFS kernel daemon: nfsd mountd.

I believe I have version 3 on the server.

I get nothing when i run

rpcinfo -p | grep nfs

on the client side

You need to give an absolute path in /etc/exports, so the second line should be

Assuming that /v1 is the directory that you want to export.

If it still does not work, you likely have a firewall blocking access to the portmapper. On 192.168.1.13 please post the complete output of "rpcinfo -p localhost" (the service is often called mountd, which is why grepping for nfs did not work). On 192.168.1.4, post the output from "rpcinfo -p 162.168.1.13". If the outputs are not the same, there is most likely a firewall problem preventing traffic from being passed.

rpcinfo -p localhost
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 53489 status
100024 1 tcp 44769 status
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 49169 nlockmgr
100021 3 udp 49169 nlockmgr
100021 4 udp 49169 nlockmgr
100021 1 tcp 50249 nlockmgr
100021 3 tcp 50249 nlockmgr
100021 4 tcp 50249 nlockmgr
100005 1 udp 59239 mountd
100005 1 tcp 40784 mountd
100005 2 udp 55781 mountd
100005 2 tcp 33273 mountd
100005 3 udp 40663 mountd
100005 3 tcp 45757 mountd


and then *.4 i have NOTHING after quite a bit of waiting

Like I say, it's probably a firewall problem then. Most Linux distros are set up with firewalls out of the box that are not configured to pass NFS traffic. You will need to either disable the firewall on 192.168.1.13 or figure out how to pass traffic to the portmapper and the actual ports that NFS uses (which are enumerated above). Honestly, if you're comfortable with it and this is on a protected local LAN, your best bet is just turning off the firewall on 192.168.1.13.

This troubleshooting section is part of the nfs-howto on sourceforge. It might give you some more help in tracking down the problem.

If it turns out to be a firewall issue and you don't want to turn off your firewall or make it broadly permissive, you might want to review the security section on the tldp nfs-howto. There are several NFS daemons that bind to random ports chosen by portmapper that you may have to change to use ports that you specify so you can write appropriate firewall rules. See the section of this Slackware NFS doc that discusses firewall for an example. The instructions on updating startup scripts may not apply to you, but the firewall rules themselves are likely applicable.

Good day -- indeed disable the firewall does seem to do the job!

Looks like i have quite a bit of ready to do -- it will be a fun sunday!

Thank you very much for you help -- i'll let you know how it goes