https://wiki.archlinux.org/api.php?action=feedcontributions&user=Xorrr&feedformat=atomArchWiki - User contributions [en]2024-03-28T18:17:44ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Netctl&diff=332020Netctl2014-08-23T14:48:58Z<p>Xorrr: extend troubleshooting when netctl service fails</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network managers]]<br />
[[cs:Netctl]]<br />
[[es:Netctl]]<br />
[[fr:Netctl]]<br />
[[ja:Netctl]]<br />
[[ru:Netctl]]<br />
[[zh-CN:Netctl]]<br />
{{Related articles start}}<br />
{{Related|Bridge with netctl}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network managers}}<br />
{{Related articles end}}<br />
<br />
''netctl'' is a CLI-based tool used to configure and manage network connections via profiles. It is a native Arch Linux project for network configuration.<br />
<br />
== Installation ==<br />
<br />
The {{Pkg|netctl}} package is available in the [[official repositories]].<br />
<br />
Optional dependencies are shown in the table below.<br />
<br />
{| class="wikitable"<br />
! Feature<br />
! Dependency<br />
! netctl program <br /> (if relevant)<br />
|-<br />
| Automatic wireless connections || {{Pkg|wpa_actiond}} || {{ic|netctl-auto}}<br />
|-<br />
| Automatic wired connections || {{Pkg|ifplugd}} || {{ic|netctl-ifplugd}}<br />
|-<br />
| WPA || {{Pkg|wpa_supplicant}} ||<br />
|-<br />
| DHCP || {{Pkg|dhcpcd}} or {{Pkg|dhclient}} || <br />
|-<br />
| Wifi menus || {{Pkg|dialog}} || <br />
|-<br />
| PPPoE || {{Pkg|ppp}} ||<br />
|-<br />
|}<br />
<br />
{{Note| You will be potentially connectionless after installing ''netctl'' if your network services are misconfigured. It may be a good idea to use {{ic|1=systemctl --type=service}} to ensure that no other service is running that may want to configure the network. Multiple networking services will conflict.}}<br />
<br />
== Required reading ==<br />
<br />
It is advisable to read the following man pages before using netctl:<br />
*[https://github.com/joukewitteveen/netctl/blob/master/docs/netctl.1.txt netctl]<br />
*[https://github.com/joukewitteveen/netctl/blob/master/docs/netctl.profile.5.txt netctl.profile]<br />
*[https://github.com/joukewitteveen/netctl/blob/master/docs/netctl.special.7.txt netctl.special]<br />
<br />
== Configuration ==<br />
<br />
''netctl'' uses profiles to manage network connections, profile files are stored in {{ic|/etc/netctl/}}. Example configuration files are provided for the user to assist them in configuring their network connection. These example profiles are located in {{ic|/etc/netctl/examples/}}. The common configurations include:<br />
* ethernet-dhcp<br />
* ethernet-static<br />
* wireless-wpa<br />
* wireless-wpa-static<br />
<br />
To use an example profile, simply copy one of them from {{ic|/etc/netctl/examples/}} to {{ic|/etc/netctl/}} and configure it to your needs:<br />
<br />
# cp /etc/netctl/examples/wireless-wpa /etc/netctl/''profile''<br />
<br />
{{Note|You will most probably '''need''' to edit the interface name in the profile. As of v197, udev no longer assigns network interface names according to the {{ic|wlan''X''}} and {{ic|eth''X''}} naming scheme. Please do not assume that your wireless interface is named {{ic|wlan0}}, or that your wired interface is named {{ic|eth0}}, as used in examples on this page. You can use the command {{ic|ip link}} to discover the names of your interfaces. See [[Network configuration#Device names]] for details.}}<br />
<br />
{{Tip|For wireless settings, you can use {{ic|wifi-menu -o}} to generate the profile file in {{ic|/etc/netctl/}}.}}<br />
<br />
Once you have created your profile, make an attempt to establish a connection using the newly created profile by running:<br />
<br />
# netctl start ''profile''<br />
<br />
{{Note|''profile'' is the file name, not including the full path. Providing the full path will make ''netctl'' exit with an error code.}}<br />
<br />
If issuing the above command results in a failure, then use {{ic|journalctl -xn}} and {{ic|netctl status ''profile''}} in order to obtain a more in depth explanation of the failure. Make the needed corrections to the failed configuration and retest.<br />
<br />
=== Automatic operation ===<br />
<br />
If you use only one profile (per interface) or want to switch profiles manually, the [[#Basic method|Basic method]] will do. Most common examples are servers, workstations, routers etc.<br />
<br />
If you need to switch multiple profiles frequently, use [[#Automatic switching of profiles|Automatic switching of profiles]]. Most common examples are laptops.<br />
<br />
==== Basic method ====<br />
<br />
With this method, you can statically start only one profile per interface. First manually check that the profile can be started successfully, then it can be enabled using<br />
<br />
# netctl enable ''profile''<br />
<br />
This will create and enable a [[systemd]] service that will start when the computer boots. Changes to the profile file will not propagate to the service file automatically. After such changes, it is necessary to reenable the profile:<br />
<br />
# netctl reenable ''profile''<br />
<br />
{{Note|The connection is only established if the profile can be started succesfully at boot time (or when the service starts). That specifically means, in case of wired connection the cable must be plugged-in, in case of wireless connection the network must be in range.}}<br />
<br />
{{Tip|To enable static IP profile on wired interface no matter if the cable is connected or not, use {{ic|1=SkipNoCarrier=yes}} in your profile.}}<br />
<br />
==== Automatic switching of profiles ====<br />
<br />
''netctl'' provides two special [[systemd]] services for automatic switching of profiles:<br />
<br />
* For wired interfaces: {{ic|netctl-ifplugd@''interface''.service}}. Using this netctl profiles change as you plug the cable in and out.<br />
* For wireless interfaces: {{ic|netctl-auto@''interface''.service}}. Using this netctl profiles change as you move from range of one network into range of other network.<br />
<br />
First [[pacman|install]] required packages:<br />
* Package {{Pkg|ifplugd}} is required to use {{ic|netctl-ifplugd@''interface''.service}}.<br />
* Package {{Pkg|wpa_actiond}} is required to use {{ic|netctl-auto@''interface''.service}}.<br />
<br />
Now configure all profiles that {{ic|netctl-auto@''interface''.service}} or {{ic|netctl-ifplugd@''interface''.service}} can start.<br />
<br />
If you want some wireless profile '''not''' to be started automatically by {{ic|netctl-auto@''interface''.service}}, you have to explicitly add {{ic|1=ExcludeAuto=yes}} to that profile. You can use {{ic|1=Priority=}} in the ''WPAConfigSection'' (see ''/etc/netctl/examples/wireless-wpa-configsection'') to set priority of some profile when multiple profiles are available. {{ic|netctl-ifplugd@''interface''.service}} will prefer profiles, which use [[Wikipedia:DHCP|DHCP]]. To prefer a profile with a static IP, you can use {{ic|1=AutoWired=yes}}. See {{ic|netctl.profile(5)}} for details.<br />
<br />
{{Warning|Automatic selection of a WPA-enabled profile by ''netctl-auto'' is not possible with option {{ic|1=Security=wpa-config}}, please use {{ic|1=Security=wpa-configsection}} instead.}}<br />
<br />
Once your profiles are set and verified to be working, simply enable these services using ''systemctl'':<br />
<br />
# systemctl enable netctl-auto@''interface''.service <br />
# systemctl enable netctl-ifplugd@''interface''.service <br />
<br />
{{Warning|<br />
* If any of the profiles contain errors, such as an empty or misquoted {{ic|1=Key=}} variable, the unit will fail to load with the message {{ic|"Failed to read or parse configuration '/run/network/wpa_supplicant_wlan0.conf'}}, even when that profile is not being used.<br />
* This method conflicts with the [[#Basic method|Basic method]]. If you have previously enabled a profile through ''netctl'', run {{ic|netctl disable ''profile''}} to prevent the profile from starting twice at boot.<br />
}}<br />
<br />
Since netctl 1.3, it possible to manually control an interface otherwise managed by netctl-auto without having to stop the netctl-auto service. This is done using the netctl-auto command. To have a list of available actions just run:<br />
# netctl-auto --help<br />
<br />
=== Migrating from netcfg ===<br />
<br />
''netctl'' uses {{ic|/etc/netctl/}} to store its profiles, '''not''' {{ic|/etc/network.d/}} (used by ''netcfg'').<br />
<br />
In order to migrate from ''netcfg'', at least the following is needed:<br />
* Disable the netcfg service: {{ic|systemctl disable netcfg.service}}.<br />
* Uninstall ''netcfg'' and install ''netctl''.<br />
* Move network profile files to the new directory.<br />
* Rename variables therein according to {{ic|netctl.profile(5)}} (Most variable names have only {{ic|UpperCamelCase}} i.e {{ic|CONNECTION}} becomes {{ic|Connection}}).<br />
* For static IP configuration make sure the {{ic|Address}} variables have a netmask after the IP (e.g. {{ic|1=Address=('192.168.1.23'''/24'''' '192.168.1.87'''/24'''')}} in the example profile). <br />
* If you setup a wireless profile according in the {{ic|wireless-wpa-configsection}} example, note that this overrides {{ic|wpa_supplicant}} options defined above the brackets. For a connection to a hidden wireless network, add {{ic|1=scan_ssid=1}} to the options in the {{ic|wireless-wpa-configsection}}; {{ic|1=Hidden=yes}} does not work there. <br />
* Unquote interface variables and other variables that do not strictly need quoting (this is mainly a style thing).<br />
* Run {{ic|netctl enable ''profile''}} for every profile in the old {{ic|NETWORKS}} array. ''last'' does not work this way, see {{ic|netctl.special(7)}}.<br />
* Use {{ic|netctl list}} and/or {{ic|netctl start ''profile''}} instead of ''netcfg-menu''. ''wifi-menu'' remains available.<br />
* Unlike ''netcfg'', by default ''netctl'' fails to bring up a [[wikipedia:Network interface controller|NIC]] when it is not connected to another powered up NIC. To solve this problem, add {{ic|1=SkipNoCarrier=yes}} at the end of your {{ic|/etc/netctl/''profile''}}.<br />
<br />
=== Passphrase obfuscation (256-bit PSK) ===<br />
<br />
{{Note|Although "encrypted", the key that you put in the profile configuration is enough to connect to a WPA-PSK network. Therefore this process is only useful for hiding the human-readable version of the passphrase. This will not prevent anyone with read access to this file from connecting to the network. You should ask yourself if there is any use in this at all, since using the same passphrase for anything else is a very poor security measure.}}<br />
<br />
Users '''not''' wishing to have the passphrase to their wireless network stored in ''plain text'' have the option of storing the corresponding 256-bit pre-shared key (PSK) instead, which is calculated from the passphrase and the SSID using standard algorithms.<br />
<br />
* Method 1: Use {{ic|wifi-menu -o}} to generate a config file in {{ic|/etc/netctl/}} <br />
* Method 2: Manual settings as follows.<br />
<br />
For both methods it is suggested to {{ic|chmod 600 /etc/netctl/<config_file>}} to prevent user access to the password.<br />
<br />
Calculate your 256-bit PSK using [[WPA_supplicant#Configuration_file|wpa_passphrase]]:<br />
{{hc|$ wpa_passphrase ''your_essid'' ''passphrase''|2=<br />
network={<br />
ssid="''your_essid''"<br />
#psk="''passphrase''"<br />
psk=64cf3ced850ecef39197bb7b7b301fc39437a6aa6c6a599d0534b16af578e04a<br />
}<br />
}}<br />
<br />
{{Note|This information will be used in your profile, so do not close the terminal.}}<br />
<br />
In a second terminal window, copy the example file {{ic|wireless-wpa}} from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cp /etc/netctl/examples/wireless-wpa /etc/netctl/wireless-wpa<br />
<br />
You will then need to edit {{ic|/etc/netctl/wireless-wpa}} using your favorite text editor and add the ''pre-shared key'', that was generated earlier using wpa_passphrase, to the {{ic|Key}} variable of this profile.<br />
<br />
Once completed your network profile {{ic|wireless-wpa}} containing a 256-bit PSK should resemble:<br />
<br />
{{hc|/etc/netctl/wireless-wpa|2=<br />
Description='A simple WPA encrypted wireless connection using 256-bit PSK'<br />
Interface=wlp2s2<br />
Connection=wireless<br />
Security=wpa<br />
IP=dhcp<br />
ESSID=''your_essid''<br />
Key=\"64cf3ced850ecef39197bb7b7b301fc39437a6aa6c6a599d0534b16af578e04a<br />
}}<br />
<br />
{{Note|<br />
* Make sure to use the '''special quoting rules''' for the {{ic|Key}} variable as explained at the end of [https://github.com/joukewitteveen/netctl/blob/master/docs/netctl.profile.5.txt netctl.profile(5)].<br />
* If the passphrase fails, try removing the {{ic|\"}} in the {{ic|Key}} variable.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Using an Experimental GUI ===<br />
<br />
If you want a graphical user interface to manage netctl and your connections and you are not afraid of highly experimental unofficial packages you can install {{AUR|netgui}} from [[AUR]]. Note, however, that netgui is still in beta status and you should be familiar with the general netctl syntax to debug possible issues.<br />
<br />
=== Set default dhcp client for all profiles ===<br />
<br />
If you want to set a default dhcp client for all profiles on an interface, create an ''executable'' file {{ic|/etc/netctl/interfaces/<interface>}} with the following line:<br />
<br />
DHCPClient='dhclient'<br />
<br />
=== Replace 'netcfg current' ===<br />
<br />
If you used {{ic|netcfg current}} in the past, you can use {{ic|# netctl-auto current}} as a replacement for connections started with {{ic|netctl-auto}} (feature since netctl-1.3). <br />
<br />
To manually parse the connections, you can also use: <br />
<br />
# netctl list | awk '/*/ {print $2}'<br />
<br />
=== Eduroam ===<br />
<br />
Some universities use a system called "Eduroam" to manage their wireless networks. The [[AUR]] contains the package {{AUR|netctl-eduroam}} which provides a template for easy configuration. Once installed, copy the template from {{ic|/etc/netctl/examples/eduroam}} to {{ic|/etc/netctl/eduroam}} and modify it according to your credentials. <br />
<br />
Alternatively adapt the example WPA config-section profiles below:<br />
<br />
{{hc|/etc/netctl/wlan0-eduroam|<nowiki><br />
Description='Eduroam-profile for <user>'<br />
Interface=wlan0<br />
Connection=wireless<br />
Security=wpa-configsection<br />
IP=dhcp<br />
WPAConfigSection=(<br />
'ssid="eduroam"'<br />
'proto=RSN WPA'<br />
'key_mgmt=WPA-EAP'<br />
'auth_alg=OPEN'<br />
'eap=PEAP'<br />
'identity="<user>"'<br />
'password="<password>"'<br />
)</nowiki><br />
}}<br />
<br />
{{Tip|To prevent storing your password as plaintext, you can generate a password hash with {{ic|$ tr -d '[:space:]' &#124; iconv -t utf16le &#124; openssl md4}}. Type your password, enter, then ctrl+d. Store the hashed password as {{ic|'password&#61;hash:<hash>'}}.}}<br />
<br />
For TTLS and certified universities this example specifies the required credentials:<br />
<br />
{{hc|/etc/netctl/wlan0-eduroam|<nowiki><br />
Description='Eduroam university'<br />
Interface=wlan0 <br />
Connection=wireless<br />
Security=wpa-configsection<br />
IP=dhcp<br />
ESSID=eduroam<br />
WPAConfigSection=(<br />
'ssid="eduroam"'<br />
'proto=RSN WPA'<br />
'key_mgmt=WPA-EAP'<br />
'eap=TTLS'<br />
'anonymous_identity="anonymous@domain_university"'<br />
'identity="XXX@domain_university"'<br />
'password="XXX"'<br />
'ca_path="/etc/ssl/certs/"'<br />
'ca_path2="/etc/ssl/certs/"'<br />
'phase2="auth=PAP"'<br />
)</nowiki><br />
}}<br />
<br />
=== Bonding ===<br />
<br />
From [https://www.kernel.org/doc/Documentation/networking/bonding.txt kernel documentation]:<br />
<br />
:''The Linux bonding driver provides a method for aggregating multiple network interfaces into a single logical "bonded" interface. The behavior of the bonded interfaces depends on the mode. Generally speaking, modes provide either hot standby or load balancing services. Additionally, link integrity monitoring may be performed.''<br />
<br />
==== Load balancing ====<br />
<br />
To use bonding with netctl, additional package from official repositories is required: {{Pkg|ifenslave}}.<br />
<br />
Copy {{ic|/etc/netctl/examples/bonding}} to {{ic|/etc/netctl/bonding}} and edit it, for example: <br />
<br />
{{hc|/etc/netctl/bonding|2=<br />
Description='Bond Interface'<br />
Interface='bond0'<br />
Connection=bond<br />
BindsToInterfaces=('eth0' 'eth1')<br />
IP=dhcp<br />
IP6=stateless}}<br />
<br />
Now you can disable your old configuration and set ''bonding'' to be started automatically. Switch to the new profile, for example:<br />
<br />
# netctl switch-to bonding<br />
<br />
{{Note|This uses the round-robin policy, which is the default for the {{ic|bonding}} driver. See [https://www.kernel.org/doc/Documentation/networking/bonding.txt official documentation] for details.}}<br />
<br />
{{Tip|To check the status and bonding mode: {{bc|$ cat /proc/net/bonding/bond0}}}}<br />
<br />
==== Wired to wireless failover ====<br />
{{Accuracy|The steps in this section are incomplete and refer to netctl profiles the user has not been instructed to create.}}<br />
<br />
This example describes how to use ''bonding'' to fallback to wireless when the wired ethernet goes down. It is assumed that ''dhcpcd'' service is running for all interfaces as by default.<br />
<br />
You will need additional packages from the official repositories: <s>{{Pkg|ifplugd}}</s>, {{Pkg|ifenslave}} and {{Pkg|wpa_supplicant}}.<br />
<br />
First configure the {{ic|bonding}} driver to use {{ic|active-backup}}:<br />
<br />
{{hc|/etc/modprobe.d/bonding.conf|2=<br />
options bonding mode=active-backup<br />
options bonding miimon=100<br />
options bonding primary=eth0<br />
options bonding max_bonds=0<br />
}}<br />
<br />
The {{ic|max_bonds}} option avoids the {{ic|Interface bond0 already exists}} error. {{ic|fail_over_mac<nowiki>=</nowiki>active}} setting may be added if MAC filtering is used. <br />
<br />
Next, configure a netctl profile to enslave the two hardware interfaces:<br />
<br />
{{hc|/etc/netctl/failover|2=<br />
Description='A wired connection with failover to wireless'<br />
Interface='bond0'<br />
Connection=bond<br />
BindsToInterfaces=('eth0' 'wlan0')<br />
IP='dhcp'<br />
SkipNoCarrier='no'<br />
}}<br />
<br />
Enable the profile on startup.<br />
<br />
# netctl enable failover<br />
<br />
Configure ''wpa_supplicant'' to associate with known networks. This can be done with a netctl profile (remember to use {{ic|1=IP='no'}}) and a ''wpa_supplicant'' service running constantly, or on-demand with ''wpa_cli''. Ways to do this are covered on the [[wpa_supplicant]] page. To run ''wpa_supplicant'' constantly create ''wpa_supplicant'' config file {{ic|/etc/wpa_supplicant/wpa_supplicant-wlan0.conf}} and then run:<br />
<br />
# systemctl enable wpa_supplicant@wlan0<br />
<br />
Set {{ic|1=IP='no'}} in wired network profile. IP address should be assigned to ''bond0'' interface only.<br />
<br />
If you have a wired and wireless connection to the same network, you can probably now disconnect and reconnect the wired connection without losing connectivity. In most cases, even streaming music will not skip!<br />
<br />
=== Using any interface ===<br />
In some cases it may be desirable to allow a profile to use any interface on the system. A common example use case is using a common disk image across many machines with differing hardware (this is especially useful if they are headless). If you use the kernel's naming scheme, and your machine has only one ethernet interface, you can probably guess that eth0 is the right interface. If you use udev's [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Predictable Network Interface Names], however, names will be assigned based on the specific hardware itself (e.g. enp1s0), rather than simply the order that the hardware was detected (e.g. eth0, eth1). This means that a netctl profile may work on one machine and not another, because they each have different interface names.<br />
<br />
A quick and dirty solution is to make use of the {{ic|/etc/netctl/interfaces/}} directory. Choose a name for your interface alias ({{ic|en-any}} in this example), and write the following to a file with that name (making sure it is executable).<br />
{{hc|/etc/netctl/interfaces/en-any|<nowiki><br />
#!/bin/bash<br />
for interface in /sys/class/net/en*; do<br />
break;<br />
done<br />
Interface=$(basename $interface)<br />
echo "en-any: using interface $Interface";<br />
</nowiki>}}<br />
Then create a profile that uses the interface. Pay special attention to the {{ic|Interfaces}} directive. The rest are only provided as examples.<br />
{{hc|/etc/netctl/wired|<nowiki><br />
Description='Wired'<br />
Interface=en-any<br />
Connection=ethernet<br />
IP=static<br />
Address=('192.168.1.15/24')<br />
Gateway='192.168.1.1'<br />
DNS=('192.168.1.1')<br />
</nowiki>}}<br />
<br />
When the {{ic|wired}} profile is started, any machine using the two files above will automatically bring up and configure the first ethernet interface found on the system, regardless of what name udev assigned to it. Note that this is not the most robust way to go about configuring interfaces. If you use multiple interfaces, netctl may try to assign the same interface to them, and will likely cause a disruption in connectivity. If you do not mind a more complicated solution, {{ic|netctl-auto}} is likely to be more reliable.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Job for netctl@wlan(...).service failed ===<br />
Some people have an issue when they connect to a network with netctl, e.g.<br />
{{hc|# netctl start wlan0-ssid|<nowiki><br />
Job for netctl@wlan0\x2ssid.service failed. See 'systemctl status netctl@wlan0\x2ssid.service' and 'journalctl -xn' for details.<br />
</nowiki>}}<br />
When then looking at journalctl -xn, either of the following are shown:<br />
<br />
If your device (wlan0 in this case) is up:<br />
network[2322]: The interface of network profile 'wlan0-ssid' is already up<br />
<br />
Check if the interface is already up via<br />
ip link<br />
<br />
If its already up set it to down (replace wlan0 with your device name):<br />
ip link set wlan0 down<br />
<br />
Then retry<br />
netctl start wlan0-ssid<br />
<br />
If it is down:<br />
dhcpcd[261]: wlan0: ipv4_sendrawpacket: Network is down<br />
<br />
One way to solve this is to use a different dhcp-client, and getting your netctl profile to use it.<br />
# pacman -S dhclient<br />
# vim /etc/netctl/wlan0-ssid<br />
<br />
{{hc|/etc/netctl/wlan0-ssid|<nowiki><br />
...<br />
DHCPClient='dhclient'<br />
</nowiki>}}<br />
<br />
Save it and try to connect with the profile:<br />
# netctl start wlan0-ssid<br />
Now it should work!<br />
<br />
=== dhcpcd: ipv4_addroute: File exists ===<br />
<br />
On some systems dhcpcd in combination with netctl causes timeout issues on resume, particularly when having swichted networks in the meantime. netctl will report that you are successfully connected but you still receive timeout issues. In this case, the old default route still exists and is not being renewed. A workaround to avoid this misbehaviour is to switch to [[#Set default dhcp client for all profiles|dhclient]] as the default dhcp client. More information on the issue can be found [https://bbs.archlinux.org/viewtopic.php?pid=1399842#p1399842 here].<br />
<br />
=== DHCP timeout issues ===<br />
<br />
If you are having timeout issues when requesting leases via DHCP you can set the timeout value higher than netctl's 30 seconds by default. Create a file in {{ic|/etc/netctl/hooks/}} or {{ic|/etc/netctl/interfaces/}}, add {{ic|1=TimeoutDHCP=40}} to it for a timeout of 40 seconds and make the file executable.<br />
<br />
=== Connection timeout issues ===<br />
<br />
If you are having timeout issues that are unrelated to DHCP (on a static ethernet connection for example), and are experiencing errors similar to the following when starting your profile:<br />
{{hc|# journalctl _SYSTEMD_UNIT&#61;netctl@''profile''.service|<br />
Starting network profile &#39;''profile''&#39;...<br />
No connection found on interface 'eth0' (timeout)<br />
Failed to bring the network up for profile &#39;''profile''&#39;<br />
}}<br />
Then you should increase carrier and up timeouts by adding {{ic|1=TimeoutUp=}} and {{ic|1=TimeoutCarrier=}} to your profile file:<br />
{{hc|/etc/netctl/''profile''|<nowiki><br />
...<br />
TimeoutUp=300<br />
TimeoutCarrier=300</nowiki><br />
}}<br />
Do not forget to reenable your profile:<br />
<br />
# netctl reenable ''profile''<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=157670 Official announcement thread]<br />
* There is a cinnamon applet available in the AUR: {{AUR|cinnamon-applet-netctl-systray-menu}}</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Golang&diff=311605Golang2014-04-23T20:40:27Z<p>Xorrr: redirect golang to Go</p>
<hr />
<div>#REDIRECT [[Go]]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Go&diff=311604Go2014-04-23T20:39:50Z<p>Xorrr: create page for the programming language go</p>
<hr />
<div>[[Category:Programming language]]<br />
[http://golang.org/ Go] is a statically-typed language with syntax loosely derived from that of C, adding garbage collected memory management, type safety, some dynamic-typing capabilities, additional built-in types such as variable-length arrays and key-value maps, and a large standard library.<br />
<br />
== Installation ==<br />
From the [[Official repositories]]: {{pkg|go}}.<br />
<br />
=== Test your installation ===<br />
Check that Go is installed correctly by building a simple program, as follows.<br />
<br />
Create a file named {{ic|hello.go}} and put the following program in it: <br />
<br />
{{bc|<br />
package main<br />
<br />
import "fmt"<br />
<br />
func main() {<br />
fmt.Printf("hello pacman\n")<br />
}<br />
}}<br />
<br />
Then run it with the go tool: <br />
{{hc|$ go run hello.go|<br />
hello pacman<br />
}}<br />
<br />
If you see the "hello pacman" message then your Go installation is working.</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=305550User:Xorrr2014-03-19T02:08:53Z<p>Xorrr: </p>
<hr />
<div>== Languages ==<br />
* German<br />
* English<br />
<br />
== Used Distributions ==<br />
* Arch - Since mid 2011<br />
<br />
== Started ==<br />
* [[Lenovo_ThinkPad_L430]]<br />
* [[Surfraw]]<br />
* [[pass]]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Pass&diff=305549Pass2014-03-19T02:07:33Z<p>Xorrr: create introductory page for the cli password manager pass</p>
<hr />
<div>[[Category:Security]]<br />
[http://www.zx2c4.com/projects/password-store/ pass] is a simple password manager for the command line. Passwords are stored inside gpg encrypted files in a simple directory tree structure. Basically pass is a shell script that makes use of existing tools like {{Pkg|gnupg}}, {{Pkg|pwgen}}, {{Pkg|tree}} & {{Pkg|git}} and can therefore be considered less "bloated" than alternatives like e.g. [http://keepass.info/ keepass]<br />
<br />
== Installation ==<br />
[[pacman|Install]] {{Pkg|pass}}, available in the [[official repositories]].<br />
<br />
== Basic usage ==<br />
{{Note|To be able to use pass you need to '''set up gnupg''' as described in [[Gnupg#Basic keys management]]}}<br />
<br />
* Initialize the password store<br />
$ pass init <gpg-id or email><br />
<br />
* Insert password, providing a descriptive hierarchical name<br />
$ pass insert archlinux.org/wiki/username<br />
<br />
* Get a view of the password store <br />
{{hc|$ pass|<br />
Password Store<br />
└── archlinux.org<br />
└── wiki<br />
└── username<br />
}}<br />
<br />
* Generate a new random password, where {{ic|<n>}} is the desired password length as a number.<br />
$ pass generate archlinux.org/wiki/username <n><br />
<br />
* Retrieve password, you will be prompted for the gpg passphrase<br />
$ pass archlinux.org/wiki/username<br />
<br />
* If you're using Xorg and have {{Pkg|xclip}} installed, the retrieved password can be put on the clipboard temporarily to paste into web forms via:<br />
$ pass -c archlinux.org/wiki/username<br />
<br />
== Migrating to pass ==<br />
There are multiple scripts listed on the [http://www.zx2c4.com/projects/password-store/ pass-project page] to import passwords from other programs<br />
<br />
== See also ==<br />
* [http://blog.sanctum.geek.nz/linux-crypto-passwords/ A more comprehensive pass tutorial]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Wake-on-LAN&diff=303427Wake-on-LAN2014-03-07T02:38:54Z<p>Xorrr: add note telling net0 has to be substituted with the apt network device</p>
<hr />
<div>[[Category:Networking]]<br />
'''Wake-on-LAN''', otherwise known as 'wol', is the ability to switch on a computer that is connected to a network (be it the internet or intranet). This article deals with what it is, how it can be used from an Arch Linux computer, and its general uses.<br />
<br />
It is important to note that Wake-on-LAN applies to the computers being physically connected (ie, not wireless).<br />
<br />
==Does my motherboard support Wake-on-LAN?==<br />
<br />
For Wake-on-LAN to work, the target computer motherboard must support this feature. Generally speaking, the Wake-on-LAN (non)ability of the target motherboard will be specified by the hardware manufacturer. Sometimes, this ability is evident by browsing through said motherboard's BIOS and looking for something like 'PCI Power up'. Most modern motherboards should support Wake-on-LAN.<br />
<br />
==Ensure that Wake-on-LAN is enabled and survives a reboot==<br />
A common problem with the Wake-on-LAN in computers running Linux is that the network drivers have Wake-on-LAN switched off by default. To manually switch on the Wake-on-LAN feature on your driver, you will need to install {{Pkg|ethtool}}.<br />
<br />
{{Note|For the following commands substitute net0 with your network device, e.g. eth0}}<br />
<br />
First query the driver to see if it's defaulted to 'on' by using ethtool:<br />
<br />
{{hc|<nowiki># ethtool net0 | grep Wake-on</nowiki>|<nowiki><br />
Supports Wake-on: pg<br />
Wake-on: d<br />
</nowiki>}}<br />
<br />
{{Note|We need a 'Wake-on' value of 'g' for WOL to work.}}<br />
<br />
To enable the wol feature in the driver, simply run the following<br />
# ethtool -s net0 wol g<br />
<br />
This command does not last beyond the '''next''' reboot. If using netctl, one can make this setting persistent by adding the following to your netctl profile:<br />
{{hc|/etc/netctl/PROFILE|2=<br />
ExecUpPost='/usr/bin/ethtool -s net0 wol g'<br />
}}<br />
<br />
*If for some reason, you find that after using the command to switch your network drivers Wake-on-LAN feature on, the computer shuts down normally but then starts again, experiment with combinations of [u/b/m]g<br />
*For some network cards, you may also need the following command:<br />
<br />
# echo enabled > /sys/class/net/net0/device/power/wakeup<br />
<br />
===With udev===<br />
<br />
udev is capable of running any command you desire as soon as a device is visible. We want udev to turn on wake on lan for our device. Put the following in /etc/udev/rules.d/50-wol.rules, replacing N with the number for your interface:<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="netN", RUN+="/usr/bin/ethtool -s %k wol g"<br />
<br />
This tells udev to run "/usr/bin/ethtool -s netN wol g" as soon as the device netN exists. To turn on wake on lan for all new devices, replace the N with a '*':<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="net*", RUN+="/usr/bin/ethtool -s %k wol g"<br />
<br />
===With cron===<br />
<br />
A command can be run each time the computer is (re)booted using "@reboot" in a crontab. First, make sure [[Cron#Installation|cron]] is enabled, and then [[Cron#Basic_commands|edit a crontab]] for the root user that contains the following line:<br />
@reboot /usr/bin/ethtool -s [net-device] wol g<br />
<br />
===With systemd===<br />
<br />
If for some reason udev fails or is not an option, systemd can be used instead as a last resort. (In this editor's experience, systemd is rather intermittent.) To use systemd, do ''not'' follow the udev instructions. Instead, create a new service unit file /etc/systemd/system/wol@.service:<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=Wake-on-LAN for %i<br />
Requires=network.target<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/ethtool -s %i wol g<br />
Type=oneshot<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Or install {{AUR|wol-systemd}} package from the [[AUR]]<br />
<br />
Then activate this new service for your network adapter:<br />
<br />
# systemctl enable wol@net0<br />
<br />
and start it right now<br />
<br />
# systemctl start wol@net0<br />
<br />
==Wake-on-LAN in different situations==<br />
<br />
The computer that you want to use Wake-on-LAN on may be directly linked to your computer through a network cable, connected to the same router that you are using, or remotely, across the internet.<br />
<br />
There are four essential things needed in order to use Wake-on-LAN on a target PC:<br />
<br />
#Some kind of Wake-on-LAN software on the host (your) PC<br />
#A connection to the internet or intranet of the target PC<br />
#The MAC address of the target PC<br />
#The internal or external IP of the target PC<br />
<br />
*Firstly, install a Wake-on-LAN software. In this article, [http://ahh.sourceforge.net/wol/ wol] will be used. It can be installed from the [[AUR_User_Guidelines#.5Bcommunity.5D|[community]]] repository.<br />
<br />
*'''It is recommended that you read the documentation of wol'''<br />
<br />
man wol<br />
wol --help<br />
<br />
*wol requires several parameters, the most basic needed:<br />
<br />
wol MACADDRESS<br />
<br />
*But it is good practice to include the IP address or hostname, therefore this syntax should be the minimal used:<br />
<br />
# wol -i HOSTNAME_OR_IP MACADDRESS<br />
<br />
*The documentation of wol states that:<br />
<br />
::''Each MAC-ADDRESS is written as x:x:x:x:x:x, where x is a hexadecimal number between 0 and ff which represents one byte of the address, which is in network byte order (big endian).''<br />
<br />
*To obtain the MACADDRESS of the target computer:<br />
<br />
$ ip link<br />
<br />
The port, IP or hostname of the target PC will be addressed in the relevant following sections.<br />
<br />
===Across your intranet/network (no router)===<br />
<br />
If you are connected directly to another computer through a network cable, or have disabled your router firewall (not a good idea), then using Wake-on-LAN should be very simple.<br />
<br />
====For two computers connected to each other====<br />
<br />
wol MACADDRESS_OF_TARGET_PC<br />
<br />
====For computers connected to a non-firewalled router====<br />
<br />
wol -i INTERNAL_IP_OF_TARGET_PC MACADDRESS_OF_TARGET_PC<br />
<br />
*To find the internal IP:<br />
{{bc|<nowiki>ip addr | grep 'inet '</nowiki>}}<br />
<br />
*Since you are not firewalled, then there is no need to worry about port redirects.<br />
*If you intend to continue using Wake-on-LAN, it is recommended that you assign your computer's MACADDRESS to a specific IP on your router. Consult your router for details as to how to do this.<br />
<br />
===Across your intranet/network (router)===<br />
<br />
The syntax used in this situation:<br />
<br />
wol -p PORT_FORWARDED_TO_INTERNAL_IP -i INTERNAL_IP MACADDRESS_OF_TARGET_PC<br />
<br />
*When you send the MagicPacket signal to the target computer via a specific port, the signal passes through your router. The router must be instructed to forward any signal heading for that specific port to the internal IP of the target PC.<br />
<br />
*It is recommended that for multiple computers connected to one computer, to assign a different port forward to each internal IP<br />
<br />
*For port forwarding help, please consult http://portforward.com/ (though this website has some Windows specific content, it has a very large database of router web interfaces)<br />
<br />
===Across the internet===<br />
{{Expansion|Request for OpenWRT instructions.}}<br />
The syntax needed in this case:<br />
<br />
wol -p X -i HOSTNAME_OR_EXTERNAL_IP_OF_TARGET MACADDRESS<br />
<br />
*Assuming that you know the external IP of the target machine, and that the [[Wake-on-LAN#Across_your_intranet.2Fnetwork_.28router.29|router ports]] on both sides have been forwarding correctly, then this should be exactly as the syntax states.<br />
<br />
<br />
Usually it is necessary to forward your wol port (typically UDP 9) to the broadcast address on your network, not to a particular IP. Most routers do not allow you to forward to broadcast, however if you can get shell access to your router (through telnet, ssh, serial cable, etc) you can implement this workaround:<br />
ip neighbor add 192.168.1.254 lladdr FF:FF:FF:FF:FF:FF dev net0<br />
<br />
(The above command assumes your network is 192.168.1.0/24 and use net0 as network interface). Now, forward UDP port 9 to 192.168.1.254. This has worked for me on a Linksys WRT54G running Tomato, and on the Verizon FIOS ActionTec router.<br />
<br />
For notes on how to do it on DD-WRT routers, see [http://www.dd-wrt.com/wiki/index.php/WOL#Remote_Wake_On_LAN_via_Port_Forwarding this tutorial].<br />
<br />
==Battery draining problem==<br />
Some laptops have battery draining problem after shutdown [http://ubuntuforums.org/archive/index.php/t-1729782.html]. This might be caused by enabled Wake-on-LAN. To solve this problem, we can disable it by using ethtool as mentioned above.<br />
<br />
# ethtool -s net0 wol d<br />
<br />
We can also add this to the '''/etc/rc.local''' or '''/etc/rc.local.shutdown'''.<br />
<br />
==Additional Notes==<br />
<br />
*A common problem is that some forget to switch on the Wake-on-LAN feature in their BIOS.<br />
<br />
*In some systems the BIOS option "Boot from PCI/PCI-E" needs to be Enabled.<br />
<br />
==Example WOL script==<br />
Here is a script you can use to automate wol to several different machine. Modify as you see fit:<br />
<br />
<pre>#!/bin/bash<br />
<br />
# definition of MAC addresses<br />
monster=01:12:46:82:ab:4f<br />
chronic=00:3a:53:21:bc:30<br />
powerless=1a:32:41:02:29:92<br />
ghost=01:1a:d2:56:6b:e6<br />
<br />
while [ "$input1" != quit ]; do<br />
echo "Which PC to wake?"<br />
echo "p) powerless"<br />
echo "m) monster"<br />
echo "c) chronic"<br />
echo "g) ghost"<br />
echo "b) wake monster, wait 40sec, then wake chronic"<br />
echo "q) quit and take no action"<br />
read input1<br />
if [ $input1 == p ]; then<br />
/usr/bin/wol $powerless<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == m ]; then<br />
/usr/bin/wol $monster<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == c ]; then<br />
/usr/bin/wol $chronic<br />
exit 1<br />
fi<br />
<br />
# this line requires an IP address in /etc/hosts for ghost<br />
# and should use wol over the internet provided that port 9<br />
# is forwarded to ghost on ghost's router<br />
<br />
if [ $input1 == g ]; then<br />
/usr/bin/wol -v -h -p 9 ghost $ghost<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == b ]; then<br />
/usr/bin/wol $monster<br />
echo "monster sent, now waiting for 40sec then waking chronic"<br />
sleep 40<br />
/usr/bin/wol $chronic<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == Q ] || [ $input1 == q ]; then<br />
echo "later!"<br />
exit 1<br />
fi<br />
<br />
done<br />
echo "this is the (quit) end!! c-ya!"</pre><br />
== Resources ==<br />
[http://www.depicus.com/wake-on-lan/woli.aspx Wake-On-Lan]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Bspwm&diff=302814Bspwm2014-03-02T01:34:23Z<p>Xorrr: remove the frequency option that is only available in the sxhkd-git pkg and won't work for anyone using the nongit sxhkd pkg</p>
<hr />
<div>[[Category:Tiling WMs]]<br />
'''bspwm''' is a tiling window manager that represents windows as the leaves of a full binary tree. It has support for [http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html EWMH] and multiple monitors, and is configured and controlled through messages.<br />
<br />
== Installation ==<br />
<br />
Install {{AUR|bspwm}} or {{AUR|bspwm-git}} from the [[AUR]]. You will also want to install {{AUR|sxhkd}} or {{AUR|sxhkd-git}}, a simple X hotkey daemon used to communicate with bspwm through {{ic|bspc}} as well as launch your applications of choice.<br />
<br />
To start bspwm on login, add the following to {{ic|~/.xinitrc}}:<br />
<br />
{{bc|<br />
sxhkd &<br />
exec bspwm<br />
}}<br />
<br />
== Configuration ==<br />
<br />
Example configuration is found on [https://github.com/baskerville/bspwm/blob/master/examples/ GitHub].<br />
<br />
Copy [https://github.com/baskerville/bspwm/blob/master/examples/bspwmrc bspwmrc] to {{ic|~/.config/bspwm/bspwmrc}}, [https://github.com/baskerville/bspwm/blob/master/examples/sxhkdrc sxhkdrc] to {{ic|~/.config/sxhkd/sxhkdrc}} and make bspwmrc executable with {{ic|chmod +x ~/.config/bspwm/bspwmrc}}.<br />
<br />
These two files are where you will be setting wm settings and keybindings, respectively.<br />
<br />
Documentation for bspwm is found by running {{ic|man bspwm}}.<br />
<br />
There is also documentation for sxhkd found by running {{ic|man sxhkd}}.<br />
<br />
==== Note for multi-monitor setups ====<br />
<br />
The example bspwmrc configures ten desktops on one monitor like this:<br />
bspc monitor -d I II III IV V VI VII VIII IX X<br />
<br />
You will need to change this line and add one for each monitor, similar to this:<br />
bspc monitor DVI-I-1 -d I II III IV<br />
bspc monitor DVI-I-2 -d V VI VII<br />
bspc monitor DP-1 -d VIII IX X<br />
<br />
You can use `xrandr -q` or `bspc query -M` to find the monitor names.<br />
<br />
The total number of desktops were maintained at ten in the above example. This is so that each desktop can still be addressed with 'super + {1-9,0}' in the sxhkdrc.<br />
<br />
=== Rules ===<br />
<br />
There are two ways to set window rules (as of [https://github.com/baskerville/bspwm/commit/cd97a3290aa8d36346deb706fa307f5f8faa2f34 cd97a32]).<br />
<br />
The first is by using the built in rule command, as shown in the example bspwmrc:<br />
{{bc|<nowiki><br />
bspc rule -a Gimp desktop=^8 follow=on floating=on<br />
bspc rule -a Chromium desktop=^2<br />
bspc rule -a mplayer2 floating=on<br />
bspc rule -a Kupfer.py focus=on<br />
bspc rule -a Screenkey manage=off<br />
</nowiki>}}<br />
<br />
The second option is to use an external rule command. This is more complex, but can allow you to craft more complex window rules. See [https://github.com/baskerville/bspwm/tree/master/examples/external_rules these examples] for a sample rule command. These scripts require [https://www.archlinux.org/packages/?sort=&q=lua-posix&maintainer=&flagged= lua-posix], [https://www.archlinux.org/packages/?sort=&repo=Extra&q=lua&maintainer=&flagged= lua] and [https://aur.archlinux.org/packages/xwinfo-git xwinfo].<br />
<br />
If a particular window does not seem to be behaving according to your rules, check the class name of the program. This can be accomplished by running {{ ic | xprop <nowiki>|</nowiki> grep WM_CLASS}} to make sure you're using the proper string.<br />
<br />
=== Panels ===<br />
Currently, [https://aur.archlinux.org/packages/bar-aint-recursive/ bar] and [https://www.archlinux.org/packages/?sort=&q=dzen2&maintainer=&flagged= dzen2] are supported with bspwm. Check the examples folder on the GitHub page for ideas or the [https://wiki.archlinux.org/index.php/Bar-aint-recursive Bar] wiki page. The panel will be executed by placing {{ic | panel &}} for bar or {{ic | panel dzen2 &}} for dzen2 in your bspwmrc. Check the opt-depends in the bspwm package for dependencies that may be required in either case.<br />
<br />
To display system information on your status bar you can use various system calls. This example will show you how to edit your {{ic | panel }} to get the volume status on your BAR:<br />
<br />
{{bc|<nowiki><br />
panel_volume()<br />
{<br />
volStatus=$(amixer get Master | tail -n 1 | cut -d '[' -f 4 | sed 's/].*//g')<br />
volLevel=$(amixer get Master | tail -n 1 | cut -d '[' -f 2 | sed 's/%.*//g')<br />
# is alsa muted or not muted?<br />
if [ "$volStatus" == "on" ]<br />
then<br />
echo "\f6"$volLevel<br />
else<br />
# If it is muted, make the font red<br />
echo "\f1"$volLevel<br />
fi<br />
}</nowiki>}}<br />
<br />
Next, we will have to make sure it is called and piped to {{ic | $PANEL_FIFO}}:<br />
<br />
{{bc|<nowiki><br />
while true; do<br />
echo "S" "$(panel_volume) $(panel_clock) > "$PANEL_FIFO"<br />
sleep 1s<br />
done &<br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Help! I get a blank screen and my keybindings don't work! ===<br />
<br />
There are a few ways to debug this. First, a blank screen is good. That means bspwm is running.<br />
<br />
I would confirm that your xinitrc looks something like<br />
<br />
{{bc|<nowiki><br />
sxhkd &<br />
exec bspwm<br />
</nowiki>}}<br />
<br />
The ampersand is important. Next, try spawning a terminal in your xinitrc to see if its getting positioned properly. It should appear somewhat "centered" on the screen. To do this, use this .xinitrc:<br />
<br />
{{bc|<nowiki><br />
sxhkd &<br />
urxvt &<br />
exec bspwm<br />
</nowiki>}}<br />
<br />
If nothing shows up, that means you probably forgot to install urxvt. If it shows up but isn't centered or taking up most of your screen, that means BSPWM isn't getting started properly. Make sure that you've {{ic | chmod +x ~/.config/bspwm/bspwmrc }}.<br />
<br />
Next, type pidof sxhkd in that terminal you spawned. It should return a number. If it doesn't, that means sxhd isn't running. Try to be explicit and run {{ ic | sxhkd -c ~/.config/sxhkd/sxhkdrc }}. You could also try changing the Super key to something like Alt in your sxhkdrc and see if that helps. Another common problem is copying the text from the example files instead of physically copying the file over. Copying / pasting code usually leads to indentation issues which sxhkd can be sensative to.<br />
<br />
== See also ==<br />
<br />
* Mailing List: bspwm ''at'' librelist.com.<br />
* {{ic|#bspwm}} - IRC channel at irc.freenode.net<br />
* https://bbs.archlinux.org/viewtopic.php?id=149444 - Arch BBS thread<br />
* https://github.com/baskerville/bspwm - GitHub project<br />
* https://github.com/windelicato/dotfiles/wiki/bspwm-for-dummies - earsplit's "bspwm for dummies"</div>Xorrrhttps://wiki.archlinux.org/index.php?title=ECryptfs&diff=295262ECryptfs2014-02-01T01:38:27Z<p>Xorrr: add info on how to undo the single directory encryption</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[fr:Encryption avec eCryptfs]]<br />
[[it:System Encryption with eCryptfs]]<br />
[[ru:System Encryption with eCryptfs]]<br />
{{Related articles start}}<br />
{{Related|Disk Encryption}}<br />
{{Related articles end}}<br />
This article describes basic usage of [https://launchpad.net/ecryptfs eCryptfs]. It guides you through the process of creating a private and secure encrypted directory within your ''$HOME'' directory, where you can store all your sensitive files and private data.<br />
<br />
In implementation eCryptfs differs from dm-crypt, which provides a ''block device encryption layer'', while eCryptfs is an actual file-system &ndash; a [http://en.wikipedia.org/wiki/Cryptographic_filesystems stacked cryptographic file system] to be exact. For comparison of the two you can refer to [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare this table ]. <br />
<br />
The summary is that it doesn't require special on-disk storage allocation effort, such as separate partitions, you can mount eCryptfs on top of any single directory to protect it. That includes e.g. your entire $HOME and network file systems (i.e. having encrypted NFS shares). All cryptographic metadata is stored in the headers of files, so encrypted data can be easily moved, stored for backup and recovered. There are other advantages, but there are also drawbacks, for instance eCryptfs is not suitable for encrypting complete partitions which also means you can't protect your swap space with it (instead you can combine it with dm-crypt).<br />
<br />
For more details on how eCryptfs compares to other disk encryption solutions, see [[Disk Encryption#Comparison table]]. <br />
<br />
== Basics ==<br />
<br />
See [[Disk_Encryption#Available_methods]] for a general introduction to stacked filesystem encryption, and how it compares to block device encryption.<br />
<br />
{{Expansion|<br> - Explain the basic mechanisms & terminology at the heart of eCryptfs ("mounting", "FEKEK", "wrapped passphrase", etc.) in simple terms|section=Major_restructuring/rewrite}}<br />
<br />
== Preparation ==<br />
<br />
Before starting to set up disk encryption, there are a few things to consider and to prepare in advance: [[Disk_Encryption#Preparation]]<br />
<br />
{{Expansion|<br> - discuss the 2 real-life set-ups for which eCryptfs is especially well suited: <u>encrypted data directory</u> and <u>encrypted home directory</u><br><br />
- discuss swap, and point to [[dm-crypt/Swap_Encryption]] for instructions [and make sure that article is written in a self-contained way that does not assume readers arrived from other dm-crypt articles!]|section=Major_restructuring/rewrite}}<br />
<br />
=== Deficiencies ===<br />
<br />
{{Accuracy|check if the warning about sparse files is still applicable}}<br />
<br />
eCryptfs does not handle [https://en.wikipedia.org/wiki/Sparse_file sparse files] well; this should be considered before encrypting large portions of the directory structure ($HOME, for example). For most intents and purposes this deficiency does not pose a problem. Using eCryptfs to encrypt sparse files, however, currently encrypts the entire allocated space of the sparse file, which, in the case of big files, can starve the system of resources. (This bug may be tracked [https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/431975 on Launchpad]). One popular and inadvisable application of eCryptfs is to encrypt a BitTorrent download location; this often requires eCryptfs to handle sparse files of 10 GB or more and may lead to intense disk starvation. A simple workaround is to place sparse files in an unencrypted '''.Public''' directory (as opposed to the standard eCryptfs '''.Private''' directory, explained below).<br />
<br />
=== Login password ===<br />
<br />
{{Deletion|Already covered in [[Disk_Encryption#Preparation]], which is linked to above.}}<br />
<br />
{{note|1= With {{pkg|shadow}} 4.1.4.3-3 ''sha512'' is the default for new passwords (see [https://bugs.archlinux.org/task/13591#comment85993 bug 13591] and corresponding [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/shadow&id=98001501a8306ef5a0df55d1cffc048851894940 commit]).}}<br />
<br />
If you are encrypting your whole home, with auto-mounting you should use a strong password and consider changing the hash algorithm for ''/etc/shadow'' from '''md5''' to stronger ones like '''sha512/bcrypt''' that helps to protect your password against rainbow-table attacks. See https://wiki.archlinux.org/index.php/SHA_password_hashes for more information.<br />
<br />
== Setup & Mounting ==<br />
<br />
eCryptfs is a part of Linux since version 2.6.19. But to work with it you will need the userspace tools provided by the package {{pkg|ecryptfs-utils}} available in the [[Official Repositories]].<br />
<br />
Once you have installed that package you can load the ecryptfs module and continue with the setup:<br />
# modprobe ecryptfs<br />
<br />
Before we say anything else it's advised that you check the eCryptfs documentation. It is distributed with a very good and complete set of manual pages.<br />
<br />
=== Using the Ubuntu tools ===<br />
<br />
Most of the user-friendly convenience tools installed by the ''ecryptfs-utils'' package assume a very specific eCryptfs setup, namely the one that is officially used by Ubuntu (where it can be selected as an option during distro installation). Unfortunately, these choices are not just default options but are actually hard-coded in the tools, so if this set-up does not suit your needs then you can't use the convenience tools and will have to follow the steps at [[#Manual_setup]] instead.<br />
<br />
The set-up used by these tools is as follows:<br />
{| style="border:solid 1px grey; margin-left:2em; margin-right:2em; margin-bottom:0.8em;"<br />
|<br />
* each user can have '''only one encrypted directory''' that is managed by these tools:<br />
** either full $HOME dir encryption...<br />
** or a single encrypted data directory ''(by default {{ic|~/Private/}}, but this can be customized)''.<br />
* the '''lower directory''' for each user is always {{ic|~/.Private/}}<br><small>''(in the case of full home dir encryption, this will be a symlink to the actual location at {{ic|/home/.ecryptfs/$USER/.Private/}})''</small><br />
* the '''encryption options''' used are:<br />
** ''cipher:'' AES<br />
** ''key length:'' 16 bytes (128 bits)<br />
** ''key management scheme:'' passphrase<br />
** ''plaintext passthrough:'' enabled<br />
* the '''configuration / control info''' for the encrypted directory is stored in a bunch of files at {{ic|~/.ecryptfs/}}:<br><small>''(in the case of full home dir encryption, this will be a symlink to the actual location at {{ic|/home/.ecryptfs/$USER/.ecryptfs/}})''</small><br />
** {{ic|Private.mnt}} ''[plain text file]'' - contains the path where the upper directory should be mounted (e.g. {{ic|/home/lucy}} or {{ic|/home/lucy/Private}})<br />
** {{ic|Private.sig}} ''[plain text file]'' - contains the signature used to identify the mount passphrase in the kernel keyring<br />
** {{ic|wrapped-passphrase}} ''[binary file]'' - the mount passphrase, encrypted with the login passphrase<br />
** {{ic|auto-mount}}, {{ic|auto-umount}} ''[empty files]'' - if they exist, the pam_ecryptfs.so module will (assuming it is loaded) automatically mount/unmount this encrypted directory when the user logs in/out<br />
|}<br />
<br />
==== Encrypting a data directory ====<br />
For a full $HOME directory encryption see [[#Encrypting a home directory]]<br />
<br />
To encrypt a single data directory as a user, run<br />
$ ecryptfs-setup-private<br />
and follow the instructions. It will automatically create the ~/.Private/ and ~/.ecryptfs/ directory structures as described in the box above. It will also ask for two passphrases:<br />
<br />
;''login passphrase'': This is the password you will have to enter each time you want to mount the encrypted directory. If you want auto-mounting on login to work, it has to be the same password you use to login to your user account; otherwise you can choose a different one.<br />
<br />
;''mount passphrase'': This is used to derive the actual file encryption master key. Thus you should not enter a custom one unless you know what you are doing - instead press Enter to let it auto-generate a random one, which will be much more secure. It will be encrypted using the login passphrase and stored in this encrypted form in {{ic|~/.ecryptfs/wrapped-passphrase}}, and automatically decrypted ("unwrapped") again in RAM when needed, so you never have to enter it manually. Make sure this file does not get lost, otherwise you can never access your encrypted folder again! You may want to run {{ic|ecryptfs-unwrap-passphrase}} to see the mount passphrase in unencrypted form, write it down on a piece of paper, and keep it in a safe (or similar), so you can use it to recover your encrypted data in case the ''wrapped-passphrase'' file is accidentally lost/corrupted or in case you forget the login passphrase.<br />
<br />
The mount point ("upper directory") for the encrypted folder will be at {{ic|~/Private}} by default, however you can manually change this right after the setup command has finished running, by doing:<br />
<br />
$ mv ~/Private /path/to/new/folder<br />
$ echo /path/to/new/folder > ~/.ecryptfs/Private.mnt<br />
<br />
To actually use your encrypted folder, you will have to mount it... See [[#Mounting]] below.<br />
<br />
===== Undo encryption =====<br />
To undo the single directory encryption run<br />
<br />
$ ecryptfs-setup-private --undo<br />
<br />
and follow the instructions<br />
<br />
==== Encrypting a home directory ====<br />
<br />
This will set up an encrypted $HOME directory for a user, and take care of migrating any existing files they have in their not yet encrypted home directory. Ensure that the user in question ''owns no processes'' and is ''logged out''. You also need to ensure that you have {{pkg|rsync}} installed. Once the prerequisites have been met run as root:<br />
<br />
# ecryptfs-migrate-home -u ''username''<br />
<br />
and follow the instructions. It is imperative that the user logs in ''before'' the next reboot, to complete the process.<br />
<br />
==== Mounting ====<br />
<br />
{{Expansion|<br>- explain how to mount on-demand, using ecryptfs-mount-private and ecryptfs-umount-private<br><br />
- explain how to mount from a live-CD, using ecryptfs-recover-private|section=Major_restructuring/rewrite}}<br />
<br />
==== Auto-mounting ====<br />
<br />
A better way is to use PAM directly, see 'PAM MODULE' in:<br />
/usr/share/doc/ecryptfs-utils/README<br />
<br />
1. Check if '''~/.ecryptfs/auto-mount''' and '''~/.ecryptfs/wrapped-passphrase''' (these are automatically created by '''ecryptfs-setup-private''') exist.<br />
<br />
2. Add ecryptfs to the pam-stack exactly as following to allow transparent unwrapping of the passphrase on login.<br />
<br />
Open '''/etc/pam.d/system-auth''' and add this ''after'' the line containing '''auth required pam_unix.so [...]''':<br />
auth required pam_ecryptfs.so unwrap<br />
, then add this ''above'' the line containing '''password required pam_unix.so [...]''':<br />
password optional pam_ecryptfs.so<br />
, and this ''after'' the line '''session required pam_unix.so''':<br />
session optional pam_ecryptfs.so<br />
<br />
3. Relogin (you need to type the user's password for obvious reason ;) and check output of '''mount''' which should now contain a mountpoint, e.g.:<br />
/home/$USER/.Private on /home/$USER/Private type ecryptfs (...)<br />
Your user's encrypted directory should be perfectly readable, e.g. $HOME/Private/<br />
<br />
Note that the latter will be automatically unmounted and made unavailable when the user log off.<br />
<br />
----<br />
<br />
{{Deletion|Does the following provide any useful information that isn't already contained in the top part of this section? Do we really need a full copy of all those PAM files here?}}<br />
<br />
To use the eCryptfs PAM module it self for mounting you should know it depends on some hard-coded Ubuntu defaults. Like using AES cipher with a 16 byte key. As described in this BBS post [https://bbs.archlinux.org/viewtopic.php?pid=727422#p727422] you have to do the following steps:<br />
<br />
1) For your understanding and preparation, read the guide mentioned above. [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html]<br />
<br />
2) Install [https://www.archlinux.org/packages/core/x86_64/keyutils/ keyutils] and [https://www.archlinux.org/packages/community/x86_64/ecryptfs-utils/ ecryptfs-utils] from the official Repos.<br />
<br />
'''[Do the following steps as root!]'''<br />
<br />
3) Make a "ecryptfs" Group:<br />
groupadd ecryptfs<br />
4) Add the user to it:<br />
usermod -aG ecryptfs user<br />
5) Load the ecryptfs module<br />
modprobe ecryptfs<br />
6) Change your /etc/pam.d/system-auth to look something like this (lines to add are bold):<br />
#%PAM-1.0<br />
<br />
auth required pam_env.so<br />
auth required pam_unix.so try_first_pass nullok<br />
'''auth required pam_ecryptfs.so unwrap'''<br />
auth optional pam_permit.so<br />
<br />
account required pam_unix.so<br />
account optional pam_permit.so<br />
account required pam_time.so<br />
<br />
'''password required pam_ecryptfs.so'''<br />
password required pam_unix.so try_first_pass nullok sha512 shadow<br />
password optional pam_permit.so<br />
<br />
'''session required pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
session required pam_env.so<br />
session required pam_unix.so<br />
session optional pam_permit.so<br />
<br />
<br />
6a) When using [[GDM]] < 3.2 to log in, edit /etc/pam.d/gdm like this:<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6b) For [[GDM]] >= 3.2, make the following changes to /etc/pam.d/gdm-password (thanks to grawity for [https://bbs.archlinux.org/viewtopic.php?pid=998061#p998061 this]):<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth requisite pam_unix.so nullok<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
auth sufficient pam_succeed_if.so uid >= 1000 quiet<br />
auth required pam_deny.so<br />
account required pam_unix.so<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
session required pam_loginuid.so<br />
-session optional pam_systemd.so<br />
session optional pam_keyinit.so '''force''' revoke<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
<br />
6c) For [[KDM]], make the following changes to /etc/pam.d/kde:<br />
<br />
#%PAM-1.0<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_nologin.so<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
<br />
6d) For [[LXDM]], make the following changes to /etc/pam.d/lxdm:<br />
<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6e) For [[LightDM]], make the following changes to /etc/pam.d/lightdm<br />
<br />
#%PAM-1.0<br />
auth required pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
<br />
7) To be able to automatically mount your encrypted home directory on login using SSH, edit /etc/pam.d/sshd:<br />
#%PAM-1.0<br />
#auth required pam_securetty.so #Disable remote root<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_env.so<br />
account required pam_nologin.so<br />
account required pam_unix.so<br />
account required pam_time.so<br />
password required pam_unix.so<br />
password optional pam_ecryptfs.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_unix_session.so<br />
session required pam_limits.so<br />
session optional pam_ck_connector.so nox11<br />
<br />
9) Log in and check if everything worked correctly.<br />
<br />
This is a working solution and ecryptfs is exactly used as in Ubuntu (10.04/10.10) - and is easy to set up. <br />
Besides this, it has the advantage of auto-unmount at log-out, which shell profile files (ie. ~/.bash_logout) could have trouble doing, because there could still be open file-descriptors by the shell at the time of umount. To encrypt swap see: [[System_Encryption_with_LUKS#Encrypting_the_Swap_partition]] (some of the tools provided by ecryptfs, such as ecryptfs-setup-swap, only work in ubuntu).<br />
<br />
=== Using ecryptfs-simple ===<br />
<br />
Use [http://xyne.archlinux.ca/projects/ecryptfs-simple/ ecryptfs-simple] if you just want to use eCryptfs to mount arbitrary directories the way you can with EncFS. ecryptfs-simple does not require root privileges or entries in fstab, nor is it limited to hard-coded directories such as ~/.Private. The package is available in the [https://aur.archlinux.org/packages.php?ID=59612 AUR] and in [http://xyne.archlinux.ca/repos/ Xyne's repos].<br />
<br />
As the name implies, usage is simple:<br />
# simple mounting<br />
ecryptfs-simple /path/to/foo /path/to/bar<br />
<br />
# automatic mounting: prompts for options on the first mount of a directory then reloads them next time<br />
ecryptfs-simple -a /path/to/foo /path/to/bar<br />
<br />
# unmounting by source directory<br />
ecryptfs-simple -u /path/to/foo<br />
<br />
# unmounting by mountpoint<br />
ecryptfs-simple -u /path/to/bar<br />
<br />
=== Manual setup ===<br />
<br />
{{Expansion|<br> - fully explain how to set up an encrypted '''data directory''' or '''home directory''' using mount.ecryptfs and ecryptfs-wrap-passphrase<br><br />
- this section should be more generic & comprehensive than it is now, and possibly be split into additional subsections|section=Major_restructuring/rewrite}}<br />
<br />
The ecryptfs-utils package is distributed with a few helper scripts which will help you with key management and similar tasks. Some were written to automate this whole process of setting up encrypted directories (''ecryptfs-setup-private'') or help you combine eCryptfs with dm-crypt to protect swap space (''ecryptfs-setup-swap''). Despite those scripts we will go trough the process manually so you get a better understanding of what is really being done.<br />
<br />
First create your private directories, in this example we will call them exactly that: Private<br />
$ su -<br />
# mkdir -m 700 /home/username/.Private<br />
# mkdir -m 500 /home/username/Private<br />
# chown username:username /home/username/{.Private,Private}<br />
<br />
Let's summarize<br />
* Actual encrypted data will be stored in ~/.Private directory (so-called ''lower'' directory)<br />
* While mounted, decrypted data will be available in ~/Private directory (so-called ''upper'' directory)<br />
** While not mounted nothing can be written to this directory<br />
** While mounted it has the same permissions as the lower directory<br />
<br />
eCryptfs can now be mounted on top of ~/Private.<br />
# mount -t ecryptfs /home/username/.Private /home/username/Private<br />
<br />
You will need to answer a few questions and provide a passphrase which should be used to mount this directory in the future. However you can also have different keys encrypting different data (more about this below). For convenience we will limit this guide to only one key and passphrase. Let's see an example:<br />
Key type: passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
Cipher: aes<br />
Key byte: 16<br />
Plaintext passtrough: no<br />
Filename encryption: no<br />
Add signature to cache: yes <br />
<br />
Let's summarize<br />
* The passphrase is your '''mount passphrase''' which will be salted, hashed and loaded into the kernel keyring.<br />
** In eCryptfs terms, this salted, hashed passphrase is your "file encryption key, encryption key", or '''fekek'''.<br />
* eCryptfs supports a few different ciphers (AES, blowfish, twofish...). You can read about them on Wikipedia.<br />
* Plaintext passtrough enables you to store and work with '''un-encrypted''' files stored in the lower directory.<br />
* Filename encryption is available since Linux 2.6.29<br />
** In eCryptfs terms the key used to protect filenames is known as "filename encryption key", or '''fnek'''.<br />
* The signature of the key(s) will be stored in {{ic|/root/.ecryptfs/sig-cache.txt}}.<br />
<br />
Since our later goal is to be able to mount without root privileges, we will now move the eCryptfs configuration directory to your own home and transfer the ownership to you:<br />
# mv /root/.ecryptfs /home/username<br />
# chown username:username /home/username/.ecryptfs<br />
<br />
Your setup is now complete and directory is mounted. You can place any file in the '''~/Private''' directory and it will get encrypted in '''~/.Private'''.<br />
<br />
Now copy a few files to your new private directory, and then un-mount it. If you inspect the files you will see that they are unreadable &ndash; encrypted. That was cool you say, but how do I get them back... and that brings us to:<br />
<br />
----<br />
<br />
Above is detailed the simplest way to setup the mount point, but '''ecryptfs-setup-private''' runs through some extra steps.<br />
<br />
* The above '''mount passphrase''' is derived from the passphrase you type in. This is not considered very [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#pubkey-about secure], so the setup script grabs some characters from {{ic|/dev/random}} for safety:<br />
<br />
od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | sed "s/^0000000//" | sed "s/\s*//g"<br />
<br />
* '''ecryptfs-setup-private''' also takes the resulting mount passphrase and wraps it with your login passphrase (pasword) and stores this in '''~/.ecryptfs/wrapped-passphrase'''. You can replicate this with: <br />
<br />
$ ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase <br />
Passphrase to wrap: <br />
Wrapping passphrase:<br />
<br />
==== Mounting ====<br />
<br />
{{Expansion|<br> - fully explain how to mount on-demand, using ecryptfs-add-passphrase and mount.ecryptfs<br><br />
- this section should be more generic & comprehensive than it is now|section=Major_restructuring/rewrite}}<br />
<br />
Whenever you need your files available you can repeat the above mount procedure, using the same passphrase and options if you want to access your previously encrypted files or using a different passphrase (and possibly options) if for some reason you want to have different keys protecting different data (imagine having a publicly shared directory where different data is encrypted by different users, and their keys).<br />
<br />
In any case going trough those questions every time could be a bit tedious.<br />
<br />
One solution would be to create an entry in the '''{{ic|/etc/fstab}}''' file for this mount point:<br />
<br />
/home/user/.Private /home/user/Private ecryptfs [... user ... ecryptfs_sig=XY,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0<br />
<br />
* You will notice that we defined the '''user''' option, it enables you to mount the directory as a user (if it does not works as a normal user, you may need to setuid mount.ecryptfs by running as root: ''chmod +s /sbin/mount.ecryptfs'')<br />
* Notice the '''ecryptfs_sig''' option, replace ''XY'' with your own key signature (as seen in the '''mtab''' line earlier and in {{ic|sig-cache.txt}})<br />
* If you enabled filename encryption then pass an additional mount option: '''ecryptfs_fnek_sig'''=''XY'', where ''XY'' is the same signature you provide with the '''ecryptfs_sig''' option.<br />
* Last option '''ecrypfs_unlink_sigs''' ensures that your keyring is cleared every time the directory is un-mounted<br />
<br />
Since your key was deleted from the kernel keyring when you un-mounted, in order to mount you need to insert it into the keyring again. You can use the '''ecryptfs-add-passphrase''' utility or the '''ecryptfs-manager''' to do it:<br />
<br />
When the key is inserted you can mount the directory: <br />
$ ecryptfs-add-passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
<br />
$ mount -i /home/username/Private<br />
<br />
You will notice that we used the '''{{Ic|-i}}''' option this time. It disables invoking the mount helper. Speaking of which, using {{Ic|-i}} by default mounts with: '''nosuid, noexec''' and '''nodev'''. If you want to have at least executable files in your private directory you can add the '''exec''' option to the fstab line.<br />
<br />
This would be a good place to mention the '''keyctl''' utility from the (earlier installed) ''keyutils'' package. It can be used for any advanced key management tasks. Following examples show how to list your keyring contents and how to clear them:<br />
$ keyctl list @u<br />
$ keyctl clear @u<br />
<br />
{{Note|However, one should remember that /etc/fstab is for system-wide partitions only and should not be used for user-specific mounts}}<br />
<br />
==== Auto-mounting ====<br />
<br />
{{Expansion|<br>- this section should be more generic & comprehensive than it is now<br><br />
- make sure it properly fits in with the article structure|section=Major_restructuring/rewrite}}<br />
<br />
The above "''eCryptfs and $HOME''" article uses a shell init file to mount the home directory. The same can be done using [[pam_mount]] with the added benefit that home is un-mounted when all sessions are logged out. Add the following lines to {{ic|/etc/security/pam_mount.conf.xml}}:<br />
<br />
<luserconf name=".pam_mount.conf.xml" /><br />
<mntoptions require="" /> <!-- Default required mount options are ; this clears them --><br />
<lclmount>mount -i %(VOLUME) "%(before=\"-o\" OPTIONS)"</lclmount> <!-- --><br />
<br />
Please prefer writing manually these lines instead of simply copy/pasting them (especially the lclmount line), otherwise you might get some corrupted characters.<br />
Explanation:<br />
* the first line indicates where the user-based configuration file is located (here {{ic|~/.pam_mount.conf.xml}}) ;<br />
* the second line overwrites the default required mount options which are unnecessary ("nosuid,nodev") ;<br />
* the last line indicates which mount command to run (eCryptfs needs the {{Ic|-i}} switch).<br />
<br />
Then set the volume definition, preferably to {{ic|~/.pam_mount.conf.xml}}:<br />
<pam_mount><br />
<volume noroot="1" fstype="ecryptfs" path="/home/.ecryptfs/user/.Private/" mountpoint="/home/user/"/><br />
</pam_mount><br />
<br />
"noroot" is needed because the encryption key will be added to the user's keyring<br />
<br />
Finally, edit {{ic|/etc/pam.d/login}} as described in [[pam_mount]]'s article.<br />
<br />
===== Optional step =====<br />
<br />
To avoid wasting time needlessly unwrapping the passphrase you can create a script that will check ''pmvarrun'' to see the number of open sessions:<br />
#!/bin/sh<br />
#<br />
# /usr/local/bin/doecryptfs<br />
<br />
exit $(/usr/sbin/pmvarrun -u$PAM_USER -o0)<br />
<br />
With the following line added before the eCryptfs unwrap module in your PAM stack:<br />
auth [success=ignore default=1] pam_exec.so quiet /usr/local/bin/doecryptfs<br />
auth required pam_ecryptfs.so unwrap<br />
The article suggests adding these to {{ic|/etc/pam.d/login}}, but the changes will need to be added to all other places you login, such as {{ic|/etc/pam.d/kde}}.<br />
<br />
== Usage ==<br />
<br />
{{Expansion|<br> - point to the above "Setup & Mounting" section for how to mount and unmount [this section here will cover all other (i.e. setup-independent) usage info]<br><br />
- explain how to interact with encrypted files using ecryptfs-stat, ecryptfs-find, ecryptfs-rewrite-file<br><br />
- discuss symlinking into the encrypted container<br><br />
- discuss placing non-encrypted files or folders in the encrypted container ("pass-through")<br><br />
- discuss backup strategies<br />
|section=Major_restructuring/rewrite}}<br />
<br />
Besides using your private directory as storage for sensitive files, and private data, you can also use it to protect application data. Take ''Firefox'' for an example, not only does it have an internal password manager but the browsing history and cache can also be sensitive. Protecting it is easy:<br />
$ mv ~/.mozilla ~/Private/mozilla<br />
$ ln -s ~/Private/mozilla ~/.mozilla<br />
<br />
=== Removal ===<br />
<br />
If you want to move a file out of the private directory just move it to it's new destination while ~/Private is mounted. Also note that there are no special steps involved if you want to remove your private directory. Make sure it is un-mounted and delete ~/.Private, along with all the files.<br />
<br />
=== Backup ===<br />
<br />
Setup explained here separates the directory with encrypted data from the mount point, so the encrypted data is available for backup at any time. With an overlay mount (i.e. ''~/Secret'' mounted over ''~/Secret'') the lower, encrypted, data is harder to get to. Today when cronjobs and other automation software do automatic backups the risk of leaking your sensitive data is higher.<br />
<br />
We explained earlier that all cryptographic metadata is stored in the headers of files. You can easily do backups, or incremental backups, of your '''~/.Private''' directory, treating it like any other directory.<br />
<br />
== See Also ==<br />
<br />
{{Deletion|Regardless of what some blog author thinks, this wiki should strive to treat the topic of disk encryption with eCryptfs comprehensively (within reasonable limits of course). If there are multiple good options at any particular step, then multiple options should be listed. Once this wiki page will have achieved that goal, the following should be deleted (or replaced by a plain "See Also" link list.)|section=Major_restructuring/rewrite}}<br />
<br />
This wiki article covers only the basic setup of a private encrypted directory. There is however another article about eCryptfs on Arch Linux, which covers encryption of your entire $HOME and encrypting swap space without breaking hibernation (suspend to disk).<br />
<br />
That article includes many more steps (i.e. using PAM modules and automatic mounting) and the author was opposed to replicating it here, because there is just no single "right" way to do it. The author proposes some solutions and discusses the security implications, but they are his solutions and as such might not be the best nor are they endorsed by the eCryptfs project in any way.<br />
<br />
Article: [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html eCryptfs and $HOME] by Adrian C. (anrxc).<br />
<br />
Consider that ''Chromium OS'', as released by Google, is using eCryptfs to protect devices that are, and will be, powered by it. Some implementation details are available and they make excellent reading. You can read them [http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data here], they could help a lot as you're coming up with your own strategy.</div>Xorrrhttps://wiki.archlinux.org/index.php?title=ECryptfs&diff=295258ECryptfs2014-02-01T01:31:14Z<p>Xorrr: Add link to the encrypt home dir part, because i thought i had to encrypt the data dir first</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[fr:Encryption avec eCryptfs]]<br />
[[it:System Encryption with eCryptfs]]<br />
[[ru:System Encryption with eCryptfs]]<br />
{{Related articles start}}<br />
{{Related|Disk Encryption}}<br />
{{Related articles end}}<br />
This article describes basic usage of [https://launchpad.net/ecryptfs eCryptfs]. It guides you through the process of creating a private and secure encrypted directory within your ''$HOME'' directory, where you can store all your sensitive files and private data.<br />
<br />
In implementation eCryptfs differs from dm-crypt, which provides a ''block device encryption layer'', while eCryptfs is an actual file-system &ndash; a [http://en.wikipedia.org/wiki/Cryptographic_filesystems stacked cryptographic file system] to be exact. For comparison of the two you can refer to [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare this table ]. <br />
<br />
The summary is that it doesn't require special on-disk storage allocation effort, such as separate partitions, you can mount eCryptfs on top of any single directory to protect it. That includes e.g. your entire $HOME and network file systems (i.e. having encrypted NFS shares). All cryptographic metadata is stored in the headers of files, so encrypted data can be easily moved, stored for backup and recovered. There are other advantages, but there are also drawbacks, for instance eCryptfs is not suitable for encrypting complete partitions which also means you can't protect your swap space with it (instead you can combine it with dm-crypt).<br />
<br />
For more details on how eCryptfs compares to other disk encryption solutions, see [[Disk Encryption#Comparison table]]. <br />
<br />
== Basics ==<br />
<br />
See [[Disk_Encryption#Available_methods]] for a general introduction to stacked filesystem encryption, and how it compares to block device encryption.<br />
<br />
{{Expansion|<br> - Explain the basic mechanisms & terminology at the heart of eCryptfs ("mounting", "FEKEK", "wrapped passphrase", etc.) in simple terms|section=Major_restructuring/rewrite}}<br />
<br />
== Preparation ==<br />
<br />
Before starting to set up disk encryption, there are a few things to consider and to prepare in advance: [[Disk_Encryption#Preparation]]<br />
<br />
{{Expansion|<br> - discuss the 2 real-life set-ups for which eCryptfs is especially well suited: <u>encrypted data directory</u> and <u>encrypted home directory</u><br><br />
- discuss swap, and point to [[dm-crypt/Swap_Encryption]] for instructions [and make sure that article is written in a self-contained way that does not assume readers arrived from other dm-crypt articles!]|section=Major_restructuring/rewrite}}<br />
<br />
=== Deficiencies ===<br />
<br />
{{Accuracy|check if the warning about sparse files is still applicable}}<br />
<br />
eCryptfs does not handle [https://en.wikipedia.org/wiki/Sparse_file sparse files] well; this should be considered before encrypting large portions of the directory structure ($HOME, for example). For most intents and purposes this deficiency does not pose a problem. Using eCryptfs to encrypt sparse files, however, currently encrypts the entire allocated space of the sparse file, which, in the case of big files, can starve the system of resources. (This bug may be tracked [https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/431975 on Launchpad]). One popular and inadvisable application of eCryptfs is to encrypt a BitTorrent download location; this often requires eCryptfs to handle sparse files of 10 GB or more and may lead to intense disk starvation. A simple workaround is to place sparse files in an unencrypted '''.Public''' directory (as opposed to the standard eCryptfs '''.Private''' directory, explained below).<br />
<br />
=== Login password ===<br />
<br />
{{Deletion|Already covered in [[Disk_Encryption#Preparation]], which is linked to above.}}<br />
<br />
{{note|1= With {{pkg|shadow}} 4.1.4.3-3 ''sha512'' is the default for new passwords (see [https://bugs.archlinux.org/task/13591#comment85993 bug 13591] and corresponding [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/shadow&id=98001501a8306ef5a0df55d1cffc048851894940 commit]).}}<br />
<br />
If you are encrypting your whole home, with auto-mounting you should use a strong password and consider changing the hash algorithm for ''/etc/shadow'' from '''md5''' to stronger ones like '''sha512/bcrypt''' that helps to protect your password against rainbow-table attacks. See https://wiki.archlinux.org/index.php/SHA_password_hashes for more information.<br />
<br />
== Setup & Mounting ==<br />
<br />
eCryptfs is a part of Linux since version 2.6.19. But to work with it you will need the userspace tools provided by the package {{pkg|ecryptfs-utils}} available in the [[Official Repositories]].<br />
<br />
Once you have installed that package you can load the ecryptfs module and continue with the setup:<br />
# modprobe ecryptfs<br />
<br />
Before we say anything else it's advised that you check the eCryptfs documentation. It is distributed with a very good and complete set of manual pages.<br />
<br />
=== Using the Ubuntu tools ===<br />
<br />
Most of the user-friendly convenience tools installed by the ''ecryptfs-utils'' package assume a very specific eCryptfs setup, namely the one that is officially used by Ubuntu (where it can be selected as an option during distro installation). Unfortunately, these choices are not just default options but are actually hard-coded in the tools, so if this set-up does not suit your needs then you can't use the convenience tools and will have to follow the steps at [[#Manual_setup]] instead.<br />
<br />
The set-up used by these tools is as follows:<br />
{| style="border:solid 1px grey; margin-left:2em; margin-right:2em; margin-bottom:0.8em;"<br />
|<br />
* each user can have '''only one encrypted directory''' that is managed by these tools:<br />
** either full $HOME dir encryption...<br />
** or a single encrypted data directory ''(by default {{ic|~/Private/}}, but this can be customized)''.<br />
* the '''lower directory''' for each user is always {{ic|~/.Private/}}<br><small>''(in the case of full home dir encryption, this will be a symlink to the actual location at {{ic|/home/.ecryptfs/$USER/.Private/}})''</small><br />
* the '''encryption options''' used are:<br />
** ''cipher:'' AES<br />
** ''key length:'' 16 bytes (128 bits)<br />
** ''key management scheme:'' passphrase<br />
** ''plaintext passthrough:'' enabled<br />
* the '''configuration / control info''' for the encrypted directory is stored in a bunch of files at {{ic|~/.ecryptfs/}}:<br><small>''(in the case of full home dir encryption, this will be a symlink to the actual location at {{ic|/home/.ecryptfs/$USER/.ecryptfs/}})''</small><br />
** {{ic|Private.mnt}} ''[plain text file]'' - contains the path where the upper directory should be mounted (e.g. {{ic|/home/lucy}} or {{ic|/home/lucy/Private}})<br />
** {{ic|Private.sig}} ''[plain text file]'' - contains the signature used to identify the mount passphrase in the kernel keyring<br />
** {{ic|wrapped-passphrase}} ''[binary file]'' - the mount passphrase, encrypted with the login passphrase<br />
** {{ic|auto-mount}}, {{ic|auto-umount}} ''[empty files]'' - if they exist, the pam_ecryptfs.so module will (assuming it is loaded) automatically mount/unmount this encrypted directory when the user logs in/out<br />
|}<br />
<br />
==== Encrypting a data directory ====<br />
For a full $HOME directory encryption see [[#Encrypting a home directory]]<br />
<br />
To encrypt a single data directory as a user, run<br />
$ ecryptfs-setup-private<br />
and follow the instructions. It will automatically create the ~/.Private/ and ~/.ecryptfs/ directory structures as described in the box above. It will also ask for two passphrases:<br />
<br />
;''login passphrase'': This is the password you will have to enter each time you want to mount the encrypted directory. If you want auto-mounting on login to work, it has to be the same password you use to login to your user account; otherwise you can choose a different one.<br />
<br />
;''mount passphrase'': This is used to derive the actual file encryption master key. Thus you should not enter a custom one unless you know what you are doing - instead press Enter to let it auto-generate a random one, which will be much more secure. It will be encrypted using the login passphrase and stored in this encrypted form in {{ic|~/.ecryptfs/wrapped-passphrase}}, and automatically decrypted ("unwrapped") again in RAM when needed, so you never have to enter it manually. Make sure this file does not get lost, otherwise you can never access your encrypted folder again! You may want to run {{ic|ecryptfs-unwrap-passphrase}} to see the mount passphrase in unencrypted form, write it down on a piece of paper, and keep it in a safe (or similar), so you can use it to recover your encrypted data in case the ''wrapped-passphrase'' file is accidentally lost/corrupted or in case you forget the login passphrase.<br />
<br />
The mount point ("upper directory") for the encrypted folder will be at {{ic|~/Private}} by default, however you can manually change this right after the setup command has finished running, by doing:<br />
<br />
$ mv ~/Private /path/to/new/folder<br />
$ echo /path/to/new/folder > ~/.ecryptfs/Private.mnt<br />
<br />
To actually use your encrypted folder, you will have to mount it... See [[#Mounting]] below.<br />
<br />
==== Encrypting a home directory ====<br />
<br />
This will set up an encrypted $HOME directory for a user, and take care of migrating any existing files they have in their not yet encrypted home directory. Ensure that the user in question ''owns no processes'' and is ''logged out''. You also need to ensure that you have {{pkg|rsync}} installed. Once the prerequisites have been met run as root:<br />
<br />
# ecryptfs-migrate-home -u ''username''<br />
<br />
and follow the instructions. It is imperative that the user logs in ''before'' the next reboot, to complete the process.<br />
<br />
==== Mounting ====<br />
<br />
{{Expansion|<br>- explain how to mount on-demand, using ecryptfs-mount-private and ecryptfs-umount-private<br><br />
- explain how to mount from a live-CD, using ecryptfs-recover-private|section=Major_restructuring/rewrite}}<br />
<br />
==== Auto-mounting ====<br />
<br />
A better way is to use PAM directly, see 'PAM MODULE' in:<br />
/usr/share/doc/ecryptfs-utils/README<br />
<br />
1. Check if '''~/.ecryptfs/auto-mount''' and '''~/.ecryptfs/wrapped-passphrase''' (these are automatically created by '''ecryptfs-setup-private''') exist.<br />
<br />
2. Add ecryptfs to the pam-stack exactly as following to allow transparent unwrapping of the passphrase on login.<br />
<br />
Open '''/etc/pam.d/system-auth''' and add this ''after'' the line containing '''auth required pam_unix.so [...]''':<br />
auth required pam_ecryptfs.so unwrap<br />
, then add this ''above'' the line containing '''password required pam_unix.so [...]''':<br />
password optional pam_ecryptfs.so<br />
, and this ''after'' the line '''session required pam_unix.so''':<br />
session optional pam_ecryptfs.so<br />
<br />
3. Relogin (you need to type the user's password for obvious reason ;) and check output of '''mount''' which should now contain a mountpoint, e.g.:<br />
/home/$USER/.Private on /home/$USER/Private type ecryptfs (...)<br />
Your user's encrypted directory should be perfectly readable, e.g. $HOME/Private/<br />
<br />
Note that the latter will be automatically unmounted and made unavailable when the user log off.<br />
<br />
----<br />
<br />
{{Deletion|Does the following provide any useful information that isn't already contained in the top part of this section? Do we really need a full copy of all those PAM files here?}}<br />
<br />
To use the eCryptfs PAM module it self for mounting you should know it depends on some hard-coded Ubuntu defaults. Like using AES cipher with a 16 byte key. As described in this BBS post [https://bbs.archlinux.org/viewtopic.php?pid=727422#p727422] you have to do the following steps:<br />
<br />
1) For your understanding and preparation, read the guide mentioned above. [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html]<br />
<br />
2) Install [https://www.archlinux.org/packages/core/x86_64/keyutils/ keyutils] and [https://www.archlinux.org/packages/community/x86_64/ecryptfs-utils/ ecryptfs-utils] from the official Repos.<br />
<br />
'''[Do the following steps as root!]'''<br />
<br />
3) Make a "ecryptfs" Group:<br />
groupadd ecryptfs<br />
4) Add the user to it:<br />
usermod -aG ecryptfs user<br />
5) Load the ecryptfs module<br />
modprobe ecryptfs<br />
6) Change your /etc/pam.d/system-auth to look something like this (lines to add are bold):<br />
#%PAM-1.0<br />
<br />
auth required pam_env.so<br />
auth required pam_unix.so try_first_pass nullok<br />
'''auth required pam_ecryptfs.so unwrap'''<br />
auth optional pam_permit.so<br />
<br />
account required pam_unix.so<br />
account optional pam_permit.so<br />
account required pam_time.so<br />
<br />
'''password required pam_ecryptfs.so'''<br />
password required pam_unix.so try_first_pass nullok sha512 shadow<br />
password optional pam_permit.so<br />
<br />
'''session required pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
session required pam_env.so<br />
session required pam_unix.so<br />
session optional pam_permit.so<br />
<br />
<br />
6a) When using [[GDM]] < 3.2 to log in, edit /etc/pam.d/gdm like this:<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6b) For [[GDM]] >= 3.2, make the following changes to /etc/pam.d/gdm-password (thanks to grawity for [https://bbs.archlinux.org/viewtopic.php?pid=998061#p998061 this]):<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth requisite pam_unix.so nullok<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth optional pam_gnome_keyring.so<br />
auth sufficient pam_succeed_if.so uid >= 1000 quiet<br />
auth required pam_deny.so<br />
account required pam_unix.so<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
session required pam_loginuid.so<br />
-session optional pam_systemd.so<br />
session optional pam_keyinit.so '''force''' revoke<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session optional pam_gnome_keyring.so auto_start<br />
<br />
6c) For [[KDM]], make the following changes to /etc/pam.d/kde:<br />
<br />
#%PAM-1.0<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_nologin.so<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_limits.so<br />
<br />
6d) For [[LXDM]], make the following changes to /etc/pam.d/lxdm:<br />
<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
password required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
<br />
6e) For [[LightDM]], make the following changes to /etc/pam.d/lightdm<br />
<br />
#%PAM-1.0<br />
auth required pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
account required pam_unix.so<br />
'''password optional pam_ecryptfs.so'''<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
<br />
7) To be able to automatically mount your encrypted home directory on login using SSH, edit /etc/pam.d/sshd:<br />
#%PAM-1.0<br />
#auth required pam_securetty.so #Disable remote root<br />
auth required pam_unix.so<br />
'''auth optional pam_ecryptfs.so unwrap'''<br />
auth required pam_env.so<br />
account required pam_nologin.so<br />
account required pam_unix.so<br />
account required pam_time.so<br />
password required pam_unix.so<br />
password optional pam_ecryptfs.so<br />
'''session optional pam_ecryptfs.so unwrap'''<br />
session required pam_unix_session.so<br />
session required pam_limits.so<br />
session optional pam_ck_connector.so nox11<br />
<br />
9) Log in and check if everything worked correctly.<br />
<br />
This is a working solution and ecryptfs is exactly used as in Ubuntu (10.04/10.10) - and is easy to set up. <br />
Besides this, it has the advantage of auto-unmount at log-out, which shell profile files (ie. ~/.bash_logout) could have trouble doing, because there could still be open file-descriptors by the shell at the time of umount. To encrypt swap see: [[System_Encryption_with_LUKS#Encrypting_the_Swap_partition]] (some of the tools provided by ecryptfs, such as ecryptfs-setup-swap, only work in ubuntu).<br />
<br />
=== Using ecryptfs-simple ===<br />
<br />
Use [http://xyne.archlinux.ca/projects/ecryptfs-simple/ ecryptfs-simple] if you just want to use eCryptfs to mount arbitrary directories the way you can with EncFS. ecryptfs-simple does not require root privileges or entries in fstab, nor is it limited to hard-coded directories such as ~/.Private. The package is available in the [https://aur.archlinux.org/packages.php?ID=59612 AUR] and in [http://xyne.archlinux.ca/repos/ Xyne's repos].<br />
<br />
As the name implies, usage is simple:<br />
# simple mounting<br />
ecryptfs-simple /path/to/foo /path/to/bar<br />
<br />
# automatic mounting: prompts for options on the first mount of a directory then reloads them next time<br />
ecryptfs-simple -a /path/to/foo /path/to/bar<br />
<br />
# unmounting by source directory<br />
ecryptfs-simple -u /path/to/foo<br />
<br />
# unmounting by mountpoint<br />
ecryptfs-simple -u /path/to/bar<br />
<br />
=== Manual setup ===<br />
<br />
{{Expansion|<br> - fully explain how to set up an encrypted '''data directory''' or '''home directory''' using mount.ecryptfs and ecryptfs-wrap-passphrase<br><br />
- this section should be more generic & comprehensive than it is now, and possibly be split into additional subsections|section=Major_restructuring/rewrite}}<br />
<br />
The ecryptfs-utils package is distributed with a few helper scripts which will help you with key management and similar tasks. Some were written to automate this whole process of setting up encrypted directories (''ecryptfs-setup-private'') or help you combine eCryptfs with dm-crypt to protect swap space (''ecryptfs-setup-swap''). Despite those scripts we will go trough the process manually so you get a better understanding of what is really being done.<br />
<br />
First create your private directories, in this example we will call them exactly that: Private<br />
$ su -<br />
# mkdir -m 700 /home/username/.Private<br />
# mkdir -m 500 /home/username/Private<br />
# chown username:username /home/username/{.Private,Private}<br />
<br />
Let's summarize<br />
* Actual encrypted data will be stored in ~/.Private directory (so-called ''lower'' directory)<br />
* While mounted, decrypted data will be available in ~/Private directory (so-called ''upper'' directory)<br />
** While not mounted nothing can be written to this directory<br />
** While mounted it has the same permissions as the lower directory<br />
<br />
eCryptfs can now be mounted on top of ~/Private.<br />
# mount -t ecryptfs /home/username/.Private /home/username/Private<br />
<br />
You will need to answer a few questions and provide a passphrase which should be used to mount this directory in the future. However you can also have different keys encrypting different data (more about this below). For convenience we will limit this guide to only one key and passphrase. Let's see an example:<br />
Key type: passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
Cipher: aes<br />
Key byte: 16<br />
Plaintext passtrough: no<br />
Filename encryption: no<br />
Add signature to cache: yes <br />
<br />
Let's summarize<br />
* The passphrase is your '''mount passphrase''' which will be salted, hashed and loaded into the kernel keyring.<br />
** In eCryptfs terms, this salted, hashed passphrase is your "file encryption key, encryption key", or '''fekek'''.<br />
* eCryptfs supports a few different ciphers (AES, blowfish, twofish...). You can read about them on Wikipedia.<br />
* Plaintext passtrough enables you to store and work with '''un-encrypted''' files stored in the lower directory.<br />
* Filename encryption is available since Linux 2.6.29<br />
** In eCryptfs terms the key used to protect filenames is known as "filename encryption key", or '''fnek'''.<br />
* The signature of the key(s) will be stored in {{ic|/root/.ecryptfs/sig-cache.txt}}.<br />
<br />
Since our later goal is to be able to mount without root privileges, we will now move the eCryptfs configuration directory to your own home and transfer the ownership to you:<br />
# mv /root/.ecryptfs /home/username<br />
# chown username:username /home/username/.ecryptfs<br />
<br />
Your setup is now complete and directory is mounted. You can place any file in the '''~/Private''' directory and it will get encrypted in '''~/.Private'''.<br />
<br />
Now copy a few files to your new private directory, and then un-mount it. If you inspect the files you will see that they are unreadable &ndash; encrypted. That was cool you say, but how do I get them back... and that brings us to:<br />
<br />
----<br />
<br />
Above is detailed the simplest way to setup the mount point, but '''ecryptfs-setup-private''' runs through some extra steps.<br />
<br />
* The above '''mount passphrase''' is derived from the passphrase you type in. This is not considered very [http://ecryptfs.sourceforge.net/ecryptfs-faq.html#pubkey-about secure], so the setup script grabs some characters from {{ic|/dev/random}} for safety:<br />
<br />
od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | sed "s/^0000000//" | sed "s/\s*//g"<br />
<br />
* '''ecryptfs-setup-private''' also takes the resulting mount passphrase and wraps it with your login passphrase (pasword) and stores this in '''~/.ecryptfs/wrapped-passphrase'''. You can replicate this with: <br />
<br />
$ ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase <br />
Passphrase to wrap: <br />
Wrapping passphrase:<br />
<br />
==== Mounting ====<br />
<br />
{{Expansion|<br> - fully explain how to mount on-demand, using ecryptfs-add-passphrase and mount.ecryptfs<br><br />
- this section should be more generic & comprehensive than it is now|section=Major_restructuring/rewrite}}<br />
<br />
Whenever you need your files available you can repeat the above mount procedure, using the same passphrase and options if you want to access your previously encrypted files or using a different passphrase (and possibly options) if for some reason you want to have different keys protecting different data (imagine having a publicly shared directory where different data is encrypted by different users, and their keys).<br />
<br />
In any case going trough those questions every time could be a bit tedious.<br />
<br />
One solution would be to create an entry in the '''{{ic|/etc/fstab}}''' file for this mount point:<br />
<br />
/home/user/.Private /home/user/Private ecryptfs [... user ... ecryptfs_sig=XY,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0<br />
<br />
* You will notice that we defined the '''user''' option, it enables you to mount the directory as a user (if it does not works as a normal user, you may need to setuid mount.ecryptfs by running as root: ''chmod +s /sbin/mount.ecryptfs'')<br />
* Notice the '''ecryptfs_sig''' option, replace ''XY'' with your own key signature (as seen in the '''mtab''' line earlier and in {{ic|sig-cache.txt}})<br />
* If you enabled filename encryption then pass an additional mount option: '''ecryptfs_fnek_sig'''=''XY'', where ''XY'' is the same signature you provide with the '''ecryptfs_sig''' option.<br />
* Last option '''ecrypfs_unlink_sigs''' ensures that your keyring is cleared every time the directory is un-mounted<br />
<br />
Since your key was deleted from the kernel keyring when you un-mounted, in order to mount you need to insert it into the keyring again. You can use the '''ecryptfs-add-passphrase''' utility or the '''ecryptfs-manager''' to do it:<br />
<br />
When the key is inserted you can mount the directory: <br />
$ ecryptfs-add-passphrase<br />
Passphrase: ThisIsAVeryWeakPassphrase<br />
<br />
$ mount -i /home/username/Private<br />
<br />
You will notice that we used the '''{{Ic|-i}}''' option this time. It disables invoking the mount helper. Speaking of which, using {{Ic|-i}} by default mounts with: '''nosuid, noexec''' and '''nodev'''. If you want to have at least executable files in your private directory you can add the '''exec''' option to the fstab line.<br />
<br />
This would be a good place to mention the '''keyctl''' utility from the (earlier installed) ''keyutils'' package. It can be used for any advanced key management tasks. Following examples show how to list your keyring contents and how to clear them:<br />
$ keyctl list @u<br />
$ keyctl clear @u<br />
<br />
{{Note|However, one should remember that /etc/fstab is for system-wide partitions only and should not be used for user-specific mounts}}<br />
<br />
==== Auto-mounting ====<br />
<br />
{{Expansion|<br>- this section should be more generic & comprehensive than it is now<br><br />
- make sure it properly fits in with the article structure|section=Major_restructuring/rewrite}}<br />
<br />
The above "''eCryptfs and $HOME''" article uses a shell init file to mount the home directory. The same can be done using [[pam_mount]] with the added benefit that home is un-mounted when all sessions are logged out. Add the following lines to {{ic|/etc/security/pam_mount.conf.xml}}:<br />
<br />
<luserconf name=".pam_mount.conf.xml" /><br />
<mntoptions require="" /> <!-- Default required mount options are ; this clears them --><br />
<lclmount>mount -i %(VOLUME) "%(before=\"-o\" OPTIONS)"</lclmount> <!-- --><br />
<br />
Please prefer writing manually these lines instead of simply copy/pasting them (especially the lclmount line), otherwise you might get some corrupted characters.<br />
Explanation:<br />
* the first line indicates where the user-based configuration file is located (here {{ic|~/.pam_mount.conf.xml}}) ;<br />
* the second line overwrites the default required mount options which are unnecessary ("nosuid,nodev") ;<br />
* the last line indicates which mount command to run (eCryptfs needs the {{Ic|-i}} switch).<br />
<br />
Then set the volume definition, preferably to {{ic|~/.pam_mount.conf.xml}}:<br />
<pam_mount><br />
<volume noroot="1" fstype="ecryptfs" path="/home/.ecryptfs/user/.Private/" mountpoint="/home/user/"/><br />
</pam_mount><br />
<br />
"noroot" is needed because the encryption key will be added to the user's keyring<br />
<br />
Finally, edit {{ic|/etc/pam.d/login}} as described in [[pam_mount]]'s article.<br />
<br />
===== Optional step =====<br />
<br />
To avoid wasting time needlessly unwrapping the passphrase you can create a script that will check ''pmvarrun'' to see the number of open sessions:<br />
#!/bin/sh<br />
#<br />
# /usr/local/bin/doecryptfs<br />
<br />
exit $(/usr/sbin/pmvarrun -u$PAM_USER -o0)<br />
<br />
With the following line added before the eCryptfs unwrap module in your PAM stack:<br />
auth [success=ignore default=1] pam_exec.so quiet /usr/local/bin/doecryptfs<br />
auth required pam_ecryptfs.so unwrap<br />
The article suggests adding these to {{ic|/etc/pam.d/login}}, but the changes will need to be added to all other places you login, such as {{ic|/etc/pam.d/kde}}.<br />
<br />
== Usage ==<br />
<br />
{{Expansion|<br> - point to the above "Setup & Mounting" section for how to mount and unmount [this section here will cover all other (i.e. setup-independent) usage info]<br><br />
- explain how to interact with encrypted files using ecryptfs-stat, ecryptfs-find, ecryptfs-rewrite-file<br><br />
- discuss symlinking into the encrypted container<br><br />
- discuss placing non-encrypted files or folders in the encrypted container ("pass-through")<br><br />
- discuss backup strategies<br />
|section=Major_restructuring/rewrite}}<br />
<br />
Besides using your private directory as storage for sensitive files, and private data, you can also use it to protect application data. Take ''Firefox'' for an example, not only does it have an internal password manager but the browsing history and cache can also be sensitive. Protecting it is easy:<br />
$ mv ~/.mozilla ~/Private/mozilla<br />
$ ln -s ~/Private/mozilla ~/.mozilla<br />
<br />
=== Removal ===<br />
<br />
If you want to move a file out of the private directory just move it to it's new destination while ~/Private is mounted. Also note that there are no special steps involved if you want to remove your private directory. Make sure it is un-mounted and delete ~/.Private, along with all the files.<br />
<br />
=== Backup ===<br />
<br />
Setup explained here separates the directory with encrypted data from the mount point, so the encrypted data is available for backup at any time. With an overlay mount (i.e. ''~/Secret'' mounted over ''~/Secret'') the lower, encrypted, data is harder to get to. Today when cronjobs and other automation software do automatic backups the risk of leaking your sensitive data is higher.<br />
<br />
We explained earlier that all cryptographic metadata is stored in the headers of files. You can easily do backups, or incremental backups, of your '''~/.Private''' directory, treating it like any other directory.<br />
<br />
== See Also ==<br />
<br />
{{Deletion|Regardless of what some blog author thinks, this wiki should strive to treat the topic of disk encryption with eCryptfs comprehensively (within reasonable limits of course). If there are multiple good options at any particular step, then multiple options should be listed. Once this wiki page will have achieved that goal, the following should be deleted (or replaced by a plain "See Also" link list.)|section=Major_restructuring/rewrite}}<br />
<br />
This wiki article covers only the basic setup of a private encrypted directory. There is however another article about eCryptfs on Arch Linux, which covers encryption of your entire $HOME and encrypting swap space without breaking hibernation (suspend to disk).<br />
<br />
That article includes many more steps (i.e. using PAM modules and automatic mounting) and the author was opposed to replicating it here, because there is just no single "right" way to do it. The author proposes some solutions and discusses the security implications, but they are his solutions and as such might not be the best nor are they endorsed by the eCryptfs project in any way.<br />
<br />
Article: [http://sysphere.org/~anrxc/j/articles/ecryptfs/index.html eCryptfs and $HOME] by Adrian C. (anrxc).<br />
<br />
Consider that ''Chromium OS'', as released by Google, is using eCryptfs to protect devices that are, and will be, powered by it. Some implementation details are available and they make excellent reading. You can read them [http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data here], they could help a lot as you're coming up with your own strategy.</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=287897Nextcloud2013-12-13T23:58:31Z<p>Xorrr: /* Installation */ add systemctl restart http command</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
{{AUR|owncloud}} is available in the [[AUR]].<br />
Set up the [[LAMP]] stack. <br />
You will probably need to install the MDB2 pear package as well: install {{pkg|php-pear}}<br />
then<br />
# pear install mdb2<br />
# Install {{AUR|owncloud}}. For installing AUR-packages see: [[AUR#Installing_packages|AUR wiki page]].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or {{Pkg|php-sqlite}} for SQLite<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
cron = -1 -1 -1 -1 -1 /usr/bin/curl -H https://localhost/cron.php<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=287896Nextcloud2013-12-13T23:56:00Z<p>Xorrr: /* Installation */ change the config file path to the one used in owncloud 6</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
{{AUR|owncloud}} is available in the [[AUR]].<br />
Set up the [[LAMP]] stack. <br />
You will probably need to install the MDB2 pear package as well: install {{pkg|php-pear}}<br />
then<br />
# pear install mdb2<br />
# Install {{AUR|owncloud}}. For installing AUR-packages see: [[AUR#Installing_packages|AUR wiki page]].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or {{Pkg|php-sqlite}} for SQLite<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache) and open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
cron = -1 -1 -1 -1 -1 /usr/bin/curl -H https://localhost/cron.php<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=287894Nextcloud2013-12-13T23:51:59Z<p>Xorrr: /* Installation */ fix format</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
{{AUR|owncloud}} is available in the [[AUR]].<br />
Set up the [[LAMP]] stack. <br />
You will probably need to install the MDB2 pear package as well: install {{pkg|php-pear}}<br />
then<br />
# pear install mdb2<br />
# Install {{AUR|owncloud}}. For installing AUR-packages see: [[AUR#Installing_packages|AUR wiki page]].<br />
# Copy {{ic|/usr/share/doc/owncloud/examples/apache.conf_example}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (if using owncloud-git)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (php5 should have been configured during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or {{Pkg|php-sqlite}} for SQLite<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache) and open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
cron = -1 -1 -1 -1 -1 /usr/bin/curl -H https://localhost/cron.php<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=287885Nextcloud2013-12-13T20:37:47Z<p>Xorrr: add info for installing the necessary php module for the database</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
{{AUR|owncloud}} is available in the [[AUR]].<br />
# First of all set up the [[LAMP]] stack. You will probably need to install the MDB2 pear package as well:<br />
{{ic|# pacman -S php-pear}}<br />
and<br />
{{ic|# pear install mdb2}}<br />
# Install the {{AUR|owncloud}} package as described in [[AUR#Installing_packages|AUR wiki page]].<br />
# Copy {{ic|/usr/share/doc/owncloud/examples/apache.conf_example}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (if using owncloud-git)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (php5 should have been configured during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or {{Pkg|php-sqlite}} for SQLite<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache) and open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
cron = -1 -1 -1 -1 -1 /usr/bin/curl -H https://localhost/cron.php<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=287883Nextcloud2013-12-13T20:28:05Z<p>Xorrr: add postgresql choice infos and reformat into table</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
{{AUR|owncloud}} is available in the [[AUR]].<br />
# First of all set up the [[LAMP]] stack. You will probably need to install the MDB2 pear package as well:<br />
{{ic|# pacman -S php-pear}}<br />
and<br />
{{ic|# pear install mdb2}}<br />
# Install the {{AUR|owncloud}} package as described in [[AUR#Installing_packages|AUR wiki page]].<br />
# Copy {{ic|/usr/share/doc/owncloud/examples/apache.conf_example}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (if using owncloud-git)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (php5 should have been configured during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache) and open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
cron = -1 -1 -1 -1 -1 /usr/bin/curl -H https://localhost/cron.php<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Surfraw&diff=264396Surfraw2013-06-26T21:48:01Z<p>Xorrr: correct typo</p>
<hr />
<div>[[Category:Internet Applications]]<br />
[[Category:Search]]<br />
[http://surfraw.alioth.debian.org/ surfraw] provides a fast UNIX command line interface to a variety of popular WWW search engines. Surfraw was originally created by Julian Assange.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] {{Pkg|surfraw}} from the [[official repositories]].<br />
<br />
==Configuration==<br />
<br />
Surfraw uses the default browser to open the result. The behaviour can be customized via {{ic|~/.surfraw.conf}}<br />
<br />
SURFRAW_graphical_browser=/usr/bin/chromium<br />
#SURFRAW_text_browser=/usr/bin/elinks<br />
SURFRAW_graphical=yes<br />
<br />
==Usage==<br />
Surfraw consists of a collection of shell scripts, called elvi, each of which searches a specific web site.<br />
<br />
To see the list of elvi type:<br />
surfraw -elvi<br />
<br />
You can call surfraw in full, or the shortened form:<br />
<br />
sr duckduckgo Archlinux <br />
<br />
You can also add surfraw to your $PATH to call the elvi directly.<br />
<br />
There are over 100 elvi available for searching the web, e.g. from amazon:<br />
<br />
surfraw amazon -search=books -country=en -q Stanislaw Lem <br />
<br />
To search the aur:<br />
<br />
sr aur yaourt<br />
<br />
To search this wiki:<br />
<br />
sr archwiki surfraw<br />
<br />
For a full list of web site search scripts see: [http://surfraw.alioth.debian.org/#elvilist List of Elvi]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Slock&diff=264393Slock2013-06-26T21:36:05Z<p>Xorrr: remove empty line after category</p>
<hr />
<div>[[Category:X Server]]<br />
[http://tools.suckless.org/slock Slock] is a simple and lightweight X display locker. Slock only offers a black background when locked. There are no animations.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] {{Pkg|slock}} from the [[official repositories]].<br />
<br />
==Usage==<br />
<br />
To lock the screen just type in:<br />
<br />
slock<br />
<br />
The screen will now turn black. Type in the password of the currently locked in user to unlock (there is no text field, just start typing).</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Slock&diff=264392Slock2013-06-26T21:35:26Z<p>Xorrr: initial text</p>
<hr />
<div>[[Category:X Server]]<br />
<br />
[http://tools.suckless.org/slock Slock] is a simple and lightweight X display locker. Slock only offers a black background when locked. There are no animations.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] {{Pkg|slock}} from the [[official repositories]].<br />
<br />
==Usage==<br />
<br />
To lock the screen just type in:<br />
<br />
slock<br />
<br />
The screen will now turn black. Type in the password of the currently locked in user to unlock (there is no text field, just start typing).</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=263821User:Xorrr2013-06-22T10:27:21Z<p>Xorrr: </p>
<hr />
<div>== Languages ==<br />
* German<br />
* English<br />
<br />
== Used Distributions ==<br />
* Arch - Since mid 2011<br />
<br />
== Tasks ==<br />
* [[Lenovo_ThinkPad_L430]]: Complete<br />
* [[Surfraw]]: Extend</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=263796User:Xorrr2013-06-21T23:43:11Z<p>Xorrr: /* Tasks */</p>
<hr />
<div>Stuttgart, Germany<br />
<br />
== Languages ==<br />
* German<br />
* English<br />
<br />
== Used Distributions ==<br />
* Arch - Since mid 2011<br />
<br />
== Tasks ==<br />
* [[Lenovo_ThinkPad_L430]]: Complete<br />
* [[Surfraw]]: Extend</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Surfraw&diff=263795Surfraw2013-06-21T23:42:06Z<p>Xorrr: "It's Alive!"</p>
<hr />
<div>[http://surfraw.alioth.debian.org/ surfraw] provides a fast unix command line interface to a variety of popular WWW search engines and was created by Julian Assange.<br />
<br />
==Installation==<br />
<br />
To install, simply run<br />
{{bc|# pacman -S surfraw}}<br />
<br />
==Configuration==<br />
<br />
Surfraw uses the default browser to open the result. The behaviour can be customized via '''~/.surfraw.conf'''<br />
<br />
SURFRAW_graphical_browser=/usr/bin/chromium<br />
#SURFRAW_text_browser=/usr/bin/elinks<br />
SURFRAW_graphical=yes<br />
<br />
==Usage==<br />
Basic searching:<br />
<br />
sr duckduckgo Archlinux <br />
<br />
There is a myriad of parameters available for e.g. amazon:<br />
<br />
surfraw amazon -search=books -country=en -q Stanislaw Lem <br />
<br />
Searching the aur:<br />
<br />
sr aur yaourt<br />
<br />
For a full list of web site search scripts see: [http://surfraw.alioth.debian.org/#elvilist List of Eliv]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Git&diff=263325Git2013-06-18T21:08:01Z<p>Xorrr: link from git prompt to the configuration part about coloring. reason: i thought i had to colorize bash to get the git colors because of the stated note.</p>
<hr />
<div>[[Category:Version Control System]]<br />
[[zh-CN:Git]]<br />
{{Article summary start}}<br />
{{Article summary text|Installing and using the Git VCS}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Super Quick Git Guide}}: Generally about contributing to pacman, although it still serves as a practical Git tutorial<br />
{{Article summary wiki|Gitweb}}<br />
{{Article summary wiki|Cgit}}<br />
{{Article summary wiki|Subversion}}<br />
{{Article summary wiki|Concurrent Versions System}}<br />
{{Article summary link|GitHub|https://github.com/}}<br />
{{Article summary end}}<br />
<br />
[http://git-scm.com/ Git] is the version control system (VCS) coded by Linus Torvalds (the creator of the Linux kernel) after being criticized for using the proprietary BitKeeper with the Linux kernel. Git is now used to maintain sources for the Linux kernel as well as thousands of other projects, including [[Pacman]], Arch's package manager.<br />
<br />
There is extensive documentation, including guides and tutorials, available from the [http://git-scm.com/documentation official web site].<br />
<br />
==Installation==<br />
{{Pkg|git}} can be installed with [[pacman]] from the [[Official Repositories|official repositories]]. If you care about using Git with other VCS software, mail servers, or using Git's GUI, pay close attention to the optional dependencies.<br />
<br />
Bash completion (e.g. hitting {{keypress|Tab}} to complete commands you are typing) should work if you add this line to your {{ic|~/.bashrc}} file:<br />
{{bc|source /usr/share/git/completion/git-completion.bash}}<br />
Alternatively, you can install the {{Pkg|bash-completion}} package to load the completions automatically for new shells.<br />
<br />
If you want to use Git's built-in GUI (e.g. {{Ic|gitk}} or {{Ic|git gui}}) you should install the {{Pkg|tk}} package, or you will get a rather cryptic message:<br />
{{bc|/usr/bin/gitk: line 3: exec: wish: not found.}}<br />
<br />
== Configuration ==<br />
Git reads its configuration from a few INI type configuration files. In each git repository {{ic|.git/config}} is used for configuration options specific to that repository. Per-user ("global") configuration in {{ic|$HOME/.gitconfig}} is used as a fall-back from the repository configuration. You can edit the files directly but the preferred method is to use the git-config utility. For example,<br />
$ git config --global core.editor "nano -w"<br />
adds {{Ic|<nowiki>editor = nano -w</nowiki>}} to the {{Ic|<nowiki>[core]</nowiki>}} section of your {{ic|~/.gitconfig}} file.<br />
<br />
The [http://schacon.github.com/git/git-config.html man page for the git-config] utility has a fairly long list of variables which can be set.<br />
<br />
The two settings you should set before using Git are your name and email. These are used to sign commits you make.<br />
$ git config --global user.name "Firstname Lastname"<br />
$ git config --global user.email "your_email@youremail.com"<br />
<br />
===Colors in Git Prompt===<br />
{{ic|color.ui}} is also a very useful option to set - it colorizes all Git output.<br />
$ git config --global color.ui true<br />
<br />
==Basic Usage==<br />
<br />
===Cloning a repository===<br />
<br />
git clone <repo location> <dir><br />
<br />
will clone a Git repository in a new directory inside your current directory. Leaving out {{ic|<dir>}}<br />
will cause it to name the folder after the Git repository. For example,<br />
<br />
git clone git@github.com:torvalds/linux.git<br />
<br />
clones Github's mirror of the Linux kernel into a directory named "linux".<br />
<br />
===Committing files===<br />
<br />
Git's commit process involves two steps:<br />
<br />
# Add new files, add changes for existing files (both with {{ic|git add <files>}}), and/or remove files (with {{ic|git rm}}). These changes are put in a staging area called the index.<br />
# Call {{ic|git commit}} to commit the changes.<br />
<br />
Git commit will open up a text editor to provide a commit message.<br />
You can set this editor to whatever you want by changing the {{ic|core.editor}} option with {{ic|git config}}.<br />
<br />
Alternatively, you can use {{ic|git commit -m <message>}} to supply the commit message without opening the text editor.<br />
<br />
Other useful commit tricks:<br />
<br />
{{ic|git commit -a}} lets you commit changes you have made to files already under Git control<br />
without having to take the step of adding the changes to the index. You still have to add new files with git add.<br />
<br />
{{ic|git add -p}} lets you commit specific parts of files you have changed.<br />
This is useful if you have made a bunch of changes that you think would be best split into several commits.<br />
<br />
===Pushing your changes===<br />
<br />
To push your changes up to a server (such as Github), use<br />
<br />
git push <server name> <branch><br />
<br />
Adding {{ic|-u}} will make this server the default one to push to for this branch.<br />
If you have cloned the repository as described above, the server will default to the location you cloned the<br />
repository from (nicknamed "origin") and the branch will default to the master branch.<br />
In other words, if you have followed this guide's instructions in cloning, {{ic|git push}} will suffice.<br />
You can set up Git to push to multiple servers if you want, but that is a more advanced topic.<br />
Branches will be discussed later in this guide.<br />
<br />
===Pulling from the server===<br />
<br />
If you are working on multiple machines and want to update your local repository to what the server has, you use<br />
<br />
git pull <server name> <branch><br />
<br />
Similarly to push, the server name and branch should have sane defaults, so {{ic|git pull}} should suffice.<br />
Git pull is actually shorthand for doing two things:<br />
<br />
# Calling {{ic|git fetch}}, which updates the local copy of what the server has. Such branches are called "remote" branches because they are mirroring remote servers.<br />
# Calling {{ic|git merge}}, which merges what the remote branch has with what you have. If your commit history is the same as the server's commit history, you will be automatically fast-forwarded to the latest commit on the server. If your history does not match (maybe someone else has pushed commits since you last synced), the two histories will be merged.<br />
<br />
It is not a bad idea to get into the practice of using these two commands instead of {{ic|git pull}}. This way you can<br />
check to make sure that the server contains what you would expect before merging.<br />
<br />
===Examining history===<br />
<br />
The command {{ic|git log}} shows the history of your current branch. Note that each commit is identified by a SHA-1 hash.<br />
The author, commit date, and commit message follow. A more useful command is<br />
<br />
git log --graph --oneline --decorate<br />
<br />
which provides a display similar to TortoiseGit's log window. It shows the following:<br />
<br />
* The first 7 digits of each commit's SHA-1 hash (enough to be unique)<br />
* The {{ic|--graph}} option shows how any branches (if there are others) fork off from the current branch.<br />
* The {{ic|--oneline}} option shows only the first line of each commit message<br />
* The {{ic|--decorate}} option shows all commit labels (branches and tags)<br />
<br />
It may be convenient to alias this command as {{ic|git graph}} by doing the following:<br />
<br />
git config --global alias.graph 'log --graph --oneline --decorate'<br />
<br />
Now typing {{ic|git graph}} will run {{ic|git log --graph --oneline --decorate}}.<br />
{{ic|git graph}} and {{ic|git log}} may be given the {{ic|--all}} flag in order to view all branches instead of just the current one.<br />
Adding {{ic|--stat}} to one of these commands is also useful -<br />
it shows which files each commit changed and how many lines were changed in each file.<br />
<br />
===Dealing With Merges===<br />
<br />
Merges happen when you pull, as a result of a rebase operation, and when you merge one branch into another.<br />
Like other version control tools, when Git cannot automatically merge a commit, it turns to you.<br />
See [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merge-Conflicts this section]<br />
of the Git Book for an explanation on how to resolve merge conflicts.<br />
If you screw up and would like to back out of the merge, you can usually abort the merge using the {{ic|--abort}} flag<br />
with whatever command started the merge (e.g. {{ic|git merge --abort}}, {{ic|git pull --abort}}, {{ic|git rebase --abort}}).<br />
<br />
==Taking Advantage of DVCS==<br />
<br />
The above commands only provide the basics.<br />
The real power and convenience in Git (and other distributed version control systems) come from leveraging its local commits and fast branching.<br />
A typical Git workflow looks like this:<br />
<br />
# Create and check out a branch to add a feature.<br />
# Make as many commits as you would like on that branch while developing that feature.<br />
# Squash, rearrange, and edit your commits until you are satisfied with the commits enough to push them to the central server and make them public.<br />
# Merge your branch back into the main branch.<br />
# Delete your branch, if you desire.<br />
# Push your changes to the central server.<br />
<br />
===Creating a branch===<br />
<br />
git branch <branch name><br />
<br />
can be used to create a branch that will branch off the current commit.<br />
After it has been created, you should switch to it using<br />
<br />
git checkout <branch name><br />
<br />
A simpler method is to do both in one step with<br />
<br />
git checkout -b <branch name><br />
<br />
To see a list of branches, and which branch is currently checked out, use<br />
<br />
git branch<br />
<br />
===A word on commits===<br />
<br />
Many of the following commands take commits as arguments. A commit can be identified by any of the following:<br />
<br />
* Its 40-digit SHA-1 hash (the first 7 digits are usually sufficient to identify it uniquely)<br />
* Any commit label such as a branch or tag name<br />
* The label {{ic|HEAD}} always refers to the currently checked-out commit (usually the head of the branch, unless you used {{ic|git checkout}} to jump back in history to an old commit)<br />
* Any of the above plus {{ic|~}} to refer to previous commits. For example, {{ic|HEAD~}} refers to one commit before {{ic|HEAD}} and {{ic|HEAD~5}} refers to five commits before {{ic|HEAD}}.<br />
<br />
===Commits as checkpoints===<br />
<br />
In Subversion and other older, centralized version control systems, commits are permanent - once you make them,<br />
they are there on the server for everyone to see.<br />
In Git, your commits are local and you can combine, rearrange, and edit them before pushing them to the server.<br />
This gives you more flexibility and lets you use commits as checkpoints. Commit early and commit often.<br />
<br />
===Editing the previous commit===<br />
<br />
git commit --amend<br />
<br />
allows you to modify the previous commit. The contents of the index will be applied to it,<br />
allowing you to add more files or changes you forgot to put in. You can also use it to edit the commit message,<br />
if you would like.<br />
<br />
===Squashing, rearranging, and changing history===<br />
<br />
git rebase -i <commit><br />
<br />
will bring up a list of all commits between {{ic|<commit>}} and the present, including {{ic|HEAD}} but excluding {{ic|<commit>}}.<br />
This command allows you rewrite history. To the left of each commit, a command is specified.<br />
Your options are as follows:<br />
<br />
* The "pick" command (the default) uses that commit in the rewritten history.<br />
* The "reword" command lets you change a commit message without changing the commit's contents.<br />
* The "edit" command will cause Git to pause during the history rewrite at this commit. You can then modify it with {{ic|git commit --amend}} or insert new commits.<br />
* The "squash" command will cause a commit to be folded into the previous one. You will be prompted to enter a message for the combined commit.<br />
* The "fixup" command works like squash, but discards the message of the commit being squashed instead of prompting for a new message.<br />
* Commits can be erased from history by deleting them from the list of commits<br />
* Commits can be re-ordered by re-ordering them in the list. When you are done modifying the list, Git will prompt you to resolve any resulting merge problems (after doing so, continue rebasing with {{ic|git rebase --continue}})<br />
<br />
When you are done modifying the list, Git will perform the desired actions.<br />
If Git stops at a commit (due to merge conflicts caused by re-ordering the commits or due to the "edit" command),<br />
use {{ic|git rebase --continue}} to resume. You can always back out of the rebase operation with {{ic|git rebase --abort}}.<br />
<br />
{{warning|Only use {{ic|git rebase -i}} on local commits that have not yet been pushed to anybody else.<br />
Modifying commits that are on the central server will cause merge problems for obvious reasons.}}<br />
<br />
{{note|Vim makes these rebase operations very simple since lines can be cut and pasted with few keystrokes.}}<br />
<br />
==Git Prompt==<br />
The Git package comes with a prompt script. To enable the prompt addition you will need to source the git-prompt.sh script and add {{Ic|$(__git_ps1 " (%s)")}} to your PS1 variable.<br />
* Add the following line to your {{ic|~/.bashrc}}/{{ic|~/.zshrc}}:<br />
source /usr/share/git/completion/git-prompt.sh<br />
* For Bash:<br />
PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '<br />
{{Note|For information about coloring your Bash prompt, see [[Color_Bash_Prompt]]}}<br />
{{Note|For information about coloring your Git prompt, see [[#Colors in Git Prompt]]}}<br />
<br />
* For zsh:<br />
PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '<br />
<br />
The {{Ic|%s}} is replaced by the current branch name. Git information is displayed only if you are navigating in a Git repository. You can enable extra information by setting and exporting certain variables to a non-empty value as shown in the following table:<br />
<br />
{| border="1"<br />
|+<br />
! Variable !! Information<br />
|-<br />
| GIT_PS1_SHOWDIRTYSTATE || '''*''' for unstaged and '''+''' for staged changes<br />
|-<br />
| GIT_PS1_SHOWSTASHSTATE || '''$''' if something is stashed<br />
|-<br />
| GIT_PS1_SHOWUNTRACKEDFILES || '''%''' if there are untracked files<br />
|}<br />
<br />
In addition you can set the {{Ic|GIT_PS1_SHOWUPSTREAM}} variable to {{Ic|"auto"}} in order to see {{Ic|'''<'''}} if you are behind upstream, {{Ic|'''>'''}} if you are ahead and {{Ic|'''<>'''}} if you have diverged.<br />
<br />
{{Note|If you experience that {{Ic|$(__git_ps1)}} returns {{Ic|((unknown))}}, then there's a {{Ic|.git}} folder in your current directory which doesn't contain any repository, and therefore Git does not recognize it. This can for example happen if you for some reason mistake Git's config-file to be {{Ic|~/.git/config}} instead of {{Ic|~/.gitconfig}}.}}<br />
<br />
==Transfer Protocols==<br />
===Smart HTTP===<br />
Since version 1.6.6 git is able to use the HTTP(S) protocol as efficiently as SSH or Git by utilizing the git-http-backend. Furthermore it is not only possible to clone or pull from repositories, but also to push into repositories over HTTP(S).<br />
<br />
The setup for this is rather simple as all you need to have installed is the Apache web server (with mod_cgi, mod_alias, and mod_env enabled) and of course, git:<br />
# pacman -S apache git<br />
<br />
Once you have your basic setup up and running, add the following to your Apache's config usually located at {{ic|/etc/httpd/conf/httpd.conf}}:<br />
<Directory "/usr/lib/git-core*"><br />
Order allow,deny<br />
Allow from all<br />
</Directory><br />
<br />
SetEnv GIT_PROJECT_ROOT /srv/git<br />
SetEnv GIT_HTTP_EXPORT_ALL<br />
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/<br />
<br />
The above example config assumes that your git repositories are located at {{ic|/srv/git}} and that you want to access them via something like <nowiki>http(s)://your_address.tld/git/your_repo.git</nowiki>. Feel free to customize this to your needs.<br />
<br />
{{Note|Of course you have to make sure that your Apache can read and write (if you want to enable push access) on your git repositories.}}<br />
<br />
For more detailed documentation, visit the following links:<br />
* http://progit.org/2010/03/04/smart-http.html<br />
* https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-http-backend.html<br />
<br />
===Git SSH===<br />
You first need to have a public SSH key. For that follow the guide at [[Using SSH Keys]]. To set up SSH itself, you need to follow the [[SSH]] guide. This assumes you have a public SSH key now and that your SSH is working.<br />
Open your SSH key in your favorite editor (default public key name is {{ic|~/.ssh/id_rsa.pub}}), and copy its content ({{keypress|Ctrl+c}}).<br />
Now go to your user where you have made your Git repository, since we now need to allow that SSH key to log in on that user to access the Git repository.<br />
Open {{ic|~/.ssh/authorized_keys}} in your favorite editor, and paste the contents of id_rsa.pub in it. Be sure it is all on one line! That is important! It should look somewhat like this:<br />
{{Warning|Do not copy the line below! It is an example! It will not work if you use that line!}}<br />
<pre style='overflow:auto'><br />
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCboOH6AotCh4OcwJgsB4AtXzDo9Gzhl+BAHuEvnDRHNSYIURqGN4CrP+b5Bx/iLrRFOBv58TcZz1jyJ2PaGwT74kvVOe9JCCdgw4nSMBV44cy+6cTJiv6f1tw8pHRS2H6nHC9SCSAWkMX4rpiSQ0wkhjug+GtBWOXDaotIzrFwLw== username@hostname<br />
</pre><br />
Now you can checkout your Git repository this way (change where needed. Here it is using the git username and localhost):<br />
git clone git@localhost:my_repository.git<br />
You should now get an SSH yes/no question. Type {{ic|yes}} followed by {{keypress|Enter}}. Then you should have your repository checked out. Because this is with SSH, you also do have commit rights now. For that look at [[Git]] and [[Super Quick Git Guide]].<br />
<br />
====Specifying a non-standard port====<br />
Connecting on a port other than 22 can be configured on a per-host basis in {{ic|/etc/ssh/ssh_config}} or {{ic|~/.ssh/config}}. To set up ports for a repository, specify the path in {{ic|.git/config}} using the port number {{ic|N}} and the ''absolute path'' {{ic|/PATH/TO/REPO}}:<br />
ssh://user@example.org:N/PATH/TO/REPO<br />
Typically the repository resides in the home directory of the user which allows you to use tilde-expansion. Thus to connect on port N=443,<br />
url = git@example.org:repo.git<br />
becomes:<br />
url = ssh://git@example.org:443/~git/repo.git<br />
<br />
===Git daemon===<br />
{{Note|The git daemon only allows read access. For write access see [[#Git SSH]].}}<br />
This will allow URLs like "git clone git://localhost/my_repository.git".<br />
<br />
Start git-daemon with root privileges. <br />
# systemctl start git-daemon.socket<br />
<br />
To run the git-daemon every time at boot, enable the service:<br />
# systemctl enable git-daemon.socket<br />
<br />
The daemon is started with the following parameters which are placed in the systemd service file.<br />
ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git<br />
<br />
So you have to place your repositories in /srv/git/ to be able to clone them with git daemon.<br />
<br />
Clients can now simply use:<br />
git clone git://localhost/my_repository.git<br />
<br />
=== Git repositories rights ===<br />
To restrict read/write access, you can simply use Unix rights, see http://sitaramc.github.com/gitolite/doc/overkill.html<br />
<br />
For a fine-grained rights access, see [[gitolite]] and [[gitosis]]<br />
<br />
==See also==<br />
* [http://git-scm.com/book Pro Git book]<br />
* [http://gitref.org/ Git Reference]<br />
* https://www.kernel.org/pub/software/scm/git/docs/<br />
* https://help.github.com/</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=260248User:Xorrr2013-06-01T18:35:24Z<p>Xorrr: </p>
<hr />
<div>Stuttgart, Germany<br />
<br />
== Languages ==<br />
* German<br />
* English<br />
<br />
== Used Distributions ==<br />
* Arch - Since mid 2011<br />
<br />
== Tasks ==<br />
* [[Lenovo_ThinkPad_L430]]: Complete</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=260240User:Xorrr2013-06-01T17:08:26Z<p>Xorrr: </p>
<hr />
<div>(:<br />
<br />
https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_L430</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_L530&diff=260236Lenovo ThinkPad L5302013-06-01T17:05:45Z<p>Xorrr: add workaround internal link</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers the Arch Linux support for the Lenovo ThinkPad L530 laptop.}}<br />
{{Article summary end}}<br />
<br />
==Hardware==<br />
Using '''Kernel 3.8.5'''<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|-<br />
! Device || Works<br />
|-<br />
| Video || Yes<br />
|-<br />
| Ethernet || Yes<br />
|-<br />
| Wireless || Yes<br />
|-<br />
| Bluetooth || Yes<br />
|-<br />
| Audio || Yes<br />
|-<br />
| Camera || Yes<br />
|-<br />
| Card Reader || Yes<br />
|-<br />
| Fingerprint Reader || Not Tested<br />
|-<br />
| Touchpad || Yes<br />
|-<br />
| Trackpoint || No<br />
|}<br />
<br />
===lspci===<br />
{{bc|<br />
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)<br />
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)<br />
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)<br />
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)<br />
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)<br />
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)<br />
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)<br />
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)<br />
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)<br />
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)<br />
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)<br />
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)<br />
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)<br />
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)<br />
01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)<br />
06:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)<br />
0c:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 07)<br />
}}<br />
<br />
===lsusb===<br />
{{bc|<br />
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub<br />
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub<br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
Bus 003 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]<br />
Bus 003 Device 004: ID 04f2:b2eb Chicony Electronics Co., Ltd <br />
}}<br />
<br />
==Configuration==<br />
===Clickpad===<br />
The clickpad works with the xf86-input-synaptic driver from extra, but the left/right click buttons at the bottom of the clickpad do not work.<br />
<br />
Install [https://aur.archlinux.org/packages.php?ID=38120 xf86-input-synaptics-clickpad] from the [[AUR]].<br />
<br />
===Video===<br />
In order to use the builtin intel graphics adapter you will have to install the corresponding drivers: <br />
# pacman -S xf86-video-intel<br />
<br />
===Ethernet===<br />
Works out of the box.<br />
<br />
===Wireless===<br />
Works out of the box.<br />
<br />
====Driver==== <br />
rtl8192ce driver<br />
LSPCI : Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)<br />
<br />
===Wireless===<br />
Install : bluez and blueman<br />
<br />
===Sound===<br />
Works out of the box.<br />
<br />
===Webcam===<br />
Works out of the box. <br />
<br />
=== Fingerprint Reader===<br />
Try : fingerprint-gui<br />
<br />
===Card Reader===<br />
Works out of the box. <br />
Tips :<br />
Card appears in : /dev/mmc* <br />
<br />
=== Trackpoint ===<br />
See [[#Troubleshooting]]<br />
<br />
=== Special key ===<br />
All special keys works except the microphone mute key : see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/751471).<br />
<br />
==Troubleshooting==<br />
===Trackpoint===<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|This is just a quick and dirty workaround. The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
# sudo modprobe -rv psmouse && sudo modprobe -v psmouse <br />
<br />
{{Note|For more infos see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== Link ==<br />
[http://zenforyen.wordpress.com/2012/07/16/experiences-with-thinkpad-l530-on-arch-linux/| Experiences with thinkpad l530 on arch linux ]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_L530&diff=260235Lenovo ThinkPad L5302013-06-01T17:03:39Z<p>Xorrr: /* Troubleshooting */</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers the Arch Linux support for the Lenovo ThinkPad L530 laptop.}}<br />
{{Article summary end}}<br />
<br />
==Hardware==<br />
Using '''Kernel 3.8.5'''<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|-<br />
! Device || Works<br />
|-<br />
| Video || Yes<br />
|-<br />
| Ethernet || Yes<br />
|-<br />
| Wireless || Yes<br />
|-<br />
| Bluetooth || Yes<br />
|-<br />
| Audio || Yes<br />
|-<br />
| Camera || Yes<br />
|-<br />
| Card Reader || Yes<br />
|-<br />
| Fingerprint Reader || Not Tested<br />
|-<br />
| Touchpad || Yes<br />
|-<br />
| Trackpoint || No<br />
|}<br />
<br />
===lspci===<br />
{{bc|<br />
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)<br />
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)<br />
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)<br />
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)<br />
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)<br />
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)<br />
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)<br />
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)<br />
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)<br />
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)<br />
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)<br />
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)<br />
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)<br />
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)<br />
01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)<br />
06:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)<br />
0c:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 07)<br />
}}<br />
<br />
===lsusb===<br />
{{bc|<br />
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub<br />
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub<br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
Bus 003 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]<br />
Bus 003 Device 004: ID 04f2:b2eb Chicony Electronics Co., Ltd <br />
}}<br />
<br />
==Configuration==<br />
===Clickpad===<br />
The clickpad works with the xf86-input-synaptic driver from extra, but the left/right click buttons at the bottom of the clickpad do not work.<br />
<br />
Install [https://aur.archlinux.org/packages.php?ID=38120 xf86-input-synaptics-clickpad] from the [[AUR]].<br />
<br />
===Video===<br />
In order to use the builtin intel graphics adapter you will have to install the corresponding drivers: <br />
# pacman -S xf86-video-intel<br />
<br />
===Ethernet===<br />
Works out of the box.<br />
<br />
===Wireless===<br />
Works out of the box.<br />
<br />
====Driver==== <br />
rtl8192ce driver<br />
LSPCI : Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)<br />
<br />
===Wireless===<br />
Install : bluez and blueman<br />
<br />
===Sound===<br />
Works out of the box.<br />
<br />
===Webcam===<br />
Works out of the box. <br />
<br />
=== Fingerprint Reader===<br />
Try : fingerprint-gui<br />
<br />
===Card Reader===<br />
Works out of the box. <br />
Tips :<br />
Card appears in : /dev/mmc* <br />
<br />
=== Trackpoint ===<br />
Don't work :-(<br />
<br />
https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
=== Special key ===<br />
All special keys works except the microphone mute key : see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/751471).<br />
<br />
==Troubleshooting==<br />
===Trackpoint===<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|This is just a quick and dirty workaround. The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
# sudo modprobe -rv psmouse && sudo modprobe -v psmouse <br />
<br />
{{Note|For more infos see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== Link ==<br />
[http://zenforyen.wordpress.com/2012/07/16/experiences-with-thinkpad-l530-on-arch-linux/| Experiences with thinkpad l530 on arch linux ]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=L430&diff=260234L4302013-06-01T17:02:20Z<p>Xorrr: Redirected page to Lenovo ThinkPad L430</p>
<hr />
<div>#REDIRECT [[Lenovo ThinkPad L430]]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_L430&diff=260233Lenovo ThinkPad L4302013-06-01T17:01:16Z<p>Xorrr: create page and add how to deal with the trackpoint issue</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers the Arch Linux support for the Lenovo ThinkPad L430 laptop.}}<br />
{{Article summary end}}<br />
<br />
==Troubleshooting==<br />
===Trackpoint===<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|This is just a quick and dirty workaround. The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
# sudo modprobe -rv psmouse && sudo modprobe -v psmouse <br />
<br />
{{Note|For more infos see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Lenovo_Thinkpad_L530&diff=260232Lenovo Thinkpad L5302013-06-01T16:47:58Z<p>Xorrr: Redirected page to Lenovo ThinkPad L530</p>
<hr />
<div>#REDIRECT [[Lenovo ThinkPad L530]]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=L530&diff=260231L5302013-06-01T16:46:55Z<p>Xorrr: Redirected page to Lenovo ThinkPad L530</p>
<hr />
<div>#REDIRECT [[Lenovo ThinkPad L530]]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=NTFS-3G&diff=250914NTFS-3G2013-03-16T12:08:06Z<p>Xorrr: show parameter to quick format</p>
<hr />
<div>[[Category:File systems]]<br />
[[es:NTFS-3G]]<br />
[[he:NTFS-3G]]<br />
[[it:NTFS-3G]]<br />
[[ru:NTFS-3G]]<br />
[[zh-CN:NTFS-3G]]<br />
[[zh-TW:NTFS-3G]]<br />
[http://www.tuxera.com/community/ntfs-3g-download/ NTFS-3G] is an open source implementation of Microsoft's NTFS file system that includes read and write support. Because it is considered to be easier to configure and developed write support earlier, users generally prefer NTFS-3G over {{Pkg|ntfsprogs}} ntfsmount. NTFS-3G developers use the FUSE file system to facilitate development and to help with portability. This document will describe how to setup NTFS-3G to work on your computer.<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|ntfs-3g}} package from the [[Official Repositories|official repositories]].<br />
<br />
== Manual mounting ==<br />
<br />
Two options exist for manually mounting NTFS partitions. The traditional:<br />
# mount -t ntfs-3g /dev/<your-NTFS-partition> /{mnt,...}/<folder><br />
<br />
Mount type {{ic|ntfs-3g}} does not need to be explicitly specified in Arch. The {{ic|mount}} command by default will use {{ic|/sbin/mount.ntfs}} which is symlinked to {{ic|/bin/ntfs-3g}} after the {{Pkg|ntfs-3g}} package is installed.<br />
<br />
The second option is to call {{ic|ntfs-3g}} directly:<br />
# ntfs-3g /dev/<your-NTFS-partition> /<mount-location><br />
<br />
== Configuring == <br />
<br />
Your NTFS partition(s) can be setup to mount automatically, or pre-configured to be able to mount in a certain way when you would like them to be mounted. This configuration can be done in the static filesystem configuration ([[fstab]]) or by the use of udev rules.<br />
<br />
=== Default settings ===<br />
<br />
Using the default settings will mount the NTFS partition(s) at boot. With this method, '''if''' the parent folder that it is mounted upon has the proper user or group [[Users and Groups|permissions]], then that user or group will be able to read and write on that partition(s).<br />
<br />
Put this in {{ic|/etc/fstab}}:<br />
# <file system> <dir> <type> <options> <dump> <pass><br />
/dev/<NTFS-part> /mnt/windows ntfs-3g defaults 0 0<br />
<br />
=== Linux compatible permissions ===<br />
Permissions on a Linux system are normally set to 755 for folders and 644 for files. It is recommended to keep these permissions in use for the NTFS partition as well if you use the partition on a regular basis. The following example assigns the above permissions to a normal user:<br />
<br />
# Mount internal windows partition with linux compatible permissions, i.e. 755 for directories (dmask=022) and 644 for files (fmask=133)<br />
UUID=01CD2ABB65E17DE0 /run/media/user1/Windows ntfs-3g uid=user1,gid=users,dmask=022,fmask=133 0 0<br />
<br />
=== Allowing Group/User ===<br />
<br />
You can also tell {{ic|/etc/fstab}} (the NTFS-3G driver) other options like those who are allowed to access (read) the partition. For example, for you to allow people in the {{ic|users}} group to have access:<br />
<br />
/dev/<NTFS-part> /mnt/windows ntfs-3g gid=users,umask=0022 0 0<br />
<br />
By default, the above line will enable write support for root only. To enable user writing, you have to specify the user who should be granted write permissions. Use the {{ic|uid}} parameter together with your username to enable user writing:<br />
<br />
/dev/<NTFS-part> /mnt/windows ntfs-3g uid=username,gid=users,umask=0022 0 0<br />
<br />
If you are running on a single user machine, you may like to own the file system yourself and grant all possible permissions:<br />
/dev/<NTFS-part> /mnt/windows ntfs-3g uid=USERNAME,gid=users 0 0<br />
<br />
=== Basic NTFS-3G options ===<br />
<br />
For most, the above settings should suffice. Here are a few other options that are general common options for various Linux filesystems. For a complete list, see [http://www.tuxera.com/community/ntfs-3g-manual/#6 this]<br />
<br />
;[[Umask|umask]]: umask is a built-in shell command which automatically sets file permissions on newly created files. For Arch Linux, the default umask for root and user is 0022. With 0022 new folders have the directory permissions of 755 and new files have permissions of 644. You can read more about umask permissions [http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html here].<br />
;noauto: If {{ic|noauto}} is set, NTFS entries in {{ic|/etc/fstab}} do not get mounted automatically at boot.<br />
;uid: The user id number. This allows a specific user to have full access to the partition. Your uid can be found with the {{ic|id}} command.<br />
;fmask and dmask: Like {{ic|umask}} but defining file and directory respectively individually.<br />
;locale: (deprecated as of 2009.1.1) - <s>some locales will need to specify their region for local characters to display properly.</s><br />
<br />
=== Allowing user to mount ===<br />
<br />
By default, ntfs-3g requires root rights to mount the filesystem, even with the "user" option in /etc/fstab, the reason why can be found [http://www.tuxera.com/community/ntfs-3g-faq/#unprivileged here]. The user option in the fstab is still required. To be able to mount as user, a few tweaks need to be made:<br />
<br />
First, check that you have access to the mount block you want to use, the easiest way to do that is to be in the disk groups with the following command:<br />
<br />
# gpasswd -a username disk<br />
<br />
{{Note| groups rights sometimes requires rebooting to kick in}}<br />
<br />
You also need acces right to the mount point you want to use, since we're going to mount something as user on this mountpoint, we might as well own it:<br />
# chown <user> /mnt/<mountpoint><br />
<br />
Second is having a ntfs-3g driver compiled with integrated FUSE support, the ntfs-3g package from extra doesn't, but there is one [https://aur.archlinux.org/packages/ntfs-3g-fuse/ on AUR].<br />
<br />
Third, we need to setuid root the driver. It is done by issuing these two commands as root:<br />
# chown root $(which ntfs-3g)<br />
# chmod 4755 $(which ntfs-3g) <br />
<br />
You should now be able to mount your NTFS partition without root rights.<br />
<br />
{{Note| There seems to be an issue with unmounting rights, so you will still need root rights if you need to unmount the filesystem}}<br />
<br />
<br />
=== NTFS-config ===<br />
<br />
{{AUR|ntfs-config}} is a program that may be able to help configure your NTFS partition(s) if other methods do not work.<br />
<br />
== Troubleshooting ==<br />
<br />
Some ideas for troubleshooting common problems.<br />
<br />
=== Damaged NTFS Filesystems ===<br />
<br />
If an NTFS filesystem has errors on it, NTFS-3G will mount it as read-only. To fix an NTFS filesystem, load Windows and run its disk checking program, chkdsk.<br />
Take in account that ntfsfix can only repair some errors. If it fails, chkdsk will probably succeed.<br />
<br />
To repair the file system without booting windows, [[pacman|install]] the {{Pkg|ntfsprogs}} package available in the [[Official Repositories|official repositories]].<br />
<br />
To fix the NTFS file system, the device must already be unmounted. For example, to fix an NTFS partition residing in {{ic|/dev/sda2}}:<br />
<br />
# umount /dev/sda2<br />
# ntfsfix /dev/sda2<br />
Mounting volume... OK<br />
Processing of $MFT and $MFTMirr completed successfully.<br />
NTFS volume version is 3.1.<br />
NTFS partition /dev/sda2 was processed successfully.<br />
# mount /dev/sda2<br />
<br />
If all went well, the volume will now be writable.<br />
<br />
=== "Metadata kept in Windows cache, refused to mount" ===<br />
<br />
When dual booting with Windows 8, trying to mount a partition that is visible to Windows may yield the following error:<br />
<br />
The disk contains an unclean file system (0, 0).<br />
Metadata kept in Windows cache, refused to mount.<br />
Failed to mount '/dev/sdc1': Operation not permitted<br />
The NTFS partition is in an unsafe state. Please resume and shutdown<br />
Windows fully (no hibernation or fast restarting), or mount the volume<br />
read-only with the 'ro' mount option.<br />
<br />
The problem is due to the new Windows 8 feature called "fast startup". When fast startup is enabled, part of the metadata of all mounted partitions are restored to the state they were at the previous closing down. As a consequence, changes made on Linux may be lost. This can happen on any partition of an internal disk when leaving Windows 8 by selecting "Shut down" or "Hibernate". Leaving Windows 8 by selecting "Restart", however, is apparently safe.<br />
<br />
To enable writing to the partitions on other operating systems, be sure the fast restarting of Windows 8 is disabled. This can be achieved by issuing as an administrator the command:<br />
<br />
powercfg /h off<br />
<br />
You can check the current settings on Control Panel > Hardware and Sound > Power Options > System Setting > Choose what the power buttons do. The box "Turn on fast startup" should either be disabled or missing.<br />
<br />
=== Mount Failure ===<br />
<br />
If you cannot mount your NTFS partition even when following this guide, try using the [[UUID]] instead of device name in {{ic|/etc/fstab}} for all NTFS partitions. Here's an fstab [[Fstab#UUID|example]].<br />
<br />
=== Format NTFS ===<br />
<br />
Install {{pkg|ntfsprogs}}.<br />
<br />
{{Warning|As always, double check the device path.}}<br />
<br />
# mkfs.ntfs -L myCoolDiskName /dev/sdc1<br />
<br />
If you dont want this to take ages on modern harddrives use:<br />
<br />
# mkfs.ntfs -Q -L myCoolDiskName /dev/sdc1<br />
<br />
{{Note| manpage on -Q: Perform quick (fast) format. This will skip both zeroing of the volume and bad sector checking.}}<br />
<br />
== Resources ==<br />
<br />
* [http://www.tuxera.com/community/ntfs-3g-manual/ Official NTFS-3G Manual]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Samba&diff=237542Samba2012-12-01T14:03:03Z<p>Xorrr: </p>
<hr />
<div>[[Category:Networking]]<br />
[[cs:Samba]]<br />
[[de:Samba]]<br />
[[da:Samba]]<br />
[[es:Samba]]<br />
[[fr:Samba]]<br />
[[it:Samba]]<br />
[[ru:Samba]]<br />
[[sr:Samba]]<br />
[[tr:Samba]]<br />
[[zh-CN:Samba]]<br />
[[zh-TW:Samba]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Installing, configuring and troubleshooting Samba}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|NFS}}<br />
{{Article summary wiki|Samba Domain Controller}}<br />
{{Article summary end}}<br />
<br />
'''Samba''' is a re-implementation of the SMB/CIFS networking protocol, it facilitates file and printer sharing among Linux and Windows systems as an alternative to [[NFS]]. Some users say that Samba is easily configured and that operation is very straight-forward. However, many new users run into problems with its complexity and non-intuitive mechanism. It is strongly suggested that the user stick close to the following directions.<br />
<br />
==Installation==<br />
<br />
Installing only the {{Pkg|smbclient}}, available in the [[Official Repositories]], is sufficient for systems that are not meant to share files, only access them.<br />
<br />
In order to make shares available to clients, install {{Pkg|samba}}, available in the [[Official Repositories]].<br />
<br />
==Configuration==<br />
=== Basic Setup ===<br />
The {{ic|/etc/samba/smb.conf}} file must be created before starting the daemons. Once that is set up, users may opt for using an advanced configuration interface like SWAT.<br />
<br />
As root, copy the default Samba configuration file to {{ic|/etc/samba/smb.conf}}:<br />
{{bc|# cp /etc/samba/smb.conf.default /etc/samba/smb.conf}}<br />
<br />
Edit {{ic|smb.conf}}. The default file creates a share for each user's home directory. It also creates a share for printers.<br />
<br />
More information about the options available can be found in {{ic|man smb.conf}}. [http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html Here] is the online version.<br />
<br />
To make samba work, start samba [[daemon]] or make it automatically start at boot.<br />
<br />
Classic init<br />
# rc.d start samba<br />
<br />
Systemd<br />
# systemctl start smbd.service nmbd.service<br />
<br />
{{Note|After starting the samba daemon check that files smbd.pid and nmbd.pid exist in /var/run/samba/ otherwise you will get an error. If not, simply create /var/run/samba directory and restart samba daemon.}}<br />
<br />
=== Shell Based Options ===<br />
====Adding users====<br />
To log into a Samba share, a samba user is needed.<br />
<br />
For Samba versions 3.4.0 and above:<br />
{{ic|# pdbedit -a -u <user>}}<br />
<br />
For earlier versions of Samba:<br />
{{ic|# smbpasswd -a <user>}}<br />
<br />
Existing smbpasswd databases can also be [[Samba#Changes_in_Samba_version_3.4.0|converted to the new format]].<br />
<br />
The user must already have an account on the server, if this is not the case, the following error will be displayed:<br />
{{ic|Failed to modify password entry for user "<user>"}}<br />
<br />
Add a new user to the Linux host with [[User Management#adduser|adduser]]. This article does not cover adding users to Windows systems.<br />
<br />
{{Note|smbpasswd is no longer used by default as of [[Samba#Changes_in_Samba_version_3.4.0|Samba version 3.4.0]] }}<br />
<br />
===Web Based Option ===<br />
====SWAT: Samba web administration tool====<br />
[http://samba.xsec.it/samba/docs/man/Samba-HOWTO-Collection/SWAT.html SWAT] is a facility that is part of the Samba suite. The main executable is called swat and is invoked by the eXtended InterNET Daemon, [[Wikipedia:xinetd|xinetd]]. <br />
<br />
There are many and varied opinions regarding the usefulness of SWAT. No matter how hard one tries to produce the perfect configuration tool, it remains an object of personal taste. SWAT is a tool that allows Web-based configuration of Samba. It has a wizard that may help to get Samba configured quickly, it has context-sensitive help on each {{ic|smb.conf}} parameter, it provides for monitoring of current state of connection information, and it allows network-wide MS Windows network password management.[http://samba.xsec.it/samba/docs/man/Samba-HOWTO-Collection/SWAT.html]<br />
<br />
{{Note|An all-encompasing [[Webmin]] tool instead can also be used, and easily load the SWAT module there.}}<br />
<br />
{{Warning|Before using SWAT, be warned that SWAT will completely replace {{ic|smb.conf}} with a fully optimized file that has been stripped of all comments , and only non-default settings will be written to the file.}}<br />
<br />
To use SWAT, first install {{Pkg|xinetd}}, available in the [[Official Repositories]].<br />
<br />
Edit {{ic|/etc/xinetd.d/swat}}. To enable SWAT, change the {{ic|1=disable = yes}} line to {{ic|1=disable = no}}.<br />
<br />
{{bc|<nowiki><br />
service swat<br />
{<br />
type = UNLISTED<br />
protocol = tcp<br />
port = 901<br />
socket_type = stream<br />
wait = no<br />
user = root<br />
server = /usr/sbin/swat<br />
log_on_success += HOST DURATION<br />
log_on_failure += HOST<br />
disable = no<br />
}<br />
</nowiki><br />
}}<br />
<br />
Alternatively, add an entry for swat to {{ic|/etc/services}} and omit the first 3 lines of the configuration.<br />
<br />
Then start xinetd [[daemon]].<br />
<br />
The web interface can be accessed on port 901 by default:<br />
{{ic|http://localhost:901/}}<br />
<br />
==Accessing shares==<br />
Shared resources from other computers on the LAN may be accessed and mounted locally by GUI or CLI methods The graphical manner is limited. Some Desktop Environments have a way to facilitate accessing these shared resources. However, most do not. In fact, most lightweight DE's and WM's offer no native method.<br />
<br />
There are two parts to share access. First is the underlying file system mechanism, and second is the interface which allows the user to select to mount shared resources. Some environments have the first part built into them.<br />
<br />
If using KDE, it has the ability to browse Samba shares. Therefore do not need any additional packages. (However, for a GUI in the KDE System Settings, install the kdenetwork-filesharing package from [extra]. Another program choice is SMB4K.) If, however, users wish to use the share in Gnome or solely from a shell, an additional package is needed.<br />
<br />
===Accessing a Samba share from GNOME/Xfce4/LXDE===<br />
In order to access samba shares through Nautilus, first install the {{Pkg|gvfs-smb}} and {{Pkg|gnome-vfs}} packages, available in the [[Official Repositories]]. <br />
<br />
For access under Xfce4 using Thunar or LXDE using pcmanfm, one only needs {{pkg|gvfs-smb}}, available in the [[Official Repositories]].<br />
<br />
From a Nautilus/Thunar window, hit {{Keypress|Ctrl+L}} or go to the "Go" menu and select "Location..." -- both actions will allow for the typing in the "Go to:" blank. Enter:<br />
{{ic|smb://servername/share}}<br />
<br />
{{Note|If the servername is not in {{ic|/etc/hosts}}, use the IP address of the server in place of the servername.}}<br />
<br />
From a Pcmanfm window, under the "Go" menu choose "Network Files".<br />
<br />
Another GNOME browser program is Gnomba.<br />
<br />
If iptables is running, the '''nf_conntrack_netbios_ns''' module should be loaded:<br />
modprobe nf_conntrack_netbios_ns<br />
<br />
===Accessing shares from other graphical environments===<br />
There are a number of useful programs, but they will need to have packages created for them. This can be done with the Arch package build system. The good thing about these others is that they do not require a particular environment to be installed to support them, and so they bring along less baggage.<br />
<br />
LinNeighborhood is non-specific when it comes to the DE or WM. It can be seen as a simple and generic X-based LAN browser and share mounter. Not pretty, but effective.<br />
<br />
Other possible programs include pyneighborhood and RUmba, as well as the xffm-samba plugin for Xffm.<br />
<br />
===Accessing a Samba share from the shell===<br />
Shares may be accessed by using an automatic mounter or by using a [[#Manual share mounting|manual method]].<br />
<br />
====Automatic share mounting====<br />
There are several alternatives for easy share browsing.<br />
<br />
=====smbnetfs=====<br />
Install {{Pkg|smbnetfs}}, available in the [[Official Repositories]].<br />
Add the following line to {{ic|/etc/fuse.conf}}: {{bc|user_allow_other}}<br />
Load the {{ic|fuse}} [[kernel module]] by issuing as root:<br />
modprobe fuse<br />
Start the {{ic|smbnetfs}} [[daemon]] by issuing as root:<br />
rc.d start smbnetfs<br />
Or if using systemctl:<br />
systemctl start smbnetfs<br />
<br />
If the required configuration is properly researched and done, it is claimed that all shares in the network are now automatically mounted under {{ic|/mnt/smbnet}}.<br />
<br />
Add the following to {{ic|/etc/rc.conf}} to access the shares at boot:<br />
MODULES=(... '''fuse''' ...)<br />
DAEMONS=(... '''smbnetfs''' ...)<br />
<br />
If a username and a password are required to access some of the shared folders, edit {{ic|/etc/smbnetfs/.smb/smbnetfs.conf}} and uncomment the line starting with "auth":<br />
<br />
auth "hostname" "username" "password"<br />
<br />
Then, it may be necessary to change the permissions of {{ic|/etc/smbnetfs/.smb/smbnetfs.conf}} and all include files for smbnetfs to work correctly:<br />
<br />
# chmod 600 /etc/smbnetfs/.smb/smbnetfs.conf<br />
<br />
=====fusesmb=====<br />
{{Note|1=Because {{ic|smbclient 3.2.X}} is malfunctioning with {{ic|fusesmb}}, revert to using older versions if necessary. See the [http://bbs.archlinux.org/viewtopic.php?id=58434 relevant forum topic] for details.}}<br />
<br />
# Install {{AUR|fusesmb}}, available in the [[Arch User Repository]].<br />
# Create a mount point: {{ic|# mkdir /mnt/fusesmb}}<br />
# Load {{ic|fuse}} [[kernel module]].<br />
# Mount the shares: {{bc|# fusesmb -o allow_other /mnt/fusesmb}}<br />
<br />
=====Autofs=====<br />
See [[Autofs]] for information on the kernel-based automounter for Linux.<br />
<br />
====Manual share mounting====<br />
1. Use [[smbclient]] to browse shares from the shell. To list any public shares on a server:<br />
$ smbclient -L <hostname> -U%<br />
<br />
2. Create the mount point for the share:<br />
# mkdir /mnt/MOUNTPOINT<br />
<br />
3. Mount the share using {{ic|mount.cifs}}. Keep in mind that not all options may be needed nor desirable, such as {{ic|password}}:<br />
# mount -t cifs //''SERVER''/''SHARENAME'' ''/mnt''/''MOUNTPOINT'' -o user=''USERNAME'',password=''PASSWORD'',workgroup=''WORKGROUP'',ip=''SERVERIP''<br />
<br />
;{{ic|SERVER}}: The Windows system's name<br />
;{{ic|SHARENAME}}: The shared directory<br />
;{{ic|MOUNTPOINT}}: The local directory where the share will be mounted to<br />
;{{ic|-o [options]}}: Specifies options for {{ic|mount.cifs}}<br />
:;{{ic|user}}: Username used to mount the share<br />
:;{{ic|password}}: The shared directory's password<br />
:;{{ic|workgroup}}: Used to specify the workgroup<br />
:;{{ic|ip}}: The IP address of the server -- if the system is unable to find the Windows computer by name (DNS, WINS, hosts entry, etc.)<br />
<br />
{{Note|Abstain from using trailing directory ('''/''') characters. Using {{ic|//SERVER/SHARENAME'''/'''}} will not work.}}<br />
As CIFS refuses to mount [http://jmatrix.net/dao/case/case.jsp?case=7F000001-1766806-11E30195CFB-2593 unsecured samba share], the ''sec=none'' option needs to be used (and the user and password from the options list need to be removed).<br />
<br />
If the mount command cannot resolve the server’s address but ''smbclient'' can, adding {{ic|wins}} to the {{ic|hosts}} line in {{ic|/etc/nsswitch.conf}} may help. The corresponding {{ic|/lib/libnss_wins.so}} driver must also be present, which is provided by the {{pkg|samba}} (server) package.<br />
<br />
4. To unmount the share, use:<br />
# umount /mnt/MOUNTPOINT<br />
<br />
=====Adding the share to {{ic|fstab}}=====<br />
Add the following to {{ic|/etc/[[fstab]]}} for easy mounting:<br />
//SERVER/SHARENAME /mnt/MOUNTPOINT cifs noauto,noatime,username=USER,password=PASSWORD,workgroup=WORKGROUP,ip=SERVERIP 0 0<br />
<br />
The {{ic|noauto}} option disables mounting it automatically at boot and {{ic|noatime}} increases performance by skipping inode access times. However, the {{ic|noatime}} is known to cause mount [https://bbs.archlinux.org/viewtopic.php?pid=1117000 problems] with kernel 3.4.x:<br />
<br />
# mount error(22): Invalid argument<br />
# Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)<br />
<br />
After adding the previous line, the syntax to mount files becomes simpler:<br />
# mount /mnt/MOUNTPOINT<br />
<br />
Another option, to keep passwords out of sight, is to use the 'credentials' option:<br />
//SERVER/SHARENAME /path/to/SHAREMOUNT cifs noauto,noatime,credentials=/path/to/smbcredentials 0 0<br />
<br />
The credentials file should contain the following text:<br />
username=USERNAME<br />
password=PASSWORD<br />
<br />
It is highly recommended to <tt>chmod 600</tt> this file so that only the owning user can read and write to it.<br />
<br />
If adding a Samba share to {{ic|fstab}}, the {{ic|netfs}} daemon should also be added to {{ic|[[rc.conf]]}}, somewhere after the [[network]] daemon. The {{ic|netfs}} daemon will mount network partitions at boot and, more importantly, unmount network partitions at shutdown. Even if using the {{ic|noauto}} option in {{ic|fstab}}, the {{ic|netfs}} daemon should be used. Without it any network share that is mounted when shutting down will cause the {{ic|network}} daemon to wait for the connection to time out, considerably extending poweroff time.<br />
<br />
=====Allowing users to mount=====<br />
Before enabling access to the mount commands, {{ic|fstab}} needs to be modified. Add the {{ic|users}} options to the entry in {{ic|/etc/fstab}}:<br />
//SERVER/SHARENAME /path/to/SHAREMOUNT cifs '''users''',noauto,noatime,username=USER,password=PASSWORD,workgroup=WORKGROUP,ip=SERVERIP 0 0<br />
<br />
{{Note|The option is {{ic|user'''s'''}} (plural). For other filesystem types handled by mount, this option is usually ''user''; sans the "'''s'''".}}<br />
<br />
This will allow users to mount it aslong as the mount point resides in a directory ''controllable'' by the user; i.e. the user's home. For users to be allowed to mount and unmount the Samba shares with mount points that they do not own, use [[#smbnetfs]], or grant privileges using [[sudo]].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Share files without a username and password ===<br />
<br />
<br />
Edit {{ic|/etc/samba/smb.conf}} and add the following line:<br />
<br />
map to guest = Bad User<br />
<br />
After this line<br />
<br />
security = user<br />
<br />
Restrict the shares data to a specific interface replace:<br />
<br />
; interfaces = 192.168.12.2/24 192.168.13.2/24<br />
<br />
with:<br />
<br />
interfaces = lo eth0<br />
bind interfaces only = true<br />
<br />
Optionally edit the account that access the shares, edit the following line:<br />
<br />
; guest account = nobody<br />
<br />
The last step is to create share directory (for write access make writable = yes):<br />
<br />
[Public Share]<br />
path = /path/to/public/share<br />
available = yes<br />
browsable = yes<br />
public = yes<br />
writable = no<br />
<br />
=== Sample configuration file ===<br />
<br />
The configuration that worked for one user:<br />
[global]<br />
workgroup = WORKGROUP<br />
server string = Samba Server<br />
netbios name = PC_NAME<br />
security = share<br />
; the line below is important! If you have permission issues make<br />
; sure the user here is the same as the user of the folder you<br />
; want to share<br />
guest account = mark<br />
username map = /etc/samba/smbusers<br />
name resolve order = hosts wins bcast<br />
wins support = no<br /><br />
[public]<br />
comment = Public Share<br />
path = /path/to/public/share<br />
available = yes<br />
browsable = yes<br />
public = yes<br />
writable = no<br />
<br />
=== Adding network shares using KDE4 GUI ===<br />
How to configure the folder sharing in KDE4. Simple file sharing limits user shared folders to their home directory and read-only access. Advanced file sharing gives full semantics of Samba with no limits to shared folders but requires su or sudo root permissions.<br />
* Read only, simple file sharing: [[Samba/Simple file sharing with KDE4]]<br />
* Full capability file sharing: [[Samba/Advanced file sharing with KDE4]]<br />
<br />
=== Discovering network shares ===<br />
<br />
If nothing is known about other systems on the local network, and automated tools such as [[#smbnetfs]] are not available, the following methods allow one to manually probe for Samba shares.<br />
<br />
1. First, install {{Pkg|nmap}} and {{Pkg|smbclient}} using [[pacman]]:<br />
# pacman -S nmap smbclient<br />
<br />
2. {{ic|nmap}} checks which ports are open:<br />
# nmap -p 139 -sT 192.168.1.*<br />
<br />
In this case, a scan on the 192.168.1.* IP address range and port 139 has been performed, resulting in:<br />
{{hc<br />
|$ nmap -sT 192.168.1.*<br />
|Starting nmap 3.78 ( http://www.insecure.org/nmap/ ) at 2005-02-15 11:45 PHT<br />
Interesting ports on 192.168.1.1:<br />
(The 1661 ports scanned but not shown below are in state: closed)<br />
PORT STATE SERVICE<br />
'''139/tcp open netbios-ssn'''<br />
5000/tcp open UPnP<br />
<br />
Interesting ports on 192.168.1.5:<br />
(The 1662 ports scanned but not shown below are in state: closed)<br />
PORT STATE SERVICE<br />
6000/tcp open X11<br />
<br />
Nmap run completed -- 256 IP addresses (2 hosts up) scanned in 7.255 seconds<br />
}}<br />
<br />
The first result is another system; the second happens to be the client from where this scan was performed.<br />
<br />
3. Now that systems with port 139 open are revealed, use {{ic|nmblookup}} to check for NetBIOS names: <br />
{{hc<br />
|$ nmblookup -A 192.168.1.1<br />
|Looking up status of 192.168.1.1<br />
PUTER <00> - B <ACTIVE><br />
HOMENET <00> - <GROUP> B <ACTIVE><br />
PUTER <03> - B <ACTIVE><br />
'''PUTER <20> - B <ACTIVE>'''<br />
HOMENET <1e> - <GROUP> B <ACTIVE><br />
USERNAME <03> - B <ACTIVE><br />
HOMENET <1d> - B <ACTIVE><br />
MSBROWSE <01> - <GROUP> B <ACTIVE><br />
}}<br />
<br />
Regardless of the output, look for '''<20>''', which shows the host with open services.<br />
<br />
4. Use {{ic|smbclient}} to list which services are shared on ''PUTER''. If prompted for a password, pressing enter should still display the list:<br />
{{hc<br />
|$ smbclient -L \\PUTER<br />
|<nowiki><br />
Sharename Type Comment<br />
--------- ---- -------<br />
MY_MUSIC Disk<br />
SHAREDDOCS Disk<br />
PRINTER$ Disk<br />
PRINTER Printer<br />
IPC$ IPC Remote Inter Process Communication<br />
<br />
Server Comment<br />
--------- -------<br />
PUTER<br />
<br />
Workgroup Master<br />
--------- -------<br />
HOMENET PUTER<br />
</nowiki>}}<br />
<br />
This shows which folders are shared and can be mounted locally. See: [[#Accessing shares]]<br />
<br />
=== Remote control of Windows computer ===<br />
<br />
Samba offers a set of tools for communication with Windows. These can be handy if access to a Windows computer through remote desktop is not an option, as shown by some examples.<br />
<br />
Send shutdown command with a comment:<br />
<br />
$ net rpc shutdown -C "comment" -I IPADDRESS -U USERNAME%PASSWORD<br />
A forced shutdown instead can be invoked by changing -C with comment to a single -f. For a restart, only add -r, followed by a -C or -f.<br />
<br />
Stop and start services:<br />
<br />
$ net rpc service stop SERVICENAME -I IPADDRESS -U USERNAME%PASSWORD<br />
<br />
To see all possible net rpc command:<br />
<br />
$ net rpc<br />
<br />
=== Block certain file extensions on samba share ===<br />
<br />
Samba offers an option to block files with certain patterns, like file extensions. This option can be used to prevent dissemination of viruses or to disuade users from wasting space with certain files:<br />
<br />
Veto files = /*.exe/*.com/*.dll/*.bat/*.vbs/*.tmp/*.mp3/*.avi/*.mp4/*.wmv/*.wma/<br />
<br />
== Troubleshooting ==<br />
=== Windows 7 connectivity problems - mount error(12): cannot allocate memory ===<br />
<br />
A known Windows 7 bug that causes "mount error(12): cannot allocate memory" on an otherwise perfect cifs share on the Linux end can be fixed by setting a few registry keys on the Windows box as follows:<br />
<br />
*HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache (set to 1)<br />
*HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size (set to 3)<br />
<br />
Restart the Windows machine for the settings to take effect.<br />
<br />
{{Note| Googling will reveal another tweak recommending users to add a key modifying the "IRPStackSize" size. This is incorrect for fixing this issue under Windows 7. Do not attempt it.}}<br />
<br />
[http://alan.lamielle.net/2009/09/03/windows-7-nonpaged-pool-srv-error-2017 Link] to original article.<br />
<br />
=== Trouble accessing a password-protected share from Windows ===<br />
<br />
For trouble accessing a password protected share from Windows, try adding this to {{ic|/etc/samba/smb.conf}}:[http://blogs.computerworld.com/networking_nightmare_ii_adding_linux]<br />
<br />
Note that this needs to be added to the '''local''' smb.conf, not to the server's smb.conf<br />
<br />
[global]<br />
# lanman fix<br />
client lanman auth = yes<br />
client ntlmv2 auth = no<br />
<br />
=== Getting a dialog box up takes a long time ===<br />
<br />
I had a problem that it took ~30 seconds to get a password dialog box up when trying to connect from both Windows XP/Windows 7. Analyzing the error.log on the server I saw:<br />
<br />
[2009/11/11 06:20:12, 0] printing/print_cups.c:cups_connect(103)<br />
Unable to connect to CUPS server localhost:631 - Interrupted system call<br />
<br />
This keeps samba from asking cups and also from complaining about /etc/printcap missing:<br />
<br />
printing = bsd<br />
printcap name = /dev/null<br />
<br />
=== Changes in Samba version 3.4.0 ===<br />
<br />
[http://www.samba.org/samba/history/samba-3.4.0.html Major enhancements in Samba 3.4.0] include:<br />
<br />
The default passdb backend has been changed to 'tdbsam'! That breaks existing setups using the 'smbpasswd' backend without explicit declaration!<br />
<br />
To stick to the 'smbpasswd' backend try changing this in {{ic|/etc/samba/smb.conf}}:<br />
<br />
passdb backend = smbpasswd<br />
<br />
or convert the smbpasswd entries using:<br />
<br />
sudo pdbedit -i smbpasswd -e tdbsam<br />
<br />
=== Error: Value too large for defined data type ===<br />
<br />
Some applications might encounter this error whith every attempt to open a file mounted in smbfs/cifs:<br />
<br />
Value too large for defined data type<br />
<br />
The solution[https://bugs.launchpad.net/ubuntu/+bug/479266/comments/5] is to add this options to the smbfs/cifs mount options (in /etc/fstab for example):<br />
<br />
,nounix,noserverino<br />
<br />
''It works on Arch Linux up-to-date (2009-12-02)''<br />
<br />
=== I need to restart samba in order get my shares visible by other ===<br />
<br />
If upon booting, the samba shares cannot be accessed from any client, check the following:<br />
* Make sure that the samba daemon has been added to the DAEMONS array of /etc/rc.conf (after the 'network' daemon)<br />
* The ''network'' service is not started in the background (prefixed with @ ). Removing the '@' in front of 'network' can fix the issue. Reboot to check.<br />
<br />
My guess on what has happened: When samba starts, the network is not properly initialized, so the server does not know on which interface to listen and thus fails to initialize correctly.<br />
<br />
In case starting samba in the correct order still doesn't help, try inserting a delay command into /etc/rc.d/samba:<br />
#!/bin/bash<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
[ -f /etc/conf.d/samba ] && . /etc/conf.d/samba<br />
<br />
[ -z "$SAMBA_DAEMONS" ] && SAMBA_DAEMONS=(smbd nmbd)<br />
<br />
case "$1" in<br />
start)<br />
rc=0<br />
stat_busy "Starting Samba Server"<br />
sleep 5<br />
if [ ! -x /var/run/samba ] ; then<br />
# rest of the file not posted here.<br />
<br />
Only the '''sleep 5''' line is inserted, everything else is as from the Arch repositories.<br />
It causes a delay of 5 seconds before starting the samba server. In order to avoid the additional boot-time, start the Samba daemon in background, as described above.<br />
<br />
The file /etc/rc.d/samba is part of the samba package, though. Therefore, manually apply this change every time Samba gets updated.<br />
<br />
=== Sharing a folder fails ===<br />
<br />
If sharing a folder from Dolphin (file manager) and everything seems ok at first, but after restarting Dolphin (file manager) the share icon is gone from the shared folder, and also some output like this in terminal (Konsole) output:<br />
‘net usershare’ returned error 255: net usershare: usershares are currently disabled<br />
Do the following:<br />
<br />
Open {{ic|/etc/samba/smb.conf}} as root and edit the section {{ic|[global]}}:<br />
[global]<br />
'''.....'''<br />
usershare allow guests = Yes<br />
usershare max shares = 100<br />
usershare owner only = False<br />
'''.....'''<br />
close the file and do the following afterwards:{{bc|<br />
# mkdir /var/lib/samba/usershares<br />
# chgrp users /var/lib/samba/usershares/<br />
# chmod 1770 /var/lib/samba/usershares/<br />
}}<br />
restart {{ic|samba}} [[daemon]]<br />
<br />
That's it! (solution was originally found [http://ryan.rawswift.com/tag/usershare/ here])<br />
<br />
dmarkey Edit:<br />
<br />
I could only get this to work with:<br />
<br />
{{bc|<br />
# chmod 1775 /var/lib/samba/usershares/<br />
}}<br />
<br />
<br />
<br />
==See also==<br />
* [http://www.samba.org/ Samba's official site]<br />
* [http://www.samba.org/samba/docs/SambaIntro.html Samba: An Introduction]</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=237541User:Xorrr2012-12-01T14:00:50Z<p>Xorrr: </p>
<hr />
<div>(:</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=237540User:Xorrr2012-12-01T14:00:21Z<p>Xorrr: </p>
<hr />
<div>::)</div>Xorrrhttps://wiki.archlinux.org/index.php?title=User:Xorrr&diff=237539User:Xorrr2012-12-01T14:00:10Z<p>Xorrr: Created page with ":)"</p>
<hr />
<div>:)</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=204631Nextcloud2012-06-12T20:29:03Z<p>Xorrr: </p>
<hr />
<div>[[Category:Networking]]<br />
{{i18n|Owncloud}}<br />
<br />
[http://en.wikipedia.org/wiki/OwnCloud ownCloud] is a software suite that provides a location-independent storage area for data (cloud storage).<br />
<br />
== Installation ==<br />
{{AUR|owncloud}} is available in the [[AUR]]. <br />
#First of all set up the [[LAMP]] stack as described in the corresponding Wiki article. <br />
#Install the {{AUR|owncloud}} package as described in [[AUR#Installing_packages]].<br />
#Add the following lines into '''/etc/httpd/conf/httpd.conf''':<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in '''/etc/php/php.ini'''<br />
gd.so<br />
xmlrpc.so<br />
zip.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in '''/etc/php/php.ini'''<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
OR<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
now restart the apache server with:<br />
# rc.d restart httpd<br />
and open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in '''/etc/php/php.ini''' to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=202162Nextcloud2012-05-19T00:33:57Z<p>Xorrr: </p>
<hr />
<div>[http://en.wikipedia.org/wiki/OwnCloud ownCloud] is a software suite that provides a location-independent storage area for data (cloud storage).<br />
<br />
== Installation ==<br />
{{AUR|owncloud}} is available in the [[AUR]]. <br />
#First of all set up the [[LAMP]] stack as described in the corresponding Wiki article. <br />
#Install the {{AUR|owncloud}} package as described in [[AUR#Installing_packages]].<br />
#Add the following lines into '''/etc/httpd/conf/httpd.conf''':<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in '''/etc/php/php.ini'''<br />
gd.so<br />
xmlrpc.so<br />
zip.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in '''/etc/php/php.ini'''<br />
sqlite.so<br />
sqlite3.so<br />
OR<br />
mysql.so<br />
mysqli.so<br />
now restart the apache server with:<br />
# rc.d restart httpd<br />
and open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
== Custom configurations ==<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in '''/etc/php/php.ini''' to your liking.<br />
upload_max_filesize = 2M</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=202161Nextcloud2012-05-19T00:32:02Z<p>Xorrr: </p>
<hr />
<div>[http://en.wikipedia.org/wiki/OwnCloud ownCloud] is a software suite that provides a location-independent storage area for data (cloud storage).<br />
<br />
== Installation ==<br />
{{AUR|owncloud}} is available in the [[AUR]]. <br />
#First of all set up the [[LAMP]] stack as described in the corresponding Wiki article. <br />
#Install the {{AUR|owncloud}} package as described in [[AUR#Installing_packages]].<br />
#Add the following lines into '''/etc/httpd/conf/httpd.conf''':<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in '''/etc/php/php.ini'''<br />
gd.so<br />
xmlrpc.so<br />
zip.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in '''/etc/php/php.ini'''<br />
sqlite.so<br />
sqlite3.so<br />
OR<br />
mysql.so<br />
mysqli.so<br />
now restart the apache server with:<br />
rc.d restart httpd<br />
and open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
== Custom configurations ==<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in '''/etc/php/php.ini''' to your liking.<br />
upload_max_filesize = 2M</div>Xorrrhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=202160Nextcloud2012-05-19T00:26:36Z<p>Xorrr: Created page with "[http://en.wikipedia.org/wiki/OwnCloud ownCloud] is a software suite that provides a location-independent storage area for data (cloud storage). == Installation == {{AUR|own..."</p>
<hr />
<div>[http://en.wikipedia.org/wiki/OwnCloud ownCloud] is a software suite that provides a location-independent storage area for data (cloud storage).<br />
<br />
== Installation ==<br />
{{AUR|owncloud}} is available in the [[AUR]]. <br />
#First of all set up the [[LAMP]] stack as described in the corresponding Wiki article. <br />
#Install the {{AUR|owncloud}} package as described in [[AUR#Installing_packages]].<br />
#Add the following lines into '''/etc/httpd/conf/httpd.conf''':<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
Uncomment extensions in '''/etc/php/php.ini'''<br />
gd.so<br />
xmlrpc.so<br />
zip.so<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in '''/etc/php/php.ini'''<br />
sqlite.so<br />
sqlite3.so<br />
OR<br />
mysql.so<br />
mysqli.so<br />
now restart the apache server with:<br />
rc.d restart httpd<br />
== Custom configurations ==<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in '''/etc/php/php.ini''' to your liking.<br />
upload_max_filesize = 2M</div>Xorrr