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, unlink, 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 '[node]web.port' configuration), and storage services
93 (unless ``--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/unlink/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 Since Tahoe-LAFS v1.8.2, the alias name can be given with or without the
307 ``tahoe create-alias fun``
309 This combines "``tahoe mkdir``" and "``tahoe add-alias``" into a single step.
311 ``tahoe list-aliases``
313 This displays a table of all configured aliases.
317 This creates a new empty unlinked directory, and prints its write-cap to
318 stdout. The new directory is not attached to anything else.
320 ``tahoe mkdir subdir``
322 ``tahoe mkdir /subdir``
324 This creates a new empty directory and attaches it below the root directory
325 of the default ``tahoe:`` alias with the name "``subdir``".
335 All four list the root directory of the default ``tahoe:`` alias.
339 This lists a subdirectory of your filesystem.
343 ``tahoe webopen tahoe:``
345 ``tahoe webopen tahoe:subdir/``
347 ``tahoe webopen subdir/``
349 This uses the python 'webbrowser' module to cause a local web browser to
350 open to the web page for the given directory. This page offers interfaces to
351 add, download, rename, and unlink files and subdirectories in that directory.
352 If no alias or path is given, this command opens the root directory of the
353 default ``tahoe:`` alias.
355 ``tahoe put file.txt``
357 ``tahoe put ./file.txt``
359 ``tahoe put /tmp/file.txt``
361 ``tahoe put ~/file.txt``
363 These upload the local file into the grid, and prints the new read-cap to
364 stdout. The uploaded file is not attached to any directory. All one-argument
365 forms of "``tahoe put``" perform an unlinked upload.
371 These also perform an unlinked upload, but the data to be uploaded is taken
374 ``tahoe put file.txt uploaded.txt``
376 ``tahoe put file.txt tahoe:uploaded.txt``
378 These upload the local file and add it to your ``tahoe:`` root with the name
381 ``tahoe put file.txt subdir/foo.txt``
383 ``tahoe put - subdir/foo.txt``
385 ``tahoe put file.txt tahoe:subdir/foo.txt``
387 ``tahoe put file.txt DIRCAP/foo.txt``
389 ``tahoe put file.txt DIRCAP/subdir/foo.txt``
391 These upload the named file and attach them to a subdirectory of the given
392 root directory, under the name "``foo.txt``". When a directory write-cap is
393 given, you can use either ``/`` (as shown above) or ``:./`` to separate it
394 from the following path. When the source file is named "``-``", the contents
395 are taken from stdin.
397 ``tahoe put file.txt --mutable``
399 Create a new (SDMF) mutable file, fill it with the contents of ``file.txt``,
400 and print the new write-cap to stdout.
402 ``tahoe put file.txt MUTABLE-FILE-WRITECAP``
404 Replace the contents of the given mutable file with the contents of
405 ``file.txt`` and print the same write-cap to stdout.
407 ``tahoe cp file.txt tahoe:uploaded.txt``
409 ``tahoe cp file.txt tahoe:``
411 ``tahoe cp file.txt tahoe:/``
413 ``tahoe cp ./file.txt tahoe:``
415 These upload the local file and add it to your ``tahoe:`` root with the name
418 ``tahoe cp tahoe:uploaded.txt downloaded.txt``
420 ``tahoe cp tahoe:uploaded.txt ./downloaded.txt``
422 ``tahoe cp tahoe:uploaded.txt /tmp/downloaded.txt``
424 ``tahoe cp tahoe:uploaded.txt ~/downloaded.txt``
426 This downloads the named file from your ``tahoe:`` root, and puts the result on
427 your local filesystem.
429 ``tahoe cp tahoe:uploaded.txt fun:stuff.txt``
431 This copies a file from your ``tahoe:`` root to a different directory, set up
432 earlier with "``tahoe add-alias fun DIRCAP``" or "``tahoe create-alias fun``".
434 ``tahoe unlink uploaded.txt``
436 ``tahoe unlink tahoe:uploaded.txt``
438 This unlinks a file from your ``tahoe:`` root (that is, causes there to no
439 longer be an entry ``uploaded.txt`` in the root directory that points to it).
440 Note that this does not delete the file from the grid.
441 For backward compatibility, ``tahoe rm`` is accepted as a synonym for
444 ``tahoe mv uploaded.txt renamed.txt``
446 ``tahoe mv tahoe:uploaded.txt tahoe:renamed.txt``
448 These rename a file within your ``tahoe:`` root directory.
450 ``tahoe mv uploaded.txt fun:``
452 ``tahoe mv tahoe:uploaded.txt fun:``
454 ``tahoe mv tahoe:uploaded.txt fun:uploaded.txt``
456 These move a file from your ``tahoe:`` root directory to the directory
457 set up earlier with "``tahoe add-alias fun DIRCAP``" or
458 "``tahoe create-alias fun``".
460 ``tahoe backup ~ work:backups``
462 This command performs a full versioned backup of every file and directory
463 underneath your "``~``" home directory, placing an immutable timestamped
464 snapshot in e.g. ``work:backups/Archives/2009-02-06_04:00:05Z/`` (note that
465 the timestamp is in UTC, hence the "Z" suffix), and a link to the latest
466 snapshot in work:backups/Latest/ . This command uses a small SQLite database
467 known as the "backupdb", stored in ``~/.tahoe/private/backupdb.sqlite``, to
468 remember which local files have been backed up already, and will avoid
469 uploading files that have already been backed up. It compares timestamps and
470 filesizes when making this comparison. It also re-uses existing directories
471 which have identical contents. This lets it run faster and reduces the
472 number of directories created.
474 If you reconfigure your client node to switch to a different grid, you
475 should delete the stale backupdb.sqlite file, to force "``tahoe backup``"
476 to upload all files to the new grid.
478 ``tahoe backup --exclude=*~ ~ work:backups``
480 Same as above, but this time the backup process will ignore any
481 filename that will end with '~'. ``--exclude`` will accept any standard
482 Unix shell-style wildcards, as implemented by the
483 `Python fnmatch module <http://docs.python.org/library/fnmatch.html>`_.
484 You may give multiple ``--exclude`` options. Please pay attention that
485 the pattern will be matched against any level of the directory tree;
486 it's still impossible to specify absolute path exclusions.
488 ``tahoe backup --exclude-from=/path/to/filename ~ work:backups``
490 ``--exclude-from`` is similar to ``--exclude``, but reads exclusion
491 patterns from ``/path/to/filename``, one per line.
493 ``tahoe backup --exclude-vcs ~ work:backups``
495 This command will ignore any file or directory name known to be used by
496 version control systems to store metadata. The excluded names are:
517 Storage Grid Maintenance
518 ========================
520 ``tahoe manifest tahoe:``
522 ``tahoe manifest --storage-index tahoe:``
524 ``tahoe manifest --verify-cap tahoe:``
526 ``tahoe manifest --repair-cap tahoe:``
528 ``tahoe manifest --raw tahoe:``
530 This performs a recursive walk of the given directory, visiting every file
531 and directory that can be reached from that point. It then emits one line to
532 stdout for each object it encounters.
534 The default behavior is to print the access cap string (like ``URI:CHK:..``
535 or ``URI:DIR2:..``), followed by a space, followed by the full path name.
537 If ``--storage-index`` is added, each line will instead contain the object's
538 storage index. This (string) value is useful to determine which share files
539 (on the server) are associated with this directory tree. The ``--verify-cap``
540 and ``--repair-cap`` options are similar, but emit a verify-cap and repair-cap,
541 respectively. If ``--raw`` is provided instead, the output will be a
542 JSON-encoded dictionary that includes keys for pathnames, storage index
543 strings, and cap strings. The last line of the ``--raw`` output will be a JSON
544 encoded deep-stats dictionary.
546 ``tahoe stats tahoe:``
548 This performs a recursive walk of the given directory, visiting every file
549 and directory that can be reached from that point. It gathers statistics on
550 the sizes of the objects it encounters, and prints a summary to stdout.
556 For a list of all debugging commands, use "``tahoe debug``". For more detailed
557 help on any of these commands, use "``tahoe debug COMMAND --help``".
559 "``tahoe debug find-shares STORAGEINDEX NODEDIRS..``" will look through one or
560 more storage nodes for the share files that are providing storage for the
563 "``tahoe debug catalog-shares NODEDIRS..``" will look through one or more
564 storage nodes and locate every single share they contain. It produces a report
565 on stdout with one line per share, describing what kind of share it is, the
566 storage index, the size of the file is used for, etc. It may be useful to
567 concatenate these reports from all storage hosts and use it to look for
570 "``tahoe debug dump-share SHAREFILE``" will take the name of a single share file
571 (as found by "``tahoe find-shares``") and print a summary of its contents to
572 stdout. This includes a list of leases, summaries of the hash tree, and
573 information from the UEB (URI Extension Block). For mutable file shares, it
574 will describe which version (seqnum and root-hash) is being stored in this
577 "``tahoe debug dump-cap CAP``" will take any Tahoe-LAFS URI and unpack it
578 into separate pieces. The most useful aspect of this command is to reveal the
579 storage index for any given URI. This can be used to locate the share files
580 that are holding the encoded+encrypted data for this file.
582 "``tahoe debug repl``" will launch an interactive Python interpreter in which
583 the Tahoe-LAFS packages and modules are available on ``sys.path`` (e.g. by using
584 '``import allmydata``'). This is most useful from a source tree: it simply sets
585 the PYTHONPATH correctly and runs the Python executable.
587 "``tahoe debug corrupt-share SHAREFILE``" will flip a bit in the given
588 sharefile. This can be used to test the client-side verification/repair code.
589 Obviously, this command should not be used during normal operation.
591 "``tahoe debug trial [OPTIONS] [TESTSUITE]``" will run the tests specified by
592 TESTSUITE (defaulting to the whole Tahoe test suite), using Twisted Trial.