1 ===========================
2 The Tahoe-LAFS CLI commands
3 ===========================
6 2. `CLI Command Overview`_
11 4. `Filesystem Manipulation`_
13 1. `Starting Directories`_
14 2. `Command Syntax Summary`_
15 3. `Command Examples`_
17 5. `Storage Grid Maintenance`_
24 Tahoe-LAFS provides a single executable named "``tahoe``", which can be used to
25 create and manage client/server nodes, manipulate the filesystem, and perform
26 several debugging/maintenance tasks.
28 This executable lives in the source tree at "``bin/tahoe``". Once you've done a
29 build (by running "``make``" or "``python setup.py build``"), ``bin/tahoe`` can
30 be run in-place: if it discovers that it is being run from within a Tahoe-LAFS
31 source tree, it will modify ``sys.path`` as necessary to use all the source code
32 and dependent libraries contained in that tree.
34 If you've installed Tahoe-LAFS (using "``make install``" or
35 "``python setup.py install``", or by installing a binary package), then the
36 ``tahoe`` executable will be available somewhere else, perhaps in
37 ``/usr/bin/tahoe``. In this case, it will use your platform's normal
38 PYTHONPATH search path to find the Tahoe-LAFS code and other libraries.
44 The "``tahoe``" tool provides access to three categories of commands.
46 * node management: create a client/server node, start/stop/restart it
47 * filesystem manipulation: list files, upload, download, delete, rename
48 * debugging: unpack cap-strings, examine share files
50 To get a list of all commands, just run "``tahoe``" with no additional
51 arguments. "``tahoe --help``" might also provide something useful.
53 Running "``tahoe --version``" will display a list of version strings, starting
54 with the "allmydata" module (which contains the majority of the Tahoe-LAFS
55 functionality) and including versions for a number of dependent libraries,
56 like Twisted, Foolscap, pycryptopp, and zfec. "``tahoe --version-and-path``"
57 will also show the path from which each library was imported.
59 On Unix systems, the shell expands filename wildcards (``*`` and ``?``)
60 before the program is able to read them, which may produce unexpected
61 results for many ``tahoe`` comands. We recommend that you avoid using them.
62 On Windows, wildcards cannot be used to specify multiple filenames to
68 As of Tahoe-LAFS v1.7.0 (v1.8.0 on Windows), the ``tahoe`` tool supports
69 non-ASCII characters in command lines and output. On Unix, the command-line
70 arguments are assumed to use the character encoding specified by the
71 current locale (usually given by the ``LANG`` environment variable).
73 If a name to be output contains control characters or characters that
74 cannot be represented in the encoding used on your terminal, it will be
75 quoted. The quoting scheme used is similar to `POSIX shell quoting`_: in
76 a "double-quoted" string, backslashes introduce escape sequences (like
77 those in Python strings), but in a 'single-quoted' string all characters
78 stand for themselves. This quoting is only used for output, on all
79 operating systems. Your shell interprets any quoting or escapes used on
82 .. _`POSIX shell quoting`: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
88 "``tahoe create-node [NODEDIR]``" is the basic make-a-new-node command. It
89 creates a new directory and populates it with files that will allow the
90 "``tahoe start``" command to use it later on. This command creates nodes that
91 have client functionality (upload/download files), web API services
92 (controlled by the 'webport' file), and storage services (unless
93 ``--no-storage`` is specified).
95 NODEDIR defaults to ``~/.tahoe/`` , and newly-created nodes default to
96 publishing a web server on port 3456 (limited to the loopback interface, at
97 127.0.0.1, to restrict access to other programs on the same host). All of the
98 other "``tahoe``" subcommands use corresponding defaults (with the exception
99 that "``tahoe run``" defaults to running a node in the current directory).
101 "``tahoe create-client [NODEDIR]``" creates a node with no storage service.
102 That is, it behaves like "``tahoe create-node --no-storage [NODEDIR]``".
103 (This is a change from versions prior to v1.6.0.)
105 "``tahoe create-introducer [NODEDIR]``" is used to create the Introducer node.
106 This node provides introduction services and nothing else. When started, this
107 node will produce an ``introducer.furl`` file, which should be published to all
110 "``tahoe create-key-generator [NODEDIR]``" is used to create a special
111 "key-generation" service, which allows a client to offload their RSA key
112 generation to a separate process. Since RSA key generation takes several
113 seconds, and must be done each time a directory is created, moving it to a
114 separate process allows the first process (perhaps a busy web-API server) to
115 continue servicing other requests. The key generator exports a FURL that can
116 be copied into a node to enable this functionality.
118 "``tahoe run [NODEDIR]``" will start a previously-created node in the foreground.
120 "``tahoe start [NODEDIR]``" will launch a previously-created node. It will
121 launch the node into the background, using the standard Twisted "``twistd``"
122 daemon-launching tool. On some platforms (including Windows) this command is
123 unable to run a daemon in the background; in that case it behaves in the
124 same way as "``tahoe run``".
126 "``tahoe stop [NODEDIR]``" will shut down a running node.
128 "``tahoe restart [NODEDIR]``" will stop and then restart a running node. This
129 is most often used by developers who have just modified the code and want to
130 start using their changes.
133 Filesystem Manipulation
134 =======================
136 These commands let you exmaine a Tahoe-LAFS filesystem, providing basic
137 list/upload/download/delete/rename/mkdir functionality. They can be used as
138 primitives by other scripts. Most of these commands are fairly thin wrappers
139 around web-API calls, which are described in `<webapi.rst>`_.
141 By default, all filesystem-manipulation commands look in ``~/.tahoe/`` to
142 figure out which Tahoe-LAFS node they should use. When the CLI command makes
143 web-API calls, it will use ``~/.tahoe/node.url`` for this purpose: a running
144 Tahoe-LAFS node that provides a web-API port will write its URL into this
145 file. If you want to use a node on some other host, just create ``~/.tahoe/``
146 and copy that node's web-API URL into this file, and the CLI commands will
147 contact that node instead of a local one.
149 These commands also use a table of "aliases" to figure out which directory
150 they ought to use a starting point. This is explained in more detail below.
155 As described in `docs/architecture.rst <../architecture.rst>`_, the
156 Tahoe-LAFS distributed filesystem consists of a collection of directories
157 and files, each of which has a "read-cap" or a "write-cap" (also known as
158 a URI). Each directory is simply a table that maps a name to a child file
159 or directory, and this table is turned into a string and stored in a
160 mutable file. The whole set of directory and file "nodes" are connected
161 together into a directed graph.
163 To use this collection of files and directories, you need to choose a
164 starting point: some specific directory that we will refer to as a
165 "starting directory". For a given starting directory, the
166 "``ls [STARTING_DIR]``" command would list the contents of this directory,
167 the "``ls [STARTING_DIR]/dir1``" command would look inside this directory
168 for a child named "``dir1``" and list its contents,
169 "``ls [STARTING_DIR]/dir1/subdir2``" would look two levels deep, etc.
171 Note that there is no real global "root" directory, but instead each
172 starting directory provides a different, possibly overlapping
173 perspective on the graph of files and directories.
175 Each Tahoe-LAFS node remembers a list of starting points, called "aliases",
176 which are short Unicode strings that stand in for a directory read- or
177 write- cap. They are stored (encoded as UTF-8) in the file
178 ``NODEDIR/private/aliases`` . If you use the command line "``tahoe ls``"
179 without any "[STARTING_DIR]" argument, then it will use the default alias,
180 which is ``tahoe:``, therefore "``tahoe ls``" has the same effect as
181 "``tahoe ls tahoe:``". The same goes for the other commands that can
182 reasonably use a default alias: ``get``, ``put``, ``mkdir``, ``mv``, and
185 For backwards compatibility with Tahoe-LAFS v1.0, if the ``tahoe:`` alias
186 is not found in ``~/.tahoe/private/aliases``, the CLI will use the contents
187 of ``~/.tahoe/private/root_dir.cap`` instead. Tahoe-LAFS v1.0 had only a
188 single starting point, and stored it in this ``root_dir.cap`` file, so v1.1
189 and later will use it if necessary. However, once you've set a ``tahoe:``
190 alias with "``tahoe set-alias``", that will override anything in the old
191 ``root_dir.cap`` file.
193 The Tahoe-LAFS CLI commands use the same path syntax as ``scp`` and
194 ``rsync`` -- an optional ``ALIAS:`` prefix, followed by the pathname or
195 filename. Some commands (like "``tahoe cp``") use the lack of an alias to
196 mean that you want to refer to a local file, instead of something from the
197 Tahoe-LAFS filesystem. [TODO] Another way to indicate this is to start
198 the pathname with a dot, slash, or tilde.
200 When you're dealing a single starting directory, the ``tahoe:`` alias is
201 all you need. But when you want to refer to something that isn't yet
202 attached to the graph rooted at that starting directory, you need to
203 refer to it by its capability. The way to do that is either to use its
204 capability directory as an argument on the command line, or to add an
205 alias to it, with the "``tahoe add-alias``" command. Once you've added an
206 alias, you can use that alias as an argument to commands.
208 The best way to get started with Tahoe-LAFS is to create a node, start it,
209 then use the following command to create a new directory and set it as your
212 tahoe create-alias tahoe
214 After that you can use "``tahoe ls tahoe:``" and
215 "``tahoe cp local.txt tahoe:``", and both will refer to the directory that
218 SECURITY NOTE: For users of shared systems
219 ``````````````````````````````````````````
221 Another way to achieve the same effect as the above "``tahoe create-alias``"
224 tahoe add-alias tahoe `tahoe mkdir`
226 However, command-line arguments are visible to other users (through the
227 ``ps`` command or ``/proc`` filesystem, or the Windows Process Explorer tool),
228 so if you are using a Tahoe-LAFS node on a shared host, your login neighbors
229 will be able to see (and capture) any directory caps that you set up with the
230 "``tahoe add-alias``" command.
232 The "``tahoe create-alias``" command avoids this problem by creating a new
233 directory and putting the cap into your aliases file for you. Alternatively,
234 you can edit the ``NODEDIR/private/aliases`` file directly, by adding a line
237 fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
239 By entering the dircap through the editor, the command-line arguments are
240 bypassed, and other users will not be able to see them. Once you've added the
241 alias, no other secrets are passed through the command line, so this
242 vulnerability becomes less significant: they can still see your filenames and
243 other arguments you type there, but not the caps that Tahoe-LAFS uses to permit
244 access to your files and directories.
247 Command Syntax Summary
248 ----------------------
250 ``tahoe add-alias ALIAS DIRCAP``
252 ``tahoe create-alias ALIAS``
254 ``tahoe list-aliases``
262 ``tahoe webopen [PATH]``
264 ``tahoe put [--mutable] [FROMLOCAL|-]``
266 ``tahoe put [--mutable] FROMLOCAL|- TOPATH``
268 ``tahoe put [FROMLOCAL|-] mutable-file-writecap``
270 ``tahoe get FROMPATH [TOLOCAL|-]``
272 ``tahoe cp [-r] FROMPATH TOPATH``
276 ``tahoe mv FROMPATH TOPATH``
278 ``tahoe ln FROMPATH TOPATH``
280 ``tahoe backup FROMLOCAL TOPATH``
282 In these summaries, ``PATH``, ``TOPATH`` or ``FROMPATH`` can be one of:
284 * ``[SUBDIRS/]FILENAME`` for a path relative to the default ``tahoe:`` alias;
285 * ``ALIAS:[SUBDIRS/]FILENAME`` for a path relative to another alias;
286 * ``DIRCAP/[SUBDIRS/]FILENAME`` or ``DIRCAP:./[SUBDIRS/]FILENAME`` for a path
287 relative to a directory cap.
293 ``tahoe add-alias ALIAS DIRCAP``
295 An example would be::
297 tahoe add-alias fun URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
299 This creates an alias ``fun:`` and configures it to use the given directory
300 cap. Once this is done, "``tahoe ls fun:``" will list the contents of this
301 directory. Use "``tahoe add-alias tahoe DIRCAP``" to set the contents of the
302 default ``tahoe:`` alias.
304 ``tahoe create-alias fun``
306 This combines "``tahoe mkdir``" and "``tahoe add-alias``" into a single step.
308 ``tahoe list-aliases``
310 This displays a table of all configured aliases.
314 This creates a new empty unlinked directory, and prints its write-cap to
315 stdout. The new directory is not attached to anything else.
317 ``tahoe mkdir subdir``
319 ``tahoe mkdir /subdir``
321 This creates a new empty directory and attaches it below the root directory
322 of the default ``tahoe:`` alias with the name "``subdir``".
332 All four list the root directory of the default ``tahoe:`` alias.
336 This lists a subdirectory of your filesystem.
340 ``tahoe webopen tahoe:``
342 ``tahoe webopen tahoe:subdir/``
344 ``tahoe webopen subdir/``
346 This uses the python 'webbrowser' module to cause a local web browser to
347 open to the web page for the given directory. This page offers interfaces to
348 add, download, rename, and delete files in the directory. If no alias or
349 path is given, this command opens the root directory of the default
352 ``tahoe put file.txt``
354 ``tahoe put ./file.txt``
356 ``tahoe put /tmp/file.txt``
358 ``tahoe put ~/file.txt``
360 These upload the local file into the grid, and prints the new read-cap to
361 stdout. The uploaded file is not attached to any directory. All one-argument
362 forms of "``tahoe put``" perform an unlinked upload.
368 These also perform an unlinked upload, but the data to be uploaded is taken
371 ``tahoe put file.txt uploaded.txt``
373 ``tahoe put file.txt tahoe:uploaded.txt``
375 These upload the local file and add it to your ``tahoe:`` root with the name
378 ``tahoe put file.txt subdir/foo.txt``
380 ``tahoe put - subdir/foo.txt``
382 ``tahoe put file.txt tahoe:subdir/foo.txt``
384 ``tahoe put file.txt DIRCAP/foo.txt``
386 ``tahoe put file.txt DIRCAP/subdir/foo.txt``
388 These upload the named file and attach them to a subdirectory of the given
389 root directory, under the name "``foo.txt``". When a directory write-cap is
390 given, you can use either ``/`` (as shown above) or ``:./`` to separate it
391 from the following path. When the source file is named "``-``", the contents
392 are taken from stdin.
394 ``tahoe put file.txt --mutable``
396 Create a new mutable file, fill it with the contents of ``file.txt``, and
397 print the new write-cap to stdout.
399 ``tahoe put file.txt MUTABLE-FILE-WRITECAP``
401 Replace the contents of the given mutable file with the contents of ``file.txt``
402 and prints the same write-cap to stdout.
404 ``tahoe cp file.txt tahoe:uploaded.txt``
406 ``tahoe cp file.txt tahoe:``
408 ``tahoe cp file.txt tahoe:/``
410 ``tahoe cp ./file.txt tahoe:``
412 These upload the local file and add it to your ``tahoe:`` root with the name
415 ``tahoe cp tahoe:uploaded.txt downloaded.txt``
417 ``tahoe cp tahoe:uploaded.txt ./downloaded.txt``
419 ``tahoe cp tahoe:uploaded.txt /tmp/downloaded.txt``
421 ``tahoe cp tahoe:uploaded.txt ~/downloaded.txt``
423 This downloads the named file from your ``tahoe:`` root, and puts the result on
424 your local filesystem.
426 ``tahoe cp tahoe:uploaded.txt fun:stuff.txt``
428 This copies a file from your ``tahoe:`` root to a different directory, set up
429 earlier with "``tahoe add-alias fun DIRCAP``" or "``tahoe create-alias fun``".
431 ``tahoe rm uploaded.txt``
433 ``tahoe rm tahoe:uploaded.txt``
435 This deletes a file from your ``tahoe:`` root.
437 ``tahoe mv uploaded.txt renamed.txt``
439 ``tahoe mv tahoe:uploaded.txt tahoe:renamed.txt``
441 These rename a file within your ``tahoe:`` root directory.
443 ``tahoe mv uploaded.txt fun:``
445 ``tahoe mv tahoe:uploaded.txt fun:``
447 ``tahoe mv tahoe:uploaded.txt fun:uploaded.txt``
449 These move a file from your ``tahoe:`` root directory to the directory
450 set up earlier with "``tahoe add-alias fun DIRCAP``" or
451 "``tahoe create-alias fun``".
453 ``tahoe backup ~ work:backups``
455 This command performs a full versioned backup of every file and directory
456 underneath your "``~``" home directory, placing an immutable timestamped
457 snapshot in e.g. ``work:backups/Archives/2009-02-06_04:00:05Z/`` (note that
458 the timestamp is in UTC, hence the "Z" suffix), and a link to the latest
459 snapshot in work:backups/Latest/ . This command uses a small SQLite database
460 known as the "backupdb", stored in ``~/.tahoe/private/backupdb.sqlite``, to
461 remember which local files have been backed up already, and will avoid
462 uploading files that have already been backed up. It compares timestamps and
463 filesizes when making this comparison. It also re-uses existing directories
464 which have identical contents. This lets it run faster and reduces the
465 number of directories created.
467 If you reconfigure your client node to switch to a different grid, you
468 should delete the stale backupdb.sqlite file, to force "``tahoe backup``"
469 to upload all files to the new grid.
471 ``tahoe backup --exclude=*~ ~ work:backups``
473 Same as above, but this time the backup process will ignore any
474 filename that will end with '~'. ``--exclude`` will accept any standard
475 Unix shell-style wildcards, as implemented by the
476 `Python fnmatch module <http://docs.python.org/library/fnmatch.html>`_.
477 You may give multiple ``--exclude`` options. Please pay attention that
478 the pattern will be matched against any level of the directory tree;
479 it's still impossible to specify absolute path exclusions.
481 ``tahoe backup --exclude-from=/path/to/filename ~ work:backups``
483 ``--exclude-from`` is similar to ``--exclude``, but reads exclusion
484 patterns from ``/path/to/filename``, one per line.
486 ``tahoe backup --exclude-vcs ~ work:backups``
488 This command will ignore any file or directory name known to be used by
489 version control systems to store metadata. The excluded names are:
510 Storage Grid Maintenance
511 ========================
513 ``tahoe manifest tahoe:``
515 ``tahoe manifest --storage-index tahoe:``
517 ``tahoe manifest --verify-cap tahoe:``
519 ``tahoe manifest --repair-cap tahoe:``
521 ``tahoe manifest --raw tahoe:``
523 This performs a recursive walk of the given directory, visiting every file
524 and directory that can be reached from that point. It then emits one line to
525 stdout for each object it encounters.
527 The default behavior is to print the access cap string (like ``URI:CHK:..``
528 or ``URI:DIR2:..``), followed by a space, followed by the full path name.
530 If ``--storage-index`` is added, each line will instead contain the object's
531 storage index. This (string) value is useful to determine which share files
532 (on the server) are associated with this directory tree. The ``--verify-cap``
533 and ``--repair-cap`` options are similar, but emit a verify-cap and repair-cap,
534 respectively. If ``--raw`` is provided instead, the output will be a
535 JSON-encoded dictionary that includes keys for pathnames, storage index
536 strings, and cap strings. The last line of the ``--raw`` output will be a JSON
537 encoded deep-stats dictionary.
539 ``tahoe stats tahoe:``
541 This performs a recursive walk of the given directory, visiting every file
542 and directory that can be reached from that point. It gathers statistics on
543 the sizes of the objects it encounters, and prints a summary to stdout.
549 For a list of all debugging commands, use "``tahoe debug``".
551 "``tahoe debug find-shares STORAGEINDEX NODEDIRS..``" will look through one or
552 more storage nodes for the share files that are providing storage for the
555 "``tahoe debug catalog-shares NODEDIRS..``" will look through one or more
556 storage nodes and locate every single share they contain. It produces a report
557 on stdout with one line per share, describing what kind of share it is, the
558 storage index, the size of the file is used for, etc. It may be useful to
559 concatenate these reports from all storage hosts and use it to look for
562 "``tahoe debug dump-share SHAREFILE``" will take the name of a single share file
563 (as found by "``tahoe find-shares``") and print a summary of its contents to
564 stdout. This includes a list of leases, summaries of the hash tree, and
565 information from the UEB (URI Extension Block). For mutable file shares, it
566 will describe which version (seqnum and root-hash) is being stored in this
569 "``tahoe debug dump-cap CAP``" will take any Tahoe-LAFS URI and unpack it
570 into separate pieces. The most useful aspect of this command is to reveal the
571 storage index for any given URI. This can be used to locate the share files
572 that are holding the encoded+encrypted data for this file.
574 "``tahoe debug repl``" will launch an interactive Python interpreter in which
575 the Tahoe-LAFS packages and modules are available on ``sys.path`` (e.g. by using
576 '``import allmydata``'). This is most useful from a source tree: it simply sets
577 the PYTHONPATH correctly and runs the Python executable.
579 "``tahoe debug corrupt-share SHAREFILE``" will flip a bit in the given
580 sharefile. This can be used to test the client-side verification/repair code.
581 Obviously, this command should not be used during normal operation.