Mount a Remote Drive via SMBFS

From AwkwardTV
Revision as of 17:05, 23 June 2007 by Alexis (talk | contribs) (Manual connection ok, but startup connection fails - Problem solved: more debugging)
Jump to: navigation, search

This section deals with possible solutions to handle mounting of SMBFS ('Windows shares') on the ATV.

Users familiar with OS X kernel extension will know from experience that a stock 10.4.7 or 10.4.8 smbfs.kext will not load/link against the ATV kernel. This means that SMB shares cannot be enabled simply by copying the smbfs.kext from a Mac onto the AppleTV. Instead, a separate smbfs mounter program will have to be installed.

There are a number to choose from - Sharity 3, DAVE, etc.

Recent Changes:

  • June 19 2007 - Solved problem with mounting on startup. This will solve the same problem for AFP mounts too.



Sharity Light

Download

  • This procedure requires you to work with the command line in Terminal.
  • You can either compile sharity yourself, or download a pre-compiled binary.
  • You will need Developer Tools installed on an Intel Mac in order to compile sharity yourself. If you'd rather avoid compiling from source (or have a PPC Mac, linux box, etc.) use the pre-compiled binary option below.


Precompiled binary option

Compiling sharity from source yourself

  • Make sure the server you're about to mount exists in the /etc/hosts file on your AppleTV.
  • On your Mac, download v1.3 @ http://www.obdev.at/products/sharity-light/index.html
  • Sharity will download as a .tar archive. You can unpack it by clicking on the archive and OS X will unpack the archive for you.
  • Unpack the archive (this has been tested on an Intel 10.4.8 system) and edit the Makefile.
  • The Makefile comes set to compile for NextStep/OpenStep rather than OS X.
  • So you need to switch the Makefile to compile for OS X by commenting out the NextStep section (i.e. putting a # symbol at the beginning of each line of the NextStep section
  • # Uncomment the OS X section by removing the # symbols at the beginning of the CFLAGS, THE_CC and RPC_WARNFLAGS lines of the Makefile section for MacOSX.
  • You will need to do some tapdancing to compile Sharity. Run make. It will bomb out--don't worry. cd to nfs, run make, cd .., run make, and test ./shlight
  • You will now have a compiled binary, shlight

Installation

  • sftp, scp or use fugu to transfer shlight from your computer to the AppleTV. You will want to transfer the binary first to your ATV frontrow home directory: /Users/frontrow/
  • After transferring the binary to the AppleTV, SSH into the ATV
  • First make sure your AppleTV drive is mounted read/write.
  • From SSH type: sudo mv shlight /usr/sbin (or /usr/bin)
  • You will be asked for a password. The password is frontrow by default.
  • Then type: sudo chmod +x /usr/sbin/shlight

Mounting your drives as frontrow:

  • Sharity is a userland application. It is not built into the operating system and rather must be placed into running status by you from ssh, or through the use of a script should you wish to automatically mount designated drives upon startup
  • To mount your share, run shlight from the command line. Following the shlight command indicate the share first (use SMB // notation for the server name, followed by the share name) and the sharepoint the SMB share will be mounted to on your AppleTV second. Unlike appleshare or NFS mounting on the AppleTV you do not need to create a mount point using mkdir--sharity will provide the mount point you indicate.

For example:

/usr/sbin/shlight //server/Share /Users/frontrow/Movies/MountedShare

  • Some SMB servers will require you to specify a username and password in the command-line. The username and password needed are those from the account sharing the directory you want to mount. For example:

/usr/sbin/shlight //server/Share /Users/frontrow/Movies/MountedShare -U username -P password

This format is particularly useful in a script. You can automate the mount by placing the above command in the /etc/rc.local file on the AppleTV.

  • Or you can just run:
/usr/sbin/shlight //server/Share /Users/frontrow/Movies/MountedShare -U username
if you don't mind being asked for a password


After mounting your share:

  • Fire up ATVFiles and browse your content
  • Tested for about 12 hours with a variety of clips ranging in size 600Mb-4Gb, bitrates 500Kbps-4.5Mbit, and codecs supported by Perian. No issues yet.
  • Also tested on a linux box running ubuntu Feisty Fawn.

Troubleshooting Sharity

Failing to connect to a server by either IP or NetBIOS name

Installed it, I'm able to mount other machines' SMB shares, just not my fileserver's for some reason...

From the ATV:

bash-2.05b# ping x.x.x.x
PING x.x.x.x (x.x.x.x): 56 data bytes
64 bytes from x.x.x.x: icmp_seq=0 ttl=128 time=1.199 ms
64 bytes from x.x.x.x: icmp_seq=1 ttl=128 time=0.476 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=128 time=0.327 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=128 time=0.737 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=128 time=0.625 ms
^C
--- x.x.x.x ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.327/0.673/1.199/0.297 ms
bash-2.05b# shlight //x.x.x.x/movies ~/Movies
x.x.x.x: unknown host

Happens as root or as frontrow...

ProfessaFresh 22:35, 27 April 2007 (CEST)

Solution

I had the same issue. Fixed it by altering the hosts file. It seems that shlight doesn't work with IPs and if you haven't got DNS working properly, it fails. Adding the IP + Hostname to /etc/hosts means that both the IP and the hostname respond. dobedobedoh 21:37, 27 April 2007 (GMT)

thanks dobedobedoh, that worked

ProfessaFresh 22:51, 27 April 2007 (CEST)


Thanks for this hack! It works perfectly! oorosh

Fails to open files

In a setup with shlight and Vista (in a domain) it seems you need to specify -W [domain name]. It connects and shows the files (you can browse), but fails to open. the shlight responds with:

nfs server shlight-163: not responding nfs server shlight-163: not responding

and can only be killed. The apple tv interface keeps waiting for the files become available. Which doesn't because of input/output error and can only be satisfied with a sudo reboot.

--Battler 17:29, 12 June 2007 (CEST) I have the same problem with a Windows 2003 File server thats in a domain. Sow I thought just add the domain name. with the -W command. The error message that I have is; Workgroup/Domain too long (max 15): dns.dnsnameof20charcts.com How can I solve this problem without actualy changing the domain name.


Fails to open files, cont'd

I have the same problem as above, although I have not been able to verify the error message as I can't seem to get debugging working. shlight works great when mounting from a Ubuntu/Samba share, but can only browse when mounting a Vista share and crashes when I try to open a file. Any help would be greatly appreciated.

Benjaminfox 08:46, 19 June 2007 (CEST)

Kernel: smb_receive_raw: Invalid packet 0x83

Kernel: smb_receive_raw: Invalid packet 0x83
Kernel: smb_receive: receive error: -5
Kernel: smb_proc_connect: Failed to send SESSION REQUEST.
error connecting to server: [5] Input/output error

This error may be seen if the hosts file has been set up improperly. Make sure the hosts file and the windows system name are identical, otherwise use the "-c" and "-s" options to shlight.


Manual connection ok, but startup connection fails - Problem solved

JeanLuc7 and others have asked:

connecting my Windows XP machine via Terminal works great:

  /usr/sbin/shlight //192.168.xx.yy/Video /Users/frontrow/Movies/Filme -U frank -P xxx

I added this command to my rc.local to have the connection right on startup, but unfortunately this does not establish a connection to my server. I have to do it manually every time I start up the ATV - which then always works great. [...]

These problems all stem from the same source: The Ethernet (or 802.11n) interface isn't up and configured when you try to mount, because it uses DHCP, and it hasn't acquired an address yet.
I've written a LaunchDaemon item that handles this for AFP, but the problem is identical. Here's an excerpt from the script that does the important part:

until ( ifconfig en0 ; ifconfig en1 ) 2>/dev/null | grep -q 'inet ' ; do
  echo "waiting 1 second for network interfaces..."   # You can delete this line
  sleep 1
done

But there's still one more detail to address: The first packet out will be dropped (I didn't bother to figure out why, it didn't seem worth the trouble). There are several approaches to that problem. Since I wanted to never have to think about it again, my mounter just does the first mount twice (if the first attempt succeeds, the second fails harmlessly, so it can run even after system boot time). But if you know your environment, you could probably just ping your home router once. Or just hit the broadcast address:

ping -c1 192.168.1.255   # Your network addresses may be different!

For most people, simply combining the two code excerpts above into rc.local, before the mount_afp or shlight command, should do the trick. (Worst case, repeat the mount command instead of using ping.) But consider making your own LaunchDaemon, it's not hard to learn.

The other option would be to use the automounter. I'd have tried that first, except the puzzle of why things weren't working was really irritating me...

And to answer other questions, no, /etc/rc* don't have to be executable. And yes, rc does call rc.local.

When I tested this solution, I was pleasantly surprised to find that the mounts were visible to ATVFiles as soon as the interface was available (even if I interrupted the bootup eye candy). My first cut at this, I anticipated having to kill the finder/backrow after mounting. It turns out that that's not needed.

--Alexis June 18 2007

So it doesn't work any more...

In my rc.local I have

/sbin/kextunload -b com.apple.driver.AppleTCOWatchdog
until ( ifconfig en0 ; ifconfig en1 ) 2>/dev/null | grep -q 'inet ' ; do
  echo "waiting 2 seconds for network interfaces..."   # You can delete this line
  sleep 2
done
ping -c2 10.10.10.1   # Ping twice for the first packet 
sudo /usr/sbin/shlight //NAS/disk1/multimedia/Films /mnt/NAS -U user -P ***
/usr/sbin/shlight //NAS/disk1/multimedia/Films /mnt/NAS -U user -P ***

chmod is 644 and at boot, there's nothing..

What's wrong ?

--Galphanet June 19 2007

You'll need to do some debugging to figure it out. In the boot-time environment, you're a little constrained. The easiest way to do it (sloppy, but OK here because nothing that cares will run from rc.local) is to redirect all stdout and stderr to a logfile so you can see what's happening. Add

exec >/Users/frontrow/boot.out 2>&1

to the beginning of your rc.local. After it boots, look at boot.out and see what errors you're getting. Post here if you're lost, I'll try to take a look. You can also do some debugging yourself (whee, 1970s tech!) by adding interesting lines in the rc.local. For example, add "ifconfig" on the line before the ping so we can confirm that the interface is really up, and has a valid IP assigned. (I suppose one possible problem could be that your DHCP server was lame; if so the ATV might self-assign an address, which would screw you up, and then get a real address a few seconds later. But that's just a WAG, not very likely.)

Aside from all this, get rid of that sudo. It's redundant, since the startup environment runs as root. In fact, you *might* want to "sudo -u frontrow" - otherwise permissions may be wrong for frontrow access (I don't know for sure, I don't use Sharity). Add a line with "df" after the shlight line, so we can see what mounts actually get done, and maybe an "ls -ld /mnt/NAS".

--Alexis June 19 2007

Hello, Thanks you very much for looking at this. So, the new rc.local file contains

exec >/Users/frontrow/boot.out 2>&1

/sbin/kextunload -b com.apple.driver.AppleTCOWatchdog

echo "launch ifconfig"
ifconfig

until ( ifconfig en0 ; ifconfig en1 ) 2>/dev/null | grep -q 'inet ' ; do
  echo "waiting 1 second for network interfaces..."   # You can delete this line
  sleep 2
done

echo "system has waited for the ip adress"
ifconfig

echo "now ping"
ping -c2 10.10.10.1   # Ping for the first packet

echo "and now PLEASE mount the network disk"
/usr/sbin/shlight //NAS/disk1/multimedia/Films /mnt/NAS -U appletv -P ****

and our boot.out

kextunload: unload id com.apple.driver.AppleTCOWatchdog succeeded (any personalities also unloaded)
launch ifconfig


lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280


waiting 1 second for network interfaces...
waiting 1 second for network interfaces...
waiting 1 second for network interfaces...
system has waited for the ip adress


lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::217:f2ff:fef7:985e%en0 prefixlen 64 scopeid 0x4
        inet 10.10.10.23 netmask 0x19191900 broadcast 238.238.238.255
        ether 00:17:f2:f7:98:5e
        media: autoselect (100baseTX <full-duplex,flow-control>) status: active
        supported media: autoselect 100baseTX <full-duplex> 100baseTX <full-duplex,flow-control> 100baseTX <hw-loopback> 100baseTX <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,flow-control> 1$
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether 00:19:e3:db:7b:9e
        media: autoselect (<unknown type>) status: inactive
        supported media: autoselect
wlt1: flags=41<UP,RUNNING> mtu 1500

now ping

PING 10.10.10.1 (10.10.10.1): 56 data bytes
64 bytes from 10.10.10.1: icmp_seq=0 ttl=64 time=1.649 ms
64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=1.797 ms

--- 10.10.10.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.649/1.723/1.797/0.074 ms

and now PLEASE mount the network disk
Using port 49169 for NFS.

and

-bash-2.05b$ ls -ld /mnt/NAS
drwxr-xr-x   2 root  admin  68 Jun 16 15:40 /mnt/NAS
-bash-2.05b$ sudo ls /mnt/NAS
Password:
-bash-2.05b$
-bash-2.05b$ df
Filesystem   512-blocks    Used    Avail Capacity  Mounted on
/dev/disk0s3    1843192 1184800   639968    65%    /
devfs               190     190        0   100%    /dev
fdesc                 2       2        0   100%    /dev
<volfs>            1024    1024        0   100%    /.vol
/dev/disk0s4   75146000 2345336 72800664     3%    /mnt


So we can see that the answer of shlight is correct (it probably thinks that it is ok) One more thing: I'm using fixed IP adresses (so no DHCP...)


--Galphanet June 19 2007

I can confirm Galphanet's results even with DHCP. I have the exact same issue.

--Jeremy 01:33, 22 June 2007 (CEST)

Me too - i have tried adding shlight in /etc/rc instead of rc.local with no luck - i have also tried to run df/ls and my boot.out shows the files without problem. But i guess something is killing the shlight process when everything starts. sudo -u frontrow /usr/sbin/shlight don't work. I also did a script with sleep 60 and /usr/sbin/shlight etc .. to start within rc.local. This did not work.

--Azral 00:28, 23 June 2007 (CEST)

So can we make a script who is waiting for the boot process complete and when it's ok, it launch shlight ?

--Galphanet June 23 2007

If we could figure out why shlight is killed and by what, and figure out a way to bypass that - yes. Now it's safe to asume that any script started within rc.local is killed by something when something happens. (My sleep 60-thing did not work ..)


--Azral 14:46, 23 June 2007 (CEST)

I think that Finder.app is the housecleaner for bad process... The other thing is to use the automount fappliance (it is in the plug-in directory) and ask to the developper to add support of shlight...

--Galphanet June 23 2007

Apparently there are multiple problems. My fix for the interface not being up is working, as your debug output shows, and yet sharity is still failing. As Azral indicates, sharity is actually running successfully and mounting the requested volume (that's progress!) but it's being killed at some point. We need some more old-fashioned debugging. If sharity supports a debugging flag ("-d", "-v", etc.) that can help, that would be good.

Another thing you can try- instead of just running the sharity command, try this:

( # keep SMB volume mounted
  while : ; do
    /usr/sbin/shlight //NAS/disk1/multimedia/Films /mnt/NAS -U appletv -P ****
    # You could do this here: echo "shlight failed on `date`; restarting in 5 seconds"
    sleep 5
  done
) &

See if that helps. Of course, that's a cheesy way of doing what launchd will do really nicely, if you set up a plist for it. You might want to try that- it's how I actually get my AFP disks mounted. In fact, I'll try to set up a page for that soon.

Commercial SMB Clients (Ex. DAVE)

Not tested for obvious reasons.