Has anyone on this forum managed to get the UNFSD DroboFS app working properly, and been able to connect to it from a client device?
I have tried and failed so far. I have almost no Linux knowledge, so can anyone tell me how to check to see if everthing is set up right and working correctly on the DroboFS (I can SSH into the DroboFS Linux console to enter commands but don’t know what to enter)?
the way it installs itself, it doesn’t work on most networks.
you need to edit
make the 192.168.0.0 match your network, the “24” after is the same as a netmask of 255.255.255.0, this will give all computers on your network access.
if you only want access from a single ip, leave off the “/24” and put in the ip of that computer
this will make one NFS share, with all of the shares you configured from drobo dashboard in it. if you only want certain folders, you can make multiple lines and just add the appropriate names like “/mnt/DroboFS/Shares/Public”
for more options for this file google “nfs exports”
once edited run the following on the drobo’s command line/mnt/DroboFS/Shares/DroboApps/unfsd/service.sh restart
to restart unfsd so the changes will take affect, or just restart the whole drobo from dashboard.
then from the computer you are trying to access from
showmount -e ip.of.drobo.fs
it should read
Export list for ip.of.drobo.fs:
I finally got it to work after finding where they bury the exports file. Thanks waw74!
You should be able to mount right to the share you have specified in the exports file. The default path on mine was: /mnt/DroboFS/Shares. Once I tried to mount to that full path, everything was happy. Hope this helps get you on your way.
So, I have one line that points the NFS to share only the Folder that I created through the Drobo Dashboard. And the IP_Address_of_Server is allowing only my Ubuntu server access to the NFS Mount by entering just the address of my Ubuntu Server. If you don’t know the address you want to permit, or you want to allow anyone on your network access it should read something like 192.168.1.0/24.
From my Ubuntu Server to mount to the NFS Share:
sudo mount -t nfs [IP_Address_Of_Drobo]:/mnt/DroboFS/Shares/[Name_Of_Share]/mnt/drobo/
This mounts my [Name_Of_Share] (Created in Drobo Dashboard) to the /mnt/drobo directory of my Ubuntu Server.
I’ve just configured this today so I am still testing SMB -vs- NFS but I have been much happier with NFS over SMB in the past.
One thing I’ve noticed is that if you don’t do /mnt/DroboFS/Shares/DroboApps/unfsd/service.sh restart, you may get mixed results. Rebooting the Drobo doesn’t always seem to restart the unfsd to populate your changes.
I tried getting UNFSD working but I ran into one problem - nothing I had would let me mount the damn shares. It’s some issue with the guid or something like that. It would nice if they had a tutorial covering the client side as well. I don’t think it’s goign to be any faster though (see my post about network performance).
Since I have a VPN setup to connect to my home network, I changed the network mask from /24 to /16. This way, any addresses from 192.168.0.1 to 192.168.254.254 are allowed to connect. This also solves the problem of different router DHCP configurations, since different manufacturers use different subnets. This is still secure since all this address space is not internet routable.
I created a different mount point for each share. More of a cosmetic change, really, but I think it makes client configuration easier. Also makes it harder to mess up the DroboApps share, by not mounting it.
‘insecure’ means that uNFSd will accept connection attempts from clients not running in ports lower than 1024. If you have no idea what this means, then you shouldn’t worry about it. I enabled it because I actually have developed my own userland NFS client, and I used the FS to test it. Setting it as insecure doesn’t really make NFS less secure at all, and may actually help with connectivity problems.
I squashed all clients into the ‘nobody’ user and group (i.e., all activity is performed as user ‘nobody’, group ‘nobody’). This may look weird at first, but it makes the most sense when dealing with a mix of SMB and NFS clients. Since the SMB daemon in the FS already performs all activity as ‘nobody’, all the file/folder ownership info gets mapped to ‘nobody’ on the SMB side anyway. By setting NFS this way, I just make sure that I don’t get any weird permission errors when mixing clients.
To guarantee that every file had the proper permissions, I just SSH’ed into the FS, and changed the ownership and fixed the permissions of all files in the shares. Since I’m basically the only one using the FS, I set it to something very ‘promiscuous’, like:
I got UNFSd working without much fuss, the problem I had was NFS performance was horrible compared to CIFS from the same client. Logged in to the Drobo and unfsd was sucking up 100% CPU but providing very little throughput, so I kicked it to the curb and went back to using Samba to mount my Drobo shares.