Amahi Wiki - User contributions [en]

Secure SSH against brute force attacks

2013-08-30T06:09:09Z

Inquam:

With more and more people installing Amahi we have more and more Amahi's exposed to the internet when people start opening up ports in their routers to be able to access their servers remotely. Since SSH is used by many this is often also exposed outwards. This opens up for SSH brute force attacks (which can be both fast and effective).

[root@dahome ~]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: SSH side: source mask: 255.255.255.255
LOG tcp -- anywhere anywhere tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255 LOG level warning prefix "SSH_brute_force "
DROP tcp -- anywhere anywhere tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

There are many more or less elaborate ways of doing this, but these three simple rules add good basic protection. This will allow a couple of failed SSH login attempts and then add a 60 second cool down. Effectively killing any interest in brute forcing the server in question.
To add these rules run the following as root

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Rules created with the iptables command are stored in memory. If the system is restarted before saving the iptables rule set, all rules are lost. For netfilter rules to persist through a system reboot, they need to be saved. To save netfilter rules, type the following command as root

iptables-save > /etc/sysconfig/iptables
<b>NOTE:</b> This actually doesn't work for F19. They have changed things. So you will lose the settings on reboot and have to manually enter them again. Will update once I found the correct way for F19.

What you can do for now is to create a simple script that executes the following on start up to restore the rules saved above

iptables-restore < /etc/sysconfig/ipdtables

= Disable root ssh access =

Another tip is to disable root ssh access if you don't really need it since that is one of the most common user names used when brute forcing.

= Alternative Ports =

Another technique that can help reduce the automatic probes of the SSH port (port 22), is to use some alternative port. For instance, you could choose a port, say port 9988, and forward that (TCP) port from the outside of your router to your HDA's port 22. To connect to your HDA (in this example myhda.yourhda.com) from outside, you could then do:

ssh -p 9988 myhda.yourhda.com

If this gets old, you can avoid the -p in the client configuration. In Linux/Mac OS X systems, this can be done with the .ssh/config file, by adding:

Host myhda.yourhda.com
Port 9988

and you will not need to type the -p in ssh or other programs that use ssh, like rsync, when accessing your host.

= Other Techniques =

Other techniques, in some case more advanced, include:

* [http://www.linuxjournal.com/article/8957 Dual-factor authentication]
* [https://www.linux.com/learn/tutorials/351079-weekend-project-secure-your-system-with-port-knocking Port knocking]

Secure SSH against brute force attacks

2013-08-29T13:36:27Z

Inquam:

With more and more people installing Amahi we have more and more Amahi's exposed to the internet when people start opening up ports in their routers to be able to access their servers remotely. Since SSH is used by many this is often also exposed outwards. This opens up for SSH brute force attacks (which can be both fast and effective).

[root@dahome ~]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: SSH side: source mask: 255.255.255.255
LOG tcp -- anywhere anywhere tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255 LOG level warning prefix "SSH_brute_force "
DROP tcp -- anywhere anywhere tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

There are many more or less elaborate ways of doing this, but these three simple rules add good basic protection. This will allow a couple of failed SSH login attempts and then add a 60 second cool down. Effectively killing any interest in brute forcing the server in question.
To add these rules run the following as root

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Rules created with the iptables command are stored in memory. If the system is restarted before saving the iptables rule set, all rules are lost. For netfilter rules to persist through a system reboot, they need to be saved. To save netfilter rules, type the following command as root

iptables-save > /etc/sysconfig/iptables
- NOTE... This actually doesn't work for F19. They have changed things. So you will loos the settings on reboot and have to manually enter them again. Will udpate once I found the correct way for F19.

= Disable root ssh access =

Another tip is to disable root ssh access if you don't really need it since that is one of the most common user names used when brute forcing.

= Alternative Ports =

Another technique that can help reduce the automatic probes of the SSH port (port 22), is to use some alternative port. For instance, you could choose a port, say port 9988, and forward that (TCP) port from the outside of your router to your HDA's port 22. To connect to your HDA (in this example myhda.yourhda.com) from outside, you could then do:

ssh -p 9988 myhda.yourhda.com

If this gets old, you can avoid the -p in the client configuration. In Linux/Mac OS X systems, this can be done with the .ssh/config file, by adding:

Host myhda.yourhda.com
Port 9988

and you will not need to type the -p in ssh or other programs that use ssh, like rsync, when accessing your host.

= Other Techniques =

Other techniques, in some case more advanced, include:

* [http://www.linuxjournal.com/article/8957 Dual-factor authentication]
* [https://www.linux.com/learn/tutorials/351079-weekend-project-secure-your-system-with-port-knocking Port knocking]

Secure SSH against brute force attacks

2013-08-29T06:54:40Z

Inquam:

With more and more people installing Amahi we have more and more Amahi's exposed to the internet when people start opening up ports in their routers to be able to access their servers remotely. Since SSH is used by many this is often also exposed outwards. This opens up for SSH brute force attacks (which can be both fast and effective).

[root@dahome ~]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: SSH side: source mask: 255.255.255.255
LOG tcp -- anywhere anywhere tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255 LOG level warning prefix "SSH_brute_force "
DROP tcp -- anywhere anywhere tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

There are many more or less elaborate ways of doing this, but these three simple rules add good basic protection. This will allow a couple of failed SSH login attempts and then add a 60 second cool down. Effectively killing any interest in brute forcing the server in question.
To add these rules run the following as root

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Rules created with the iptables command are stored in memory. If the system is restarted before saving the iptables rule set, all rules are lost. For netfilter rules to persist through a system reboot, they need to be saved. To save netfilter rules, type the following command as root

iptables-save > /etc/sysconfig/iptables

= Disable root ssh access =

Another tip is to disable root ssh access if you don't really need it since that is one of the most common user names used when brute forcing.

= Alternative Ports =

Another technique that can help reduce the automatic probes of the SSH port (port 22), is to use some alternative port. For instance, you could choose a port, say port 9988, and forward that (TCP) port from the outside of your router to your HDA's port 22. To connect to your HDA (in this example myhda.yourhda.com) from outside, you could then do:

ssh -p 9988 myhda.yourhda.com

If this gets old, you can avoid the -p in the client configuration. In Linux/Mac OS X systems, this can be done with the .ssh/config file, by adding:

Host myhda.yourhda.com
Port 9988

and you will not need to type the -p in ssh or other programs that use ssh, like rsync, when accessing your host.

= Other Techniques =

Other techniques, in some case more advanced, include:

* [http://www.linuxjournal.com/article/8957 Dual-factor authentication]
* [https://www.linux.com/learn/tutorials/351079-weekend-project-secure-your-system-with-port-knocking Port knocking]

Secure SSH against brute force attacks

2013-08-29T06:36:50Z

Inquam:

Secure SSH against brute force attacks

2013-08-28T13:25:19Z

Inquam: Created page with "With more and more people installing Amahi we have more and more Amahi's exposed to the internet when people start opening up ports in their routers to be able to access their..."

Mount Shares Locally

2013-08-05T07:44:20Z

Inquam: /* Updated script for Greyhole users */

{{MessageBox|
backgroundcolor = #faa|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

<b>NOTE:</b> Recommend not using copy and paste for the steps below. It often introduces hidden characters which causes failure in the script.

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

== Download and Setup ==

* As '''root:''' Install the mount_shares_locally initd script:
=== On Ubuntu ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
sudo apt-get install cifs-utils curl
sudo curl -o /etc/init.d/mount_shares_locally http://dl.amahi.org/mount_shares_locally
sudo chmod +x /etc/init.d/mount_shares_locally
sudo update-rc.d mount_shares_locally defaults
</div>

=== On Fedora ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

== Configuration ==

* Edit /etc/init.d/mount_shares_locally (as user root) in a text editor, and replace ''your_username'' (on line 12) with your username. Example '''username="amahi"'''
{{Code|Code= nano /etc/init.d/mount_shares_locally}}
* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
{{Code|Code= nano /home/YourHDA_username/.smb_credentials}}
*Enter the following:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>
'''NOTE:''' your_username and your_password in the .smb_credentials file needs to be the original username and password you created when you installed fedora.

*To test your new mounts, you can execute '''service mount_shares_locally start''' (as root user)<br/>

'''service mount_shares_locally stop''' (as root user) will unmount the local shares.<br/>

'''NOTE:''' If you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now (<u>DO NOT</u> remove the drive mount lines). The above initd script replaces all this.

== Re-mount to Add new shares ==
If you added new share to greyhole via the web admin. This does not automatically mount locally. You need to restart your mount script by running '''service mount_shares_locally restart'''. This will unmount and remount all your shares, adding all the new shares you added.

== Where everything is mounted ==
You will find the mounted shares in ''/mnt/samba/*''<br/>
For example, your "Pictures" share would be located at '''/mnt/samba/Pictures'''.

<b>NOTE:</b> When working with files on the HDA, access them via this share and <u>NOT</u> the traditional /var/hda/files/pictures location.

== Unable to mount locally after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]

It's easily fixed by installing the missing dependency.

{{Code|yum install cifs-utils}}

Now it should work fine to run

{{Code|/etc/init.d/mount_shares_locally start}}

== MySQL Problems With Newer Versions of Greyhole ==

Since Greyhole moved from SQL Lite to MySQL, you may hit a problem where Greyhole and the mount_shares_locally script both attempt to start before MySQL in bootup, leading to the services not starting properly. If this happens, you can try this to fix it:

{{Code|ls /etc/rc.d/rc3.d/}}
* Look for any entries marked S-1. If there are any, they need to be removed. Run the following as root:

{{Code|rm S-1*}}

== Updated script for Greyhole users ==

Some apps used by Amahi are used to download files etc. Often we want these files to end up in our shares. Let's say that SickBeard is used to download TV episodes. You then have to configure SickBeard to place your new episode somewhere. A logical place is to save to the landing zone of your Greyhole share which could be ''/var/hda/files/TV''. There are two downsides to this though.

* Greyhole is not notified of the fact that a file is added and only discovers it and makes it available in your share after a ''fsck'', which could take a long time.
* Files deleted through apps in this folder don't register a ''delete'' event that Greyhole can pick up and thus only the symlink in the landing zone is removed. The actual file copies remain on disc. Similarly users running Plex Media Server for example will have issues if the clients are allowed to ''delete contents'' and the server is configured to work on the landing zone. I described this issue when packaging Plex a long time ago here: https://wiki.amahi.org/index.php/Plex_Media_Server

Since Greyhole uses Samba as a layer between the user and itself we would like to keep our writes and deletes to the shares and not the actual landing zone. But since apps (most of them) run as the user ''apache'' it will not be able to access ''/mnt/samba'', which is the default mount point if you set up ''mount_shares_locally''. This following script retains the function of the original script but also adds a second mount point under ''/mnt/apache'' where the ''apache'' user will have read and write access. I have kept it simple and it will use the same credentials as the ''main'' mount. So only shares available to that user will be available for apache.

By doing this apache will now have a place where it is allowed to read and write files to your shares and SickBeard can thus be configured to place the new episode in ''/mnt/apache/TV'' which is then instantly picked up by Greyhole and file copies distributed to the discs in your pool as configured.

Note that this script is based of the Greyhole original one and uses ''/etc/samba/smb.conf'' as the source of your shares and does not load the shares from the database like the old HDA version of the script did. If that behaviour is desired that can be easily added by replacing the lines

testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p

with

mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p

### BEGIN INIT INFO
# Provides: mount_shares_locally
# Required-Start: $network $local_fs $remote_fs smb mysqld
# Required-Stop: $network $local_fs $remote_fs smb
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mount Samba shares locally
### END INIT INFO

username="YOURUSERHERE"

if [ -f /etc/rc.d/init.d/functions ]; then
. /etc/rc.d/init.d/functions
fi

start () {
uid=`id -u $username`
gid=`id -g $username`

echo -n $"Mounting Samba shares locally: "
mkdir -p /mnt/samba/
mkdir -p /mnt/apache/
cd /mnt/apache/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
cd /mnt/samba/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
sleep 5
ls -1 | while read d; do
/sbin/mount.cifs "//127.0.0.1/$d" "$d" -o credentials=/home/${username}/.smb_credentials,uid=${uid},gid=${gid},file_mode=0660,dir_mode=0770,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
/sbin/mount.cifs "//127.0.0.1/$d" "/mnt/apache/$d" -o credentials=/home/${username}/.smb_credentials,uid=`id -u apache`,gid=`id -g apache`,file_mode=0777,dir_mode=0777,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
done
touch /var/lock/subsys/mount_shares_locally
success $"$base startup"
echo
return 0
}

stop () {
echo -n $"Unmounting locally mounted Samba shares: "
/bin/umount -l /mnt/samba/*
/bin/umount -l /mnt/apache/*
rm -f /var/lock/subsys/mount_shares_locally
success $"$base shutdown"
echo
return 0
}

restart () {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
;;
esac

exit $?

Mount Shares Locally

2013-08-05T07:43:25Z

Inquam: /* Updated script for Greyhole users */

{{MessageBox|
backgroundcolor = #faa|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

<b>NOTE:</b> Recommend not using copy and paste for the steps below. It often introduces hidden characters which causes failure in the script.

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

== Download and Setup ==

* As '''root:''' Install the mount_shares_locally initd script:
=== On Ubuntu ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
sudo apt-get install cifs-utils curl
sudo curl -o /etc/init.d/mount_shares_locally http://dl.amahi.org/mount_shares_locally
sudo chmod +x /etc/init.d/mount_shares_locally
sudo update-rc.d mount_shares_locally defaults
</div>

=== On Fedora ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

== Configuration ==

* Edit /etc/init.d/mount_shares_locally (as user root) in a text editor, and replace ''your_username'' (on line 12) with your username. Example '''username="amahi"'''
{{Code|Code= nano /etc/init.d/mount_shares_locally}}
* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
{{Code|Code= nano /home/YourHDA_username/.smb_credentials}}
*Enter the following:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>
'''NOTE:''' your_username and your_password in the .smb_credentials file needs to be the original username and password you created when you installed fedora.

*To test your new mounts, you can execute '''service mount_shares_locally start''' (as root user)<br/>

'''service mount_shares_locally stop''' (as root user) will unmount the local shares.<br/>

'''NOTE:''' If you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now (<u>DO NOT</u> remove the drive mount lines). The above initd script replaces all this.

== Re-mount to Add new shares ==
If you added new share to greyhole via the web admin. This does not automatically mount locally. You need to restart your mount script by running '''service mount_shares_locally restart'''. This will unmount and remount all your shares, adding all the new shares you added.

== Where everything is mounted ==
You will find the mounted shares in ''/mnt/samba/*''<br/>
For example, your "Pictures" share would be located at '''/mnt/samba/Pictures'''.

<b>NOTE:</b> When working with files on the HDA, access them via this share and <u>NOT</u> the traditional /var/hda/files/pictures location.

== Unable to mount locally after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]

It's easily fixed by installing the missing dependency.

{{Code|yum install cifs-utils}}

Now it should work fine to run

{{Code|/etc/init.d/mount_shares_locally start}}

== MySQL Problems With Newer Versions of Greyhole ==

Since Greyhole moved from SQL Lite to MySQL, you may hit a problem where Greyhole and the mount_shares_locally script both attempt to start before MySQL in bootup, leading to the services not starting properly. If this happens, you can try this to fix it:

{{Code|ls /etc/rc.d/rc3.d/}}
* Look for any entries marked S-1. If there are any, they need to be removed. Run the following as root:

{{Code|rm S-1*}}

== Updated script for Greyhole users ==

Some apps used by Amahi are used to download files etc. Often we want these files to end up in our shares. Let's say that SickBeard is used to download TV episodes. You then have to configure SickBeard to place your new episode somewhere. A logical place is to save to the landing zone of your Greyhole share which could be ''/var/hda/files/TV''. There are two downsides to this though.

* Greyhole is not notified of the fact that a file is added and only discovers it and makes it available in your share after a ''fsck'', which could take a long time.
* Files deleted through apps in this folder don't register a ''delete'' event that Greyhole can pick up and thus only the symlink in the landing zone is removed. The actual file copies remain on disc. Similarly users running Plex Media Server for example will have issues if the clients are allowed to ''delete contents'' and the server is configured to work on the landing zone. I described this issue when packaging Plex a long time ago here: https://wiki.amahi.org/index.php/Plex_Media_Server

Since Greyhole uses Samba as a layer between the user and itself we would like to keep our writes and deletes to the shares and not the actual landing zone. But since apps (most of them) run as the user ''apache'' it will not be able to access ''/mnt/samba'', which is the default mount point if you set up ''mount_shares_locally''. This following script retains the function of the original script but also adds a second mount point under ''/mnt/apache'' where the ''apache'' user will have read and write access. I have kept it simple and it will use the same credentials as the ''main'' mount. So only shares available to that user will be available for apache.

By doing this apache will now have a place where it is allowed to read and write files to your shares and SickBeard can thus be configured to place the new episode in ''/mnt/apache/TV'' which is the instantly picked up by Greyhole and file copies distributed to the discs in your pool as configured.

Note that this script is based of the Greyhole original one and uses ''/etc/samba/smb.conf'' as the source of your shares and does not load the shares from the database like the old HDA version of the script did. If that behaviour is desired that can be easily added by replacing the lines

testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p

with

mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p

### BEGIN INIT INFO
# Provides: mount_shares_locally
# Required-Start: $network $local_fs $remote_fs smb mysqld
# Required-Stop: $network $local_fs $remote_fs smb
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mount Samba shares locally
### END INIT INFO

username="YOURUSERHERE"

if [ -f /etc/rc.d/init.d/functions ]; then
. /etc/rc.d/init.d/functions
fi

start () {
uid=`id -u $username`
gid=`id -g $username`

echo -n $"Mounting Samba shares locally: "
mkdir -p /mnt/samba/
mkdir -p /mnt/apache/
cd /mnt/apache/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
cd /mnt/samba/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
sleep 5
ls -1 | while read d; do
/sbin/mount.cifs "//127.0.0.1/$d" "$d" -o credentials=/home/${username}/.smb_credentials,uid=${uid},gid=${gid},file_mode=0660,dir_mode=0770,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
/sbin/mount.cifs "//127.0.0.1/$d" "/mnt/apache/$d" -o credentials=/home/${username}/.smb_credentials,uid=`id -u apache`,gid=`id -g apache`,file_mode=0777,dir_mode=0777,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
done
touch /var/lock/subsys/mount_shares_locally
success $"$base startup"
echo
return 0
}

stop () {
echo -n $"Unmounting locally mounted Samba shares: "
/bin/umount -l /mnt/samba/*
/bin/umount -l /mnt/apache/*
rm -f /var/lock/subsys/mount_shares_locally
success $"$base shutdown"
echo
return 0
}

restart () {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
;;
esac

exit $?

Mount Shares Locally

2013-08-05T07:43:12Z

Inquam: /* Updated script for Greyhole users */

{{MessageBox|
backgroundcolor = #faa|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

<b>NOTE:</b> Recommend not using copy and paste for the steps below. It often introduces hidden characters which causes failure in the script.

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

== Download and Setup ==

* As '''root:''' Install the mount_shares_locally initd script:
=== On Ubuntu ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
sudo apt-get install cifs-utils curl
sudo curl -o /etc/init.d/mount_shares_locally http://dl.amahi.org/mount_shares_locally
sudo chmod +x /etc/init.d/mount_shares_locally
sudo update-rc.d mount_shares_locally defaults
</div>

=== On Fedora ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

== Configuration ==

* Edit /etc/init.d/mount_shares_locally (as user root) in a text editor, and replace ''your_username'' (on line 12) with your username. Example '''username="amahi"'''
{{Code|Code= nano /etc/init.d/mount_shares_locally}}
* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
{{Code|Code= nano /home/YourHDA_username/.smb_credentials}}
*Enter the following:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>
'''NOTE:''' your_username and your_password in the .smb_credentials file needs to be the original username and password you created when you installed fedora.

*To test your new mounts, you can execute '''service mount_shares_locally start''' (as root user)<br/>

'''service mount_shares_locally stop''' (as root user) will unmount the local shares.<br/>

'''NOTE:''' If you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now (<u>DO NOT</u> remove the drive mount lines). The above initd script replaces all this.

== Re-mount to Add new shares ==
If you added new share to greyhole via the web admin. This does not automatically mount locally. You need to restart your mount script by running '''service mount_shares_locally restart'''. This will unmount and remount all your shares, adding all the new shares you added.

== Where everything is mounted ==
You will find the mounted shares in ''/mnt/samba/*''<br/>
For example, your "Pictures" share would be located at '''/mnt/samba/Pictures'''.

<b>NOTE:</b> When working with files on the HDA, access them via this share and <u>NOT</u> the traditional /var/hda/files/pictures location.

== Unable to mount locally after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]

It's easily fixed by installing the missing dependency.

{{Code|yum install cifs-utils}}

Now it should work fine to run

{{Code|/etc/init.d/mount_shares_locally start}}

== MySQL Problems With Newer Versions of Greyhole ==

Since Greyhole moved from SQL Lite to MySQL, you may hit a problem where Greyhole and the mount_shares_locally script both attempt to start before MySQL in bootup, leading to the services not starting properly. If this happens, you can try this to fix it:

{{Code|ls /etc/rc.d/rc3.d/}}
* Look for any entries marked S-1. If there are any, they need to be removed. Run the following as root:

{{Code|rm S-1*}}

== Updated script for Greyhole users ==

Some apps used by Amahi are used to download files etc. Often we want these files to end up in our shares. Let's say that SickBeard is used to download TV episodes. You then have to configure SickBeard to place your new episode somewhere. A logical place is to save to the landing zone of your Greyhole share which could be ''/var/hda/files/TV''. There are two downsides to this though.

* Greyhole is not notified of the fact that a file is added and only discovers it and makes it available in your share after a ''fsck'', which could take a long time.
* Files deleted through apps in this folder don't register a ''delete'' event that Greyhole can pick up and thus only the symlink in the landing zone is removed. The actual file copies remain on disc. Similarly users running Plex Media Server for example will have issues if the clients are allowed to ''delete contents'' and the server is configured to work on the landing zone. I described this issue when packaging Plex a long time ago here: https://wiki.amahi.org/index.php/Plex_Media_Server

Since Greyhole uses Samba as a layer between the user and itself we would like to keep our writes and deletes to the shares and not the actual landing zone. But since apps (most of them) run as the user ''apache'' it will not be able to access ''/mnt/samba'', which is the default mount point if you set up ''mount_shares_locally''. This following script retains the function of the original script but also adds a second mount point under ''/mnt/apache'' where the ''apache'' user will have read and write access. I have kept it simple and it will use the same credentials as the ''main'' mount. So only shares available to that user will ea available for apache.

By doing this apache will now have a place where it is allowed to read and write files to your shares and SickBeard can thus be configured to place the new episode in ''/mnt/apache/TV'' which is the instantly picked up by Greyhole and file copies distributed to the discs in your pool as configured.

Note that this script is based of the Greyhole original one and uses ''/etc/samba/smb.conf'' as the source of your shares and does not load the shares from the database like the old HDA version of the script did. If that behaviour is desired that can be easily added by replacing the lines

testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p

with

mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p

### BEGIN INIT INFO
# Provides: mount_shares_locally
# Required-Start: $network $local_fs $remote_fs smb mysqld
# Required-Stop: $network $local_fs $remote_fs smb
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mount Samba shares locally
### END INIT INFO

username="YOURUSERHERE"

if [ -f /etc/rc.d/init.d/functions ]; then
. /etc/rc.d/init.d/functions
fi

start () {
uid=`id -u $username`
gid=`id -g $username`

echo -n $"Mounting Samba shares locally: "
mkdir -p /mnt/samba/
mkdir -p /mnt/apache/
cd /mnt/apache/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
cd /mnt/samba/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
sleep 5
ls -1 | while read d; do
/sbin/mount.cifs "//127.0.0.1/$d" "$d" -o credentials=/home/${username}/.smb_credentials,uid=${uid},gid=${gid},file_mode=0660,dir_mode=0770,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
/sbin/mount.cifs "//127.0.0.1/$d" "/mnt/apache/$d" -o credentials=/home/${username}/.smb_credentials,uid=`id -u apache`,gid=`id -g apache`,file_mode=0777,dir_mode=0777,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
done
touch /var/lock/subsys/mount_shares_locally
success $"$base startup"
echo
return 0
}

stop () {
echo -n $"Unmounting locally mounted Samba shares: "
/bin/umount -l /mnt/samba/*
/bin/umount -l /mnt/apache/*
rm -f /var/lock/subsys/mount_shares_locally
success $"$base shutdown"
echo
return 0
}

restart () {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
;;
esac

exit $?

Mount Shares Locally

2013-08-05T07:42:03Z

Inquam: /* Updated script for Greyhole users */

{{MessageBox|
backgroundcolor = #faa|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

<b>NOTE:</b> Recommend not using copy and paste for the steps below. It often introduces hidden characters which causes failure in the script.

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

== Download and Setup ==

* As '''root:''' Install the mount_shares_locally initd script:
=== On Ubuntu ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
sudo apt-get install cifs-utils curl
sudo curl -o /etc/init.d/mount_shares_locally http://dl.amahi.org/mount_shares_locally
sudo chmod +x /etc/init.d/mount_shares_locally
sudo update-rc.d mount_shares_locally defaults
</div>

=== On Fedora ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

== Configuration ==

* Edit /etc/init.d/mount_shares_locally (as user root) in a text editor, and replace ''your_username'' (on line 12) with your username. Example '''username="amahi"'''
{{Code|Code= nano /etc/init.d/mount_shares_locally}}
* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
{{Code|Code= nano /home/YourHDA_username/.smb_credentials}}
*Enter the following:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>
'''NOTE:''' your_username and your_password in the .smb_credentials file needs to be the original username and password you created when you installed fedora.

*To test your new mounts, you can execute '''service mount_shares_locally start''' (as root user)<br/>

'''service mount_shares_locally stop''' (as root user) will unmount the local shares.<br/>

'''NOTE:''' If you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now (<u>DO NOT</u> remove the drive mount lines). The above initd script replaces all this.

== Re-mount to Add new shares ==
If you added new share to greyhole via the web admin. This does not automatically mount locally. You need to restart your mount script by running '''service mount_shares_locally restart'''. This will unmount and remount all your shares, adding all the new shares you added.

== Where everything is mounted ==
You will find the mounted shares in ''/mnt/samba/*''<br/>
For example, your "Pictures" share would be located at '''/mnt/samba/Pictures'''.

<b>NOTE:</b> When working with files on the HDA, access them via this share and <u>NOT</u> the traditional /var/hda/files/pictures location.

== Unable to mount locally after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]

It's easily fixed by installing the missing dependency.

{{Code|yum install cifs-utils}}

Now it should work fine to run

{{Code|/etc/init.d/mount_shares_locally start}}

== MySQL Problems With Newer Versions of Greyhole ==

Since Greyhole moved from SQL Lite to MySQL, you may hit a problem where Greyhole and the mount_shares_locally script both attempt to start before MySQL in bootup, leading to the services not starting properly. If this happens, you can try this to fix it:

{{Code|ls /etc/rc.d/rc3.d/}}
* Look for any entries marked S-1. If there are any, they need to be removed. Run the following as root:

{{Code|rm S-1*}}

== Updated script for Greyhole users ==

Some apps used by Amahi are used to download files etc. Often we want these files to end up in our shares. Let's say that SickBeard is used to download TV episodes. You then have to configure SickBeard to place your new episode somewhere. A logical place is to save to the landing zone of your Greyhole share which could be ''/var/hda/files/TV''. There are two downsides to this though.

* Greyhole is not notified of the fact that a file is added and only discovers it and makes it available in your share after a ''fsck'', which could take a long time.
* Files deleted through apps in this folder don't register a ''delete'' event that Greyhole can pick up and thus only the symlink in the landing zone is removed. The actual file copies remain on disc. Similarly users running Plex Media Server for example will have issues if the clients are allowed to ''delete contents'' and the server is configured to work on the landing zone. I described this issue when packaging Plex a long time ago here: https://wiki.amahi.org/index.php/Plex_Media_Server

Since Greyhole uses Samba as a layer between the user and itself we would like to keep our writes and deletes to the shares and not the actual landing zone. But since apps (most of them) run as the user ''apache'' it will not be able to access ''/mnt/samba'' which is the default mount point if you set up ''mount_shares_locally''. This following script retains the function of the original script but also adds a second mount point under ''/mnt/apache'' where the ''apache'' user will have read and write access. I have kept it simple and it will use the same credentials as the ''main'' mount. So only shares available to that user will ea available for apache.

By doing this apache will now have a place where it is allowed to read and write files to your shares and SickBeard can thus be configured to place the new episode in ''/mnt/apache/TV'' which is the instantly picked up by Greyhole and file copies distributed to the discs in your pool as configured.

Note that this script is based of the Greyhole original one and uses ''/etc/samba/smb.conf'' as the source of your shares and does not load the shares from the database like the old HDA version of the script did. If that behaviour is desired that can be easily added by replacing the lines

testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p

with

mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p

### BEGIN INIT INFO
# Provides: mount_shares_locally
# Required-Start: $network $local_fs $remote_fs smb mysqld
# Required-Stop: $network $local_fs $remote_fs smb
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mount Samba shares locally
### END INIT INFO

username="YOURUSERHERE"

if [ -f /etc/rc.d/init.d/functions ]; then
. /etc/rc.d/init.d/functions
fi

start () {
uid=`id -u $username`
gid=`id -g $username`

echo -n $"Mounting Samba shares locally: "
mkdir -p /mnt/samba/
mkdir -p /mnt/apache/
cd /mnt/apache/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
cd /mnt/samba/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
sleep 5
ls -1 | while read d; do
/sbin/mount.cifs "//127.0.0.1/$d" "$d" -o credentials=/home/${username}/.smb_credentials,uid=${uid},gid=${gid},file_mode=0660,dir_mode=0770,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
/sbin/mount.cifs "//127.0.0.1/$d" "/mnt/apache/$d" -o credentials=/home/${username}/.smb_credentials,uid=`id -u apache`,gid=`id -g apache`,file_mode=0777,dir_mode=0777,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
done
touch /var/lock/subsys/mount_shares_locally
success $"$base startup"
echo
return 0
}

stop () {
echo -n $"Unmounting locally mounted Samba shares: "
/bin/umount -l /mnt/samba/*
/bin/umount -l /mnt/apache/*
rm -f /var/lock/subsys/mount_shares_locally
success $"$base shutdown"
echo
return 0
}

restart () {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
;;
esac

exit $?

Mount Shares Locally

2013-08-05T07:40:47Z

Inquam: /* Updated script for Greyhole users */

{{MessageBox|
backgroundcolor = #faa|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

<b>NOTE:</b> Recommend not using copy and paste for the steps below. It often introduces hidden characters which causes failure in the script.

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

== Download and Setup ==

* As '''root:''' Install the mount_shares_locally initd script:
=== On Ubuntu ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
sudo apt-get install cifs-utils curl
sudo curl -o /etc/init.d/mount_shares_locally http://dl.amahi.org/mount_shares_locally
sudo chmod +x /etc/init.d/mount_shares_locally
sudo update-rc.d mount_shares_locally defaults
</div>

=== On Fedora ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

== Configuration ==

* Edit /etc/init.d/mount_shares_locally (as user root) in a text editor, and replace ''your_username'' (on line 12) with your username. Example '''username="amahi"'''
{{Code|Code= nano /etc/init.d/mount_shares_locally}}
* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
{{Code|Code= nano /home/YourHDA_username/.smb_credentials}}
*Enter the following:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>
'''NOTE:''' your_username and your_password in the .smb_credentials file needs to be the original username and password you created when you installed fedora.

*To test your new mounts, you can execute '''service mount_shares_locally start''' (as root user)<br/>

'''service mount_shares_locally stop''' (as root user) will unmount the local shares.<br/>

'''NOTE:''' If you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now (<u>DO NOT</u> remove the drive mount lines). The above initd script replaces all this.

== Re-mount to Add new shares ==
If you added new share to greyhole via the web admin. This does not automatically mount locally. You need to restart your mount script by running '''service mount_shares_locally restart'''. This will unmount and remount all your shares, adding all the new shares you added.

== Where everything is mounted ==
You will find the mounted shares in ''/mnt/samba/*''<br/>
For example, your "Pictures" share would be located at '''/mnt/samba/Pictures'''.

<b>NOTE:</b> When working with files on the HDA, access them via this share and <u>NOT</u> the traditional /var/hda/files/pictures location.

== Unable to mount locally after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]

It's easily fixed by installing the missing dependency.

{{Code|yum install cifs-utils}}

Now it should work fine to run

{{Code|/etc/init.d/mount_shares_locally start}}

== MySQL Problems With Newer Versions of Greyhole ==

Since Greyhole moved from SQL Lite to MySQL, you may hit a problem where Greyhole and the mount_shares_locally script both attempt to start before MySQL in bootup, leading to the services not starting properly. If this happens, you can try this to fix it:

{{Code|ls /etc/rc.d/rc3.d/}}
* Look for any entries marked S-1. If there are any, they need to be removed. Run the following as root:

{{Code|rm S-1*}}

== Updated script for Greyhole users ==

Some apps used by Amahi are used to download files etc. Often we want these files to end up in our shares. Let's say that SickBeard is used to download TV episodes. You then have to configure SickBeard to place your new episode somewhere. A logical place is to save to the landing zone of your Greyhole share which could be ''/var/hda/files/TV''. There are two downsides to this though.

* Greyhole is not notified of the fact that a file is added and only discovers it and makes it available in your share after a ''fsck'', which could take a long time.
* Files deleted through apps in this folder don't register a ''delete'' event that Greyhole can pick up and thus only the symlink in the landing zone is removed. The actual file copies remain on disc. Similarly users running Plex Media Server for example will have issues if the clients are allowed to ''delete contents'' and the server is configured to work on the landing zone. I described this issue when packaging Plex a long time ago here: https://wiki.amahi.org/index.php/Plex_Media_Server

Since Greyhole uses Samba as a layer between the user and itself we would like to keep our writes and deletes to the shares and not the actual landing zone. But since apps (most of them) run as the users ''apache'' it will not be able to access ''/mnt/samba'' which is the default mount point if you set up ''mount_shares_locally''. This following script retains the function of the original script but also adds a second mount point under ''/mnt/apache'' where the ''apache'' user will have read and write access. I have kept it simple and it will use the same credentials as the ''main'' mount. So only shares available to that user will ea available for apache.

By doing this apache will now have a place where it is allowed to read and write files to your shares and SickBeard can thus be configured to place the new episode in ''/mnt/apache/TV'' which is the instantly picked up by Greyhole and file copies distributed to the discs in your pool as configured.

Note that this script is based of the Greyhole original one and uses ''/etc/samba/smb.conf'' as the source of your shares and does not load the shares from the database like the old HDA version of the script did. If that behaviour is desired that can be easily added by replacing the lines

testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p

with

mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p

### BEGIN INIT INFO
# Provides: mount_shares_locally
# Required-Start: $network $local_fs $remote_fs smb mysqld
# Required-Stop: $network $local_fs $remote_fs smb
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mount Samba shares locally
### END INIT INFO

username="YOURUSERHERE"

if [ -f /etc/rc.d/init.d/functions ]; then
. /etc/rc.d/init.d/functions
fi

start () {
uid=`id -u $username`
gid=`id -g $username`

echo -n $"Mounting Samba shares locally: "
mkdir -p /mnt/samba/
mkdir -p /mnt/apache/
cd /mnt/apache/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
cd /mnt/samba/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
sleep 5
ls -1 | while read d; do
/sbin/mount.cifs "//127.0.0.1/$d" "$d" -o credentials=/home/${username}/.smb_credentials,uid=${uid},gid=${gid},file_mode=0660,dir_mode=0770,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
/sbin/mount.cifs "//127.0.0.1/$d" "/mnt/apache/$d" -o credentials=/home/${username}/.smb_credentials,uid=`id -u apache`,gid=`id -g apache`,file_mode=0777,dir_mode=0777,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
done
touch /var/lock/subsys/mount_shares_locally
success $"$base startup"
echo
return 0
}

stop () {
echo -n $"Unmounting locally mounted Samba shares: "
/bin/umount -l /mnt/samba/*
/bin/umount -l /mnt/apache/*
rm -f /var/lock/subsys/mount_shares_locally
success $"$base shutdown"
echo
return 0
}

restart () {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
;;
esac

exit $?

Mount Shares Locally

2013-08-05T07:37:57Z

Inquam: Added description of an updated version of the script to allow apache to write to locally mounted shares to facilitate easier use for apps

{{MessageBox|
backgroundcolor = #faa|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

<b>NOTE:</b> Recommend not using copy and paste for the steps below. It often introduces hidden characters which causes failure in the script.

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

== Download and Setup ==

* As '''root:''' Install the mount_shares_locally initd script:
=== On Ubuntu ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
sudo apt-get install cifs-utils curl
sudo curl -o /etc/init.d/mount_shares_locally http://dl.amahi.org/mount_shares_locally
sudo chmod +x /etc/init.d/mount_shares_locally
sudo update-rc.d mount_shares_locally defaults
</div>

=== On Fedora ===
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

== Configuration ==

* Edit /etc/init.d/mount_shares_locally (as user root) in a text editor, and replace ''your_username'' (on line 12) with your username. Example '''username="amahi"'''
{{Code|Code= nano /etc/init.d/mount_shares_locally}}
* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
{{Code|Code= nano /home/YourHDA_username/.smb_credentials}}
*Enter the following:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>
'''NOTE:''' your_username and your_password in the .smb_credentials file needs to be the original username and password you created when you installed fedora.

*To test your new mounts, you can execute '''service mount_shares_locally start''' (as root user)<br/>

'''service mount_shares_locally stop''' (as root user) will unmount the local shares.<br/>

'''NOTE:''' If you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now (<u>DO NOT</u> remove the drive mount lines). The above initd script replaces all this.

== Re-mount to Add new shares ==
If you added new share to greyhole via the web admin. This does not automatically mount locally. You need to restart your mount script by running '''service mount_shares_locally restart'''. This will unmount and remount all your shares, adding all the new shares you added.

== Where everything is mounted ==
You will find the mounted shares in ''/mnt/samba/*''<br/>
For example, your "Pictures" share would be located at '''/mnt/samba/Pictures'''.

<b>NOTE:</b> When working with files on the HDA, access them via this share and <u>NOT</u> the traditional /var/hda/files/pictures location.

== Unable to mount locally after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]

It's easily fixed by installing the missing dependency.

{{Code|yum install cifs-utils}}

Now it should work fine to run

{{Code|/etc/init.d/mount_shares_locally start}}

== MySQL Problems With Newer Versions of Greyhole ==

Since Greyhole moved from SQL Lite to MySQL, you may hit a problem where Greyhole and the mount_shares_locally script both attempt to start before MySQL in bootup, leading to the services not starting properly. If this happens, you can try this to fix it:

{{Code|ls /etc/rc.d/rc3.d/}}
* Look for any entries marked S-1. If there are any, they need to be removed. Run the following as root:

{{Code|rm S-1*}}

== Updated script for Greyhole users ==

Some apps used by Amahi are used to download files etc. Often we want these files to end up in our shares. Let's say that SickBeard is used to download TV episodes. You then have to configure SickBeard to place your new episode somewhere. A logical place is to save to the landing zone of your Greyhole share which could be ''/var/hda/files/TV''. There are two downsides to this though.

* Greyhole is not notified of the fact that a file is added and only discovers it and makes it available in your share after a ''fsck''
* Files deleted through apps in this folder don't register a ''delete'' event that Greyhole can pick up and thus only the symlink in the landing zone is removed. The actual file copies remain in disc. Similarly users running Plex Media Server for example will have issues if the clients are allowed to ''delete contents'' and the server is configured to work on the landing zone. I described this issue when packaging Plex a long time ago here: https://wiki.amahi.org/index.php/Plex_Media_Server

Since Greyhole uses Samba as a layer between the user and itself we would like to keep our writes and deletes to the shares and not the actual landing zone. But since apps (most of them) run as the users ''apache'' it will not be able to access ''/mnt/samba'' which is the default mount point if you set up ''mount_shares_locally''. This following script retains the function of the original script but also adds a second mount point under ''/mnt/apache'' where the ''apache'' user will have read and write access. I have kept it simple and it will use the same credentials as the ''main'' mount. So only shares available to that user will ea available for apache.

By doing this apache will now have a place where it is allowed to read and write files to your shares and SickBeard can thus be configured to place the new episode in ''/mnt/apache/TV'' which is the instantly picked up by Greyhole and file copies distributed to the discs in your pool as configured.

Note that this script is based of the Greyhole original one and uses ''/etc/samba/smb.conf'' as the source of your shares and does not load the shares from the database like the old HDA version of the script did. If that behaviour is desired that can be easily added by replacing the lines

testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p

with

mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p

### BEGIN INIT INFO
# Provides: mount_shares_locally
# Required-Start: $network $local_fs $remote_fs smb mysqld
# Required-Stop: $network $local_fs $remote_fs smb
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mount Samba shares locally
### END INIT INFO

username="YOURUSERHERE"

if [ -f /etc/rc.d/init.d/functions ]; then
. /etc/rc.d/init.d/functions
fi

start () {
uid=`id -u $username`
gid=`id -g $username`

echo -n $"Mounting Samba shares locally: "
mkdir -p /mnt/samba/
mkdir -p /mnt/apache/
cd /mnt/apache/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
cd /mnt/samba/
testparm -s /etc/samba/smb.conf 2>/dev/null | grep "^\[" | grep -v "\[global\]" | grep -v "\[homes\]" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | xargs -d "\n" mkdir -p
sleep 5
ls -1 | while read d; do
/sbin/mount.cifs "//127.0.0.1/$d" "$d" -o credentials=/home/${username}/.smb_credentials,uid=${uid},gid=${gid},file_mode=0660,dir_mode=0770,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
/sbin/mount.cifs "//127.0.0.1/$d" "/mnt/apache/$d" -o credentials=/home/${username}/.smb_credentials,uid=`id -u apache`,gid=`id -g apache`,file_mode=0777,dir_mode=0777,nobrl,hard,_netdev,iocharset=utf8,noserverino,mfsymlinks
done
touch /var/lock/subsys/mount_shares_locally
success $"$base startup"
echo
return 0
}

stop () {
echo -n $"Unmounting locally mounted Samba shares: "
/bin/umount -l /mnt/samba/*
/bin/umount -l /mnt/apache/*
rm -f /var/lock/subsys/mount_shares_locally
success $"$base shutdown"
echo
return 0
}

restart () {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
;;
esac

exit $?

File:Plex media server screenshot 320x240.png

2011-08-26T08:16:10Z

Inquam:

File:Plex media server logo 160x120.png

2011-08-26T08:15:12Z

Inquam:

File:Plex-Interface.png

2011-08-22T08:46:22Z

Inquam:

File:Plex-Logo.gif

2011-08-22T08:42:06Z

Inquam:

Make Samba Go Faster

2011-08-11T11:34:12Z

Inquam:

{{MessageBox|
backgroundcolor = red|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

==Background==

Amahi makes heavy use of Samba. Samba is what handles shared folders and allow you to connect to your Amahi and browse your folders from Windows etc.
Greyhole also uses Samba and it's logs to handle file operations.

After installing a wired gigabit network in my house, due to the WIFI being bogged down by 14 wireless clients, I tested the performance in the network. I got around 500-600MBit/sec in read speeds and about 600-700MBit/sec in write speeds. But when I tried against the Amahi server I found that I only got 56MBit/sec in read speeds.

After looking at the samba configuration file I saw that Async IO ('''AIO''') was not enabled by Amahi. What AIO does is that it let's Samba handle several file operations asynchronously. This can, at the expense of some CPU cycles, increase the performance quite a lot.

I increased the read speed to 500-600MBit/sec by enabling AIO and saw Samba using around 1-4% CPU on a Intel E2200.

==Enable AIO==

To enable AIO an you can add the following to the '''global''' section of your '''/etc/samba/smb.conf''' file

{{Text|Text=
socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
min receivefile size = 16384
use sendfile = true
aio read size = 16384
aio write size = 16384
aio write behind = true <--- NOTE!!!: Only use with extreme caution. Read explanation bellow
}}

This is only an example but you can tweak all the options to fit your environment and needs. Bellow are an explination of the options used above. More information can be found at http://www.samba.org

==Options Explained==

===min receivefile size===
This option changes the behavior of Samba when processing SMBwriteX calls. Any incoming SMBwriteX call on a non-signed SMB/CIFS connection greater than this value will not be processed in the normal way but will be passed to any underlying kernel recvfile or splice system call (if there is no such call Samba will emulate in user space). This allows zero-copy writes directly from network socket buffers into the filesystem buffer cache, if available. It may improve performance but user testing is recommended. If set to zero Samba processes SMBwriteX calls in the normal way. To enable POSIX large write support (SMB/CIFS writes up to 16Mb) this option must be nonzero. The maximum value is 128k. Values greater than 128k will be silently set to 128k.

Note this option will have NO EFFECT if set on a SMB signed connection.

The default is zero, which disables this option

===use sendfile===
If this parameter is yes, and the sendfile() system call is supported by the underlying operating system, then some SMB read calls (mainly ReadAndX and ReadRaw) will use the more efficient sendfile system call for files that are exclusively oplocked. This may make more efficient use of the system CPU's and cause Samba to be faster. Samba automatically turns this off for clients that use protocol levels lower than NT LM 0.12 and when it detects a client is Windows 9x (using sendfile from Linux will cause these clients to fail).

===socket options===
This option allows you to set socket options to be used when talking with the client.

Socket options are controls on the networking layer of the operating systems which allow the connection to be tuned.

This option will typically be used to tune your Samba server for optimal performance for your local network. There is no way that Samba can know what the optimal parameters are for your net, so you must experiment and choose them yourself. We strongly suggest you read the appropriate documentation for your operating system first (perhaps man setsockopt will help).

You may find that on some systems Samba will say "Unknown socket option" when you supply an option. This means you either incorrectly typed it or you need to add an include file to includes.h for your OS. If the latter is the case please send the patch to samba-technical@samba.org.

Any of the supported socket options may be combined in any way you like, as long as your OS allows it.

This is the list of socket options currently settable using this option:

* SO_KEEPALIVE
* SO_REUSEADDR
* SO_BROADCAST
* TCP_NODELAY
* IPTOS_LOWDELAY
* IPTOS_THROUGHPUT
* SO_SNDBUF *
* SO_RCVBUF *
* SO_SNDLOWAT *
* SO_RCVLOWAT *

''Those marked with a '*' take an integer argument. The others can optionally take a 1 or 0 argument to enable or disable the option, by default they will be enabled if you don't specify 1 or 0.''

To specify an argument use the syntax SOME_OPTION = VALUE for example SO_SNDBUF = 8192. Note that you must not have any spaces before or after the = sign.

If you are on a local network then a sensible option might be:

{{Text|Text=socket options = IPTOS_LOWDELAY}}

If you have a local network then you could try:

{{Text|Text=socket options = IPTOS_LOWDELAY TCP_NODELAY}}

If you are on a wide area network then perhaps try setting IPTOS_THROUGHPUT.

Note that several of the options may cause your Samba server to fail completely. '''Use these options with caution!'''

===aio read size===
Samba will read from file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write size===
Samba will write to file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write behind===
Samba will not wait until write requests are finished before returning the result to the client for files listed in this parameter. Instead, Samba will immediately return that the write request has been finished successfully, no matter if the operation will succeed or not. This might speed up clients without aio support, but is really dangerous, because data could be lost and files could be damaged.

==Things to Note==
'''It can not be under stressed. Bad options can be very BAD. It can corrupt your data and make you very sad. Use extreme caution if experimenting with the options!'''

If you add a new share in Amahi or change the settings of an existing one, Amahi will overwrite the '''/etc/samba/smb.conf''' file with the new configuration and thus removing your changes. A place to enable '''AIO''' in the settings section of Amahi has been suggested at http://bugs.amahi.org/issues/show/861

Make Samba Go Faster

2011-08-11T11:26:39Z

Inquam:

{{MessageBox|
backgroundcolor = red|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

==Background==

Amahi makes heavy use of Samba. Samba is what handles shared folders and allow you to connect to your Amahi and browse your folders from Windows etc.
Greyhole also uses Samba and it's logs to handle file operations.

After installing a wired gigabit network in my house, due to the WIFI being bogged down by 14 wireless clients, I tested the performance in the network. I got around 500-600MBit/sec in read speeds and about 600-700MBit/sec in write speeds. But when I tried against the Amahi server I found that I only got 56MBit/sec in read speeds.

After looking at the samba configuration file I saw that Async IO ('''AIO''') was not enabled by Amahi. What AIO does is that it let's Samba handle several file operations asynchronously. This can, at the expense of some CPU cycles, increase the performance quite a lot.

I increased the read speed to 500-600MBit/sec by enabling AIO and saw Samba using around 1-4% CPU on a Intel E2200.

==Enable AIO==

To enable AIO an you can add the following to the '''global''' section of your '''/etc/samba/smb.conf''' file

{{Text|Text=
socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
min receivefile size = 16384
use sendfile = true
aio read size = 16384
aio write size = 16384
aio write behind = true <--- NOTE!!!: Only use with extreme caution. Read explanation bellow
}}

This is only an example but you can tweak all the options to fit your environment and needs. Bellow are an explination of the options used above. More information can be found at http://www.samba.org

==Options Explained==

===min receivefile size===
This option changes the behavior of Samba when processing SMBwriteX calls. Any incoming SMBwriteX call on a non-signed SMB/CIFS connection greater than this value will not be processed in the normal way but will be passed to any underlying kernel recvfile or splice system call (if there is no such call Samba will emulate in user space). This allows zero-copy writes directly from network socket buffers into the filesystem buffer cache, if available. It may improve performance but user testing is recommended. If set to zero Samba processes SMBwriteX calls in the normal way. To enable POSIX large write support (SMB/CIFS writes up to 16Mb) this option must be nonzero. The maximum value is 128k. Values greater than 128k will be silently set to 128k.

Note this option will have NO EFFECT if set on a SMB signed connection.

The default is zero, which disables this option

===use sendfile===
If this parameter is yes, and the sendfile() system call is supported by the underlying operating system, then some SMB read calls (mainly ReadAndX and ReadRaw) will use the more efficient sendfile system call for files that are exclusively oplocked. This may make more efficient use of the system CPU's and cause Samba to be faster. Samba automatically turns this off for clients that use protocol levels lower than NT LM 0.12 and when it detects a client is Windows 9x (using sendfile from Linux will cause these clients to fail).

===socket options===
This option allows you to set socket options to be used when talking with the client.

Socket options are controls on the networking layer of the operating systems which allow the connection to be tuned.

This option will typically be used to tune your Samba server for optimal performance for your local network. There is no way that Samba can know what the optimal parameters are for your net, so you must experiment and choose them yourself. We strongly suggest you read the appropriate documentation for your operating system first (perhaps man setsockopt will help).

You may find that on some systems Samba will say "Unknown socket option" when you supply an option. This means you either incorrectly typed it or you need to add an include file to includes.h for your OS. If the latter is the case please send the patch to samba-technical@samba.org.

Any of the supported socket options may be combined in any way you like, as long as your OS allows it.

This is the list of socket options currently settable using this option:

* SO_KEEPALIVE
* SO_REUSEADDR
* SO_BROADCAST
* TCP_NODELAY
* IPTOS_LOWDELAY
* IPTOS_THROUGHPUT
* SO_SNDBUF *
* SO_RCVBUF *
* SO_SNDLOWAT *
* SO_RCVLOWAT *

''Those marked with a '*' take an integer argument. The others can optionally take a 1 or 0 argument to enable or disable the option, by default they will be enabled if you don't specify 1 or 0.''

To specify an argument use the syntax SOME_OPTION = VALUE for example SO_SNDBUF = 8192. Note that you must not have any spaces before or after the = sign.

If you are on a local network then a sensible option might be:

{{Text|Text=socket options = IPTOS_LOWDELAY}}

If you have a local network then you could try:

{{Text|Text=socket options = IPTOS_LOWDELAY TCP_NODELAY}}

If you are on a wide area network then perhaps try setting IPTOS_THROUGHPUT.

Note that several of the options may cause your Samba server to fail completely. '''Use these options with caution!'''

===aio read size===
Samba will read from file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write size===
Samba will write to file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write behind===
Samba will not wait until write requests are finished before returning the result to the client for files listed in this parameter. Instead, Samba will immediately return that the write request has been finished successfully, no matter if the operation will succeed or not. This might speed up clients without aio support, but is really dangerous, because data could be lost and files could be damaged.

==Things to Note==
'''It can not be under stressed. Bad options can be very BAD. It can corrupt your data and make you very sad. Use extreme caution if elaborating with the options!'''

If you add a new share in Amahi or change the settings of an existing one, Amahi will overwrite the '''/etc/samba/smb.conf''' file with the new configuration and thus removing your changes. A place to enable '''AIO''' in the settings section of Amahi has been suggested at http://bugs.amahi.org/issues/show/861

Make Samba Go Faster

2011-08-11T11:25:26Z

Inquam:

{{MessageBox|
backgroundcolor = red|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

==Background==

Amahi makes heavy use of Samba. Samba is what handles shared folders and allow you to connect to your Amahi and browse your folders from Windows etc.
Greyhole also uses Samba and it's logs to handle file operations.

After installing a wired gigabit network in my house, due to the WIFI being bogged down by 14 wireless clients, I tested the performance in the network. I got around 500-600MBit/sec in read speeds and about 600-700MBit/sec in write speeds. But when I tried against the Amahi server I found that I only got 56MBit/sec in read speeds.

After looking at the samba configuration file I saw that Async IO ('''AIO''') was not enabled by Amahi. What AIO does is that it let's Samba create multiple threads to handle file operations. This can, at the expense of some CPU cycles, increase the performance quite a lot.

I increased the read speed to 500-600MBit/sec by enabling AIO and saw Samba using around 1-4% CPU on a Intel E2200.

==Enable AIO==

To enable AIO an you can add the following to the '''global''' section of your '''/etc/samba/smb.conf''' file

{{Text|Text=
socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
min receivefile size = 16384
use sendfile = true
aio read size = 16384
aio write size = 16384
aio write behind = true <--- NOTE!!!: Only use with extreme caution. Read explanation bellow
}}

This is only an example but you can tweak all the options to fit your environment and needs. Bellow are an explination of the options used above. More information can be found at http://www.samba.org

==Options Explained==

===min receivefile size===
This option changes the behavior of Samba when processing SMBwriteX calls. Any incoming SMBwriteX call on a non-signed SMB/CIFS connection greater than this value will not be processed in the normal way but will be passed to any underlying kernel recvfile or splice system call (if there is no such call Samba will emulate in user space). This allows zero-copy writes directly from network socket buffers into the filesystem buffer cache, if available. It may improve performance but user testing is recommended. If set to zero Samba processes SMBwriteX calls in the normal way. To enable POSIX large write support (SMB/CIFS writes up to 16Mb) this option must be nonzero. The maximum value is 128k. Values greater than 128k will be silently set to 128k.

Note this option will have NO EFFECT if set on a SMB signed connection.

The default is zero, which disables this option

===use sendfile===
If this parameter is yes, and the sendfile() system call is supported by the underlying operating system, then some SMB read calls (mainly ReadAndX and ReadRaw) will use the more efficient sendfile system call for files that are exclusively oplocked. This may make more efficient use of the system CPU's and cause Samba to be faster. Samba automatically turns this off for clients that use protocol levels lower than NT LM 0.12 and when it detects a client is Windows 9x (using sendfile from Linux will cause these clients to fail).

===socket options===
This option allows you to set socket options to be used when talking with the client.

Socket options are controls on the networking layer of the operating systems which allow the connection to be tuned.

This option will typically be used to tune your Samba server for optimal performance for your local network. There is no way that Samba can know what the optimal parameters are for your net, so you must experiment and choose them yourself. We strongly suggest you read the appropriate documentation for your operating system first (perhaps man setsockopt will help).

You may find that on some systems Samba will say "Unknown socket option" when you supply an option. This means you either incorrectly typed it or you need to add an include file to includes.h for your OS. If the latter is the case please send the patch to samba-technical@samba.org.

Any of the supported socket options may be combined in any way you like, as long as your OS allows it.

This is the list of socket options currently settable using this option:

* SO_KEEPALIVE
* SO_REUSEADDR
* SO_BROADCAST
* TCP_NODELAY
* IPTOS_LOWDELAY
* IPTOS_THROUGHPUT
* SO_SNDBUF *
* SO_RCVBUF *
* SO_SNDLOWAT *
* SO_RCVLOWAT *

''Those marked with a '*' take an integer argument. The others can optionally take a 1 or 0 argument to enable or disable the option, by default they will be enabled if you don't specify 1 or 0.''

To specify an argument use the syntax SOME_OPTION = VALUE for example SO_SNDBUF = 8192. Note that you must not have any spaces before or after the = sign.

If you are on a local network then a sensible option might be:

{{Text|Text=socket options = IPTOS_LOWDELAY}}

If you have a local network then you could try:

{{Text|Text=socket options = IPTOS_LOWDELAY TCP_NODELAY}}

If you are on a wide area network then perhaps try setting IPTOS_THROUGHPUT.

Note that several of the options may cause your Samba server to fail completely. '''Use these options with caution!'''

===aio read size===
Samba will read from file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write size===
Samba will write to file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write behind===
Samba will not wait until write requests are finished before returning the result to the client for files listed in this parameter. Instead, Samba will immediately return that the write request has been finished successfully, no matter if the operation will succeed or not. This might speed up clients without aio support, but is really dangerous, because data could be lost and files could be damaged.

==Things to Note==
'''It can not be under stressed. Bad options can be very BAD. It can corrupt your data and make you very sad. Use extreme caution if elaborating with the options!'''

If you add a new share in Amahi or change the settings of an existing one, Amahi will overwrite the '''/etc/samba/smb.conf''' file with the new configuration and thus removing your changes. A place to enable '''AIO''' in the settings section of Amahi has been suggested at http://bugs.amahi.org/issues/show/861

Make Samba Go Faster

2011-08-11T11:23:03Z

Inquam:

{{MessageBox|
backgroundcolor = red|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

==Background==

Amahi makes heavy use of Samba. Samba is what handles shared folders and allow you to connect to your Amahi and browse your folders from Windows etc.
Greyhole also uses Samba and it's logs to handle file operations.

After installing a wired gigabit network in my house, due to the WIFI being bogged down by 14 wireless clients, I tested the performance in the network. I got around 5-600MBit/sec in read speeds and about 6-700MBit/sec in write speeds. But when I tried against the Amahi server I found that I only got 56MBit/sec in read speeds.

After looking at the samba configuration file I saw that Async IO ('''AIO''') was not enabled by Amahi. What AIO does is that it let's Samba create multiple threads to handle file operations. This can, at the expense of some CPU cycles, increase the performance quite a lot.

I increased the read speed to 500-600MBit/sec by enabling AIO and saw Samba using around 1-4% CPU on a Intel E2200.

==Enable AIO==

To enable AIO an you can add the following to the '''global''' section of your '''/etc/samba/smb.conf''' file

{{Text|Text=
socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
min receivefile size = 16384
use sendfile = true
aio read size = 16384
aio write size = 16384
aio write behind = true <--- NOTE!!!: Only use with extreme caution. Read explanation bellow
}}

This is only an example but you can tweak all the options to fit your environment and needs. Bellow are an explination of the options used above. More information can be found at http://www.samba.org

==Options Explained==

===min receivefile size===
This option changes the behavior of Samba when processing SMBwriteX calls. Any incoming SMBwriteX call on a non-signed SMB/CIFS connection greater than this value will not be processed in the normal way but will be passed to any underlying kernel recvfile or splice system call (if there is no such call Samba will emulate in user space). This allows zero-copy writes directly from network socket buffers into the filesystem buffer cache, if available. It may improve performance but user testing is recommended. If set to zero Samba processes SMBwriteX calls in the normal way. To enable POSIX large write support (SMB/CIFS writes up to 16Mb) this option must be nonzero. The maximum value is 128k. Values greater than 128k will be silently set to 128k.

Note this option will have NO EFFECT if set on a SMB signed connection.

The default is zero, which disables this option

===use sendfile===
If this parameter is yes, and the sendfile() system call is supported by the underlying operating system, then some SMB read calls (mainly ReadAndX and ReadRaw) will use the more efficient sendfile system call for files that are exclusively oplocked. This may make more efficient use of the system CPU's and cause Samba to be faster. Samba automatically turns this off for clients that use protocol levels lower than NT LM 0.12 and when it detects a client is Windows 9x (using sendfile from Linux will cause these clients to fail).

===socket options===
This option allows you to set socket options to be used when talking with the client.

Socket options are controls on the networking layer of the operating systems which allow the connection to be tuned.

This option will typically be used to tune your Samba server for optimal performance for your local network. There is no way that Samba can know what the optimal parameters are for your net, so you must experiment and choose them yourself. We strongly suggest you read the appropriate documentation for your operating system first (perhaps man setsockopt will help).

You may find that on some systems Samba will say "Unknown socket option" when you supply an option. This means you either incorrectly typed it or you need to add an include file to includes.h for your OS. If the latter is the case please send the patch to samba-technical@samba.org.

Any of the supported socket options may be combined in any way you like, as long as your OS allows it.

This is the list of socket options currently settable using this option:

* SO_KEEPALIVE
* SO_REUSEADDR
* SO_BROADCAST
* TCP_NODELAY
* IPTOS_LOWDELAY
* IPTOS_THROUGHPUT
* SO_SNDBUF *
* SO_RCVBUF *
* SO_SNDLOWAT *
* SO_RCVLOWAT *

''Those marked with a '*' take an integer argument. The others can optionally take a 1 or 0 argument to enable or disable the option, by default they will be enabled if you don't specify 1 or 0.''

To specify an argument use the syntax SOME_OPTION = VALUE for example SO_SNDBUF = 8192. Note that you must not have any spaces before or after the = sign.

If you are on a local network then a sensible option might be:

{{Text|Text=socket options = IPTOS_LOWDELAY}}

If you have a local network then you could try:

{{Text|Text=socket options = IPTOS_LOWDELAY TCP_NODELAY}}

If you are on a wide area network then perhaps try setting IPTOS_THROUGHPUT.

Note that several of the options may cause your Samba server to fail completely. '''Use these options with caution!'''

===aio read size===
Samba will read from file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write size===
Samba will write to file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write behind===
Samba will not wait until write requests are finished before returning the result to the client for files listed in this parameter. Instead, Samba will immediately return that the write request has been finished successfully, no matter if the operation will succeed or not. This might speed up clients without aio support, but is really dangerous, because data could be lost and files could be damaged.

==Things to Note==
'''It can not be under stressed. Bad options can be very BAD. It can corrupt your data and make you very sad. Use extreme caution if elaborating with the options!'''

If you add a new share in Amahi or change the settings of an existing one, Amahi will overwrite the '''/etc/samba/smb.conf''' file with the new configuration and thus removing your changes. A place to enable '''AIO''' in the settings section of Amahi has been suggested at http://bugs.amahi.org/issues/show/861

Make Samba Go Faster

2011-08-11T11:16:57Z

Inquam: Created page with "{{MessageBox| backgroundcolor = red| image =Warning.png| heading =WARNING| message = This is recommended only for advanced users, proceed with caution.}} ==Background== Amahi m..."

{{MessageBox|
backgroundcolor = red|
image =Warning.png|
heading =WARNING|
message = This is recommended only for advanced users, proceed with caution.}}

==Background==

Amahi makes heavy use of Samba. Samba is what handles shared folders and allow you to connect to your Amahi and browse your folders from Windows etc.
Greyhole also uses Samba and it's logs to handle file operations.

After installing a wired gigabit network in my house, due to the WIFI being bogged down by 14 wireless clients, I tested the performance in the network. I got around 5-600MBit/sec in read speeds and about 6-700MBit/sec in write speeds. But when I tried against the Amahi server I found that I only got 56MBit/sec in read speeds.

After looking at the samba configuration file I saw that Async IO ('''AIO''') was not enabled by Amahi. What AIO does is that it let's Samba create multiple threads to handle file operations. This can, at the expense of some CPU cycles, increase the performance quite a lot.

==Enable AIO==

To enable AIO an you can add the following to the '''global''' section of your '''/etc/samba/smb.conf''' file

{{Text|Text=
socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
min receivefile size = 16384
use sendfile = true
aio read size = 16384
aio write size = 16384
aio write behind = true <--- NOTE!!!: Only use with extreme caution. Read explanation bellow
}}

This is only an example but you can tweak all the options to fit your environment and needs. Bellow are an explination of the options used above. More information can be found at http://www.samba.org

==Options Explained==

===min receivefile size===
This option changes the behavior of Samba when processing SMBwriteX calls. Any incoming SMBwriteX call on a non-signed SMB/CIFS connection greater than this value will not be processed in the normal way but will be passed to any underlying kernel recvfile or splice system call (if there is no such call Samba will emulate in user space). This allows zero-copy writes directly from network socket buffers into the filesystem buffer cache, if available. It may improve performance but user testing is recommended. If set to zero Samba processes SMBwriteX calls in the normal way. To enable POSIX large write support (SMB/CIFS writes up to 16Mb) this option must be nonzero. The maximum value is 128k. Values greater than 128k will be silently set to 128k.

Note this option will have NO EFFECT if set on a SMB signed connection.

The default is zero, which disables this option

===use sendfile===
If this parameter is yes, and the sendfile() system call is supported by the underlying operating system, then some SMB read calls (mainly ReadAndX and ReadRaw) will use the more efficient sendfile system call for files that are exclusively oplocked. This may make more efficient use of the system CPU's and cause Samba to be faster. Samba automatically turns this off for clients that use protocol levels lower than NT LM 0.12 and when it detects a client is Windows 9x (using sendfile from Linux will cause these clients to fail).

===socket options===
This option allows you to set socket options to be used when talking with the client.

Socket options are controls on the networking layer of the operating systems which allow the connection to be tuned.

This option will typically be used to tune your Samba server for optimal performance for your local network. There is no way that Samba can know what the optimal parameters are for your net, so you must experiment and choose them yourself. We strongly suggest you read the appropriate documentation for your operating system first (perhaps man setsockopt will help).

You may find that on some systems Samba will say "Unknown socket option" when you supply an option. This means you either incorrectly typed it or you need to add an include file to includes.h for your OS. If the latter is the case please send the patch to samba-technical@samba.org.

Any of the supported socket options may be combined in any way you like, as long as your OS allows it.

This is the list of socket options currently settable using this option:

* SO_KEEPALIVE
* SO_REUSEADDR
* SO_BROADCAST
* TCP_NODELAY
* IPTOS_LOWDELAY
* IPTOS_THROUGHPUT
* SO_SNDBUF *
* SO_RCVBUF *
* SO_SNDLOWAT *
* SO_RCVLOWAT *

''Those marked with a '*' take an integer argument. The others can optionally take a 1 or 0 argument to enable or disable the option, by default they will be enabled if you don't specify 1 or 0.''

To specify an argument use the syntax SOME_OPTION = VALUE for example SO_SNDBUF = 8192. Note that you must not have any spaces before or after the = sign.

If you are on a local network then a sensible option might be:

{{Text|Text=socket options = IPTOS_LOWDELAY}}

If you have a local network then you could try:

{{Text|Text=socket options = IPTOS_LOWDELAY TCP_NODELAY}}

If you are on a wide area network then perhaps try setting IPTOS_THROUGHPUT.

Note that several of the options may cause your Samba server to fail completely. '''Use these options with caution!'''

===aio read size===
Samba will read from file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write size===
Samba will write to file asynchronously when size of request is bigger than this value. Note that it happens only for non-chained and non-chaining reads and when not using write cache.

===aio write behind===
Samba will not wait until write requests are finished before returning the result to the client for files listed in this parameter. Instead, Samba will immediately return that the write request has been finished successfully, no matter if the operation will succeed or not. This might speed up clients without aio support, but is really dangerous, because data could be lost and files could be damaged.

==Things to Note==
'''It can not be under stressed. Bad options can be very BAD. It can corrupt your data and make you very sad. Use extreme caution if elaborating with the options!'''

If you add a new share in Amahi or change the settings of an existing one, Amahi will overwrite the '''/etc/samba/smb.conf''' file with the new configuration and thus removing your changes. A place to enable '''AIO''' in the settings section of Amahi has been suggested at

Mount Shares Locally

2011-03-07T06:32:10Z

Inquam: fixed spelling error

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

* Install the mount_shares_locally initd script:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropbox.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

* Edit /etc/init.d/mount_shares_locally in a text editor, and replace ''your_username'' (on line 12) with your username.

* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>

To test your new mounts, you can execute '''service mount_shares_locally start'''<br/>
You will find the mounted shares in ''/mnt/samba/*''<br/>
'''service mount_shares_locally stop''' will unmount the local shares.<br/>

Note: if you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now. The above initd script replaces all this.

== Unable to mount localy after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]

It's easily fixed by installing the missing dependency.

{{Code|yum install cifs-utils}}

Now it should work fine to run

{{Code|/etc/init.d/mount_shares_locally start}}

Mount Shares Locally

2011-03-06T09:20:20Z

Inquam: Added information about possible fix when script stops working after Amahi6 upgrade

Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.

* Install the mount_shares_locally initd script:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll">
curl -o /etc/init.d/mount_shares_locally http://dl.dropbox.com/u/3022105/Amahi/mount_shares_locally
chmod +x /etc/init.d/mount_shares_locally
chkconfig --add mount_shares_locally
</div>

* Edit /etc/init.d/mount_shares_locally in a text editor, and replace ''your_username'' (on line 12) with your username.

* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
username=your_username
password=your_password
domain=HOME
</div>

To test your new mounts, you can execute '''service mount_shares_locally start'''<br/>
You will find the mounted shares in ''/mnt/samba/*''<br/>
'''service mount_shares_locally stop''' will unmount the local shares.<br/>

Note: if you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now. The above initd script replaces all this.

== Unable to mount localy after upgrading to Amahi6 ==
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.

{{Code|
[root@localhost ~]# /etc/init.d/mount_shares_locally start
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory
[ OK ]
}}

It's easily fixed by installing the missing dependency.

{{Code|
yum install cifs-utils
}}

No it should work fine to run

{{Code|
/etc/init.d/mount_shares_locally start
}}