Drobo FS Shell/System FAQ

This is a collection of useful linux shell tips for the Drobo FS.

CAUTION: Some of these tips here involve changes to system files and could result in corruption of system files, locking your Drobo FS, removing file shares, or potentially data loss. Make these changes at your own risk as you will need to fix it yourself. I do not warranty or support any problems that result through any of the listed tips. Believe me, it does happen because I've done it myself!

Anyone who tries using passwd to change the root password and then reboots their Drobo FS quickly learns that the password is reset back to “root” after the reboot. This happens because the Drobo FS system has a built in feature that rebuilds the passwd file after a reboot. Adding or removing a user from the Dashboard will most likely result in the same behavior.

If you want change the root password and make sure it sticks, use the passwd command to change the password for the root user and then using vi, copy the updated line from the /etc/passwd file, and manually update the hidden /etc/.passwd file. The /etc/.passwd file is used as the source to rebuild the /etc/passwd file, so your changes will stick.

Warning: Changing this /etc/.passwd file IS permanent and does appear to persist after a Drobo FS reset as well. This means that if you forget this password, a drobo reset will not reset it back to root.

Update: There is an updated version of the Dropbear Drobo App that attempts to fix this issue with the root_passwd script. Running this script should result in saving the root password during reboots, but the script only works for setting the root password.

First, you must download the application package file to the DroboApp share.

# download the MediaTomb application from this site
wget -P /mnt/DroboFS/Shares/DroboApps http://drobo.jhah.net/_media/apps/mediatomb/mediatomb.tgz

After downloading the package, you can either install and start it manually or call the internal script to complete the install.

# run DroboApp install (install and starts new application files)
/usr/bin/DroboApps.sh install
 
# or manually install and start the application
cd /mnt/DroboFS/Shares/DroboApps
tar xzf mediatomb.tgz
./mediatomb/service.sh start

To uninstall a DroboApp, you simply need to delete the application folder. To be safe, you should always stop the application before deleting it.

# stop the specific application
/mnt/DroboFS/Shares/DroboApps/mediatomb/service.sh stop
 
# delete the application folder
rm -rf /mnt/DroboFS/Shares/DroboApps/mediatomb

When using a static IP address, you can only set the DNS servers in the Dashboard but you cannot specify the default domain or extra search domains. The result is that your Drobo FS may have issues with DNS resolution of local computers on your network, or even itself for that matter.

You can manually edit the /etc/resolv.conf file to correct this problem; however, your changes would be lost after a reboot. You can make easily make this permanent by updating the /etc/init.d/net_config script that generates /etc/resolv/conf when using a static address and add your domain to the configuration file.

--- /etc/init.d/net_config      Thu Jul  1 05:32:57 2010
+++ /etc/init.d/net_config.new  Thu Jul  1 03:58:09 2010
@@ -136,7 +136,8 @@
     static_err=1
   fi

-  echo nameserver $DNS1 > $RESOLV_CONF
+  echo domain mynetwork.local > $RESOLV_CONF
+  echo nameserver $DNS1 >> $RESOLV_CONF
   echo nameserver $DNS2 >> $RESOLV_CONF

   if [ $static_err -eq 0 ]; then

• The restart button is now enabled in version 7.0.4 of Dashboard.
• If dashboard is not available, the power switch can be used to power off and on the Drobo FS.
• For those with SSH access, the following command will restart your Drobo FS:

/usr/bin/DroboApps.sh stop
/sbin/reboot

• The shutdown button in the Dashboard is the recommended method.
• If dashboard is not available, the power switch will stop applications and power off.
• For those who like SSH, you are out of luck at this time. There are several commands but they will not work as expected, here are some details.

# the following command DOES stop applications
/usr/bin/DroboApps.sh stop
 
# halt the system, but does NOT shut down applications or power off the device
/sbin/halt
# poweroff does the same as halt, it does NOT turn off the power
/sbin/poweroff
 
# using either of these commands will halt the system and you must then use the power button.

You may have found the /mnt/DroboFS/System/samba/conf/smb.conf configuration file already and yes it is the config file used by the smbd process. The changes does not seem to always take effect so you could stop samba using /etc/init.d/deinit_samba and then /etc/init.d/init_samba to restart it. If you do this, you might see successful results. …But wait, does this really work?

If you look closely at the smb.conf file, you will see generated by generateConfigFile which is a clear sign that the Drobo will overwrite your changes. If you modify this file directly, your file will be overwritten eventually. If you are also supporting AppleTalk clients, you would need to update the /mnt/DroboFS/System/netatalk/conf/AppleVolumes.default file as well, which again is a generated file. Further, if you launch the Dashboard your would not be there.

This does not mean that we are out of luck just yet. The Drobo FS writes the master data for shares in the /mnt/DroboFS/System/DNAS/configs/shares.conf XML file. If you update this XML file, it will use this data to regenerate the SMB and AppleTalk configuration files so that your changes won't be lost. After you reboot, your changes should also appear in the Dashboard. I suggest that you keep a backup of the original file before making any changes, the .scratch file won't help you recover the original. Do NOT try to kill and restart the nasd process to regenerate these files, it most likely won't work and it may reset your configuration.

Note: you can edit the /etc/.backup_smb.conf file to change some SMB settings even though this wasn't the original question.

There was a known issue with Drobo FS drives not spinning down that was fixed with firmware v1.05; however, this firmware apparently did not fix this issue for everyone. If you are still having issues with your drives not spinning down after the firmware update, it could be caused by anonymous or NULL connections to the Samba server process on your Drobo FS because the Samba “connections.tdb” file which tracks open connections is stored on the physical disk.

You can try one of the two following fixes depending on your needs:

1. If possible, change your Drobo FS Workgroup setting so that it does NOT match your local network (or at least the culprit Windows workstation). This is not the best fix as other network devices may have issues connecting to your Drobo FS if not within the same workgroup.
2. A better fix is to change the Samba configuration of the Drobo FS to move the connections.tdb and other non-persistent files off the physical disk. Since the setting is defined in /mnt/DroboFS/System/samba/conf/smb.conf which is auto-generated, you cannot change this directly. The workaround is to redefine the lock dir setting in the /etc/.backup_smb.conf file to override the default from the generated smb.conf file such as the following:

   ; store samba lock files on flash under /var (only 2MB total)
   ;lock dir = /var/samba/lock
   ; or store them in memory instead of persistent storage
   ;lock dir = /dev/shm/smblock

   The setting could be overwritten by a firmware update, but is persistent through normal activity.

Warning: The /var mount has very limited space and this could potentially lead to problems if the lock files start growing too large.

Note: This issue was easily reproduced in all tests with the network Browser service on a Windows XP Pro SP3 workstation. Not all versions of Windows were tested and Windows 7 was not as consistent.