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 results
61 for many ``tahoe`` comands. We recommend, if you use wildcards, to start the
62 path with "``./``", for example "``tahoe cp -r ./* somewhere:``". This
63 prevents the expanded filename from being interpreted as an option or as an
64 alias, allowing filenames that start with a dash or contain colons to be
67 On Windows, a single letter followed by a colon is treated as a drive
68 specification rather than an alias (and is invalid unless a local path is
69 allowed in that context). Wildcards cannot be used to specify multiple
70 filenames to ``tahoe`` on Windows.
75 As of Tahoe-LAFS v1.7.0 (v1.8.0 on Windows), the ``tahoe`` tool supports
76 non-ASCII characters in command lines and output. On Unix, the command-line
77 arguments are assumed to use the character encoding specified by the
78 current locale (usually given by the ``LANG`` environment variable).
80 If a name to be output contains control characters or characters that
81 cannot be represented in the encoding used on your terminal, it will be
82 quoted. The quoting scheme used is similar to `POSIX shell quoting`_: in
83 a "double-quoted" string, backslashes introduce escape sequences (like
84 those in Python strings), but in a 'single-quoted' string all characters
85 stand for themselves. This quoting is only used for output, on all
86 operating systems. Your shell interprets any quoting or escapes used on
89 .. _`POSIX shell quoting`: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
95 "``tahoe create-node [NODEDIR]``" is the basic make-a-new-node command. It
96 creates a new directory and populates it with files that will allow the
97 "``tahoe start``" command to use it later on. This command creates nodes that
98 have client functionality (upload/download files), web API services
99 (controlled by the '[node]web.port' configuration), and storage services
100 (unless ``--no-storage`` is specified).
102 NODEDIR defaults to ``~/.tahoe/`` , and newly-created nodes default to
103 publishing a web server on port 3456 (limited to the loopback interface, at
104 127.0.0.1, to restrict access to other programs on the same host). All of the
105 other "``tahoe``" subcommands use corresponding defaults (with the exception
106 that "``tahoe run``" defaults to running a node in the current directory).
108 "``tahoe create-client [NODEDIR]``" creates a node with no storage service.
109 That is, it behaves like "``tahoe create-node --no-storage [NODEDIR]``".
110 (This is a change from versions prior to v1.6.0.)
112 "``tahoe create-introducer [NODEDIR]``" is used to create the Introducer node.
113 This node provides introduction services and nothing else. When started, this
114 node will produce a ``private/introducer.furl`` file, which should be
115 published to all clients.
117 "``tahoe create-key-generator [NODEDIR]``" is used to create a special
118 "key-generation" service, which allows a client to offload their RSA key
119 generation to a separate process. Since RSA key generation takes several
120 seconds, and must be done each time a directory is created, moving it to a
121 separate process allows the first process (perhaps a busy web-API server) to
122 continue servicing other requests. The key generator exports a FURL that can
123 be copied into a node to enable this functionality.
125 "``tahoe run [NODEDIR]``" will start a previously-created node in the foreground.
127 "``tahoe start [NODEDIR]``" will launch a previously-created node. It will
128 launch the node into the background, using the standard Twisted "``twistd``"
129 daemon-launching tool. On some platforms (including Windows) this command is
130 unable to run a daemon in the background; in that case it behaves in the
131 same way as "``tahoe run``".
133 "``tahoe stop [NODEDIR]``" will shut down a running node.
135 "``tahoe restart [NODEDIR]``" will stop and then restart a running node. This
136 is most often used by developers who have just modified the code and want to
137 start using their changes.
140 Filesystem Manipulation
141 =======================
143 These commands let you exmaine a Tahoe-LAFS filesystem, providing basic
144 list/upload/download/unlink/rename/mkdir functionality. They can be used as
145 primitives by other scripts. Most of these commands are fairly thin wrappers
146 around web-API calls, which are described in `<webapi.rst>`__.
148 By default, all filesystem-manipulation commands look in ``~/.tahoe/`` to
149 figure out which Tahoe-LAFS node they should use. When the CLI command makes
150 web-API calls, it will use ``~/.tahoe/node.url`` for this purpose: a running
151 Tahoe-LAFS node that provides a web-API port will write its URL into this
152 file. If you want to use a node on some other host, just create ``~/.tahoe/``
153 and copy that node's web-API URL into this file, and the CLI commands will
154 contact that node instead of a local one.
156 These commands also use a table of "aliases" to figure out which directory
157 they ought to use a starting point. This is explained in more detail below.
162 As described in `docs/architecture.rst <../architecture.rst>`__, the
163 Tahoe-LAFS distributed filesystem consists of a collection of directories
164 and files, each of which has a "read-cap" or a "write-cap" (also known as
165 a URI). Each directory is simply a table that maps a name to a child file
166 or directory, and this table is turned into a string and stored in a
167 mutable file. The whole set of directory and file "nodes" are connected
168 together into a directed graph.
170 To use this collection of files and directories, you need to choose a
171 starting point: some specific directory that we will refer to as a
172 "starting directory". For a given starting directory, the
173 "``ls [STARTING_DIR]``" command would list the contents of this directory,
174 the "``ls [STARTING_DIR]/dir1``" command would look inside this directory
175 for a child named "``dir1``" and list its contents,
176 "``ls [STARTING_DIR]/dir1/subdir2``" would look two levels deep, etc.
178 Note that there is no real global "root" directory, but instead each
179 starting directory provides a different, possibly overlapping
180 perspective on the graph of files and directories.
182 Each Tahoe-LAFS node remembers a list of starting points, called "aliases",
183 which are short Unicode strings that stand in for a directory read- or
184 write- cap. They are stored (encoded as UTF-8) in the file
185 ``NODEDIR/private/aliases`` . If you use the command line "``tahoe ls``"
186 without any "[STARTING_DIR]" argument, then it will use the default alias,
187 which is ``tahoe:``, therefore "``tahoe ls``" has the same effect as
188 "``tahoe ls tahoe:``". The same goes for the other commands that can
189 reasonably use a default alias: ``get``, ``put``, ``mkdir``, ``mv``, and
192 For backwards compatibility with Tahoe-LAFS v1.0, if the ``tahoe:`` alias
193 is not found in ``~/.tahoe/private/aliases``, the CLI will use the contents
194 of ``~/.tahoe/private/root_dir.cap`` instead. Tahoe-LAFS v1.0 had only a
195 single starting point, and stored it in this ``root_dir.cap`` file, so v1.1
196 and later will use it if necessary. However, once you've set a ``tahoe:``
197 alias with "``tahoe set-alias``", that will override anything in the old
198 ``root_dir.cap`` file.
200 The Tahoe-LAFS CLI commands use the same path syntax as ``scp`` and
201 ``rsync`` -- an optional ``ALIAS:`` prefix, followed by the pathname or
202 filename. Some commands (like "``tahoe cp``") use the lack of an alias to
203 mean that you want to refer to a local file, instead of something from the
204 Tahoe-LAFS filesystem. [TODO] Another way to indicate this is to start
205 the pathname with a dot, slash, or tilde.
207 When you're dealing a single starting directory, the ``tahoe:`` alias is
208 all you need. But when you want to refer to something that isn't yet
209 attached to the graph rooted at that starting directory, you need to
210 refer to it by its capability. The way to do that is either to use its
211 capability directory as an argument on the command line, or to add an
212 alias to it, with the "``tahoe add-alias``" command. Once you've added an
213 alias, you can use that alias as an argument to commands.
215 The best way to get started with Tahoe-LAFS is to create a node, start it,
216 then use the following command to create a new directory and set it as your
219 tahoe create-alias tahoe
221 After that you can use "``tahoe ls tahoe:``" and
222 "``tahoe cp local.txt tahoe:``", and both will refer to the directory that
225 SECURITY NOTE: For users of shared systems
226 ``````````````````````````````````````````
228 Another way to achieve the same effect as the above "``tahoe create-alias``"
231 tahoe add-alias tahoe `tahoe mkdir`
233 However, command-line arguments are visible to other users (through the
234 ``ps`` command or ``/proc`` filesystem, or the Windows Process Explorer tool),
235 so if you are using a Tahoe-LAFS node on a shared host, your login neighbors
236 will be able to see (and capture) any directory caps that you set up with the
237 "``tahoe add-alias``" command.
239 The "``tahoe create-alias``" command avoids this problem by creating a new
240 directory and putting the cap into your aliases file for you. Alternatively,
241 you can edit the ``NODEDIR/private/aliases`` file directly, by adding a line
244 fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
246 By entering the dircap through the editor, the command-line arguments are
247 bypassed, and other users will not be able to see them. Once you've added the
248 alias, no other secrets are passed through the command line, so this
249 vulnerability becomes less significant: they can still see your filenames and
250 other arguments you type there, but not the caps that Tahoe-LAFS uses to permit
251 access to your files and directories.
254 Command Syntax Summary
255 ----------------------
257 ``tahoe add-alias ALIAS[:] DIRCAP``
259 ``tahoe create-alias ALIAS[:]``
261 ``tahoe list-aliases``
269 ``tahoe webopen [PATH]``
271 ``tahoe put [--mutable] [FROMLOCAL|-]``
273 ``tahoe put [--mutable] FROMLOCAL|- TOPATH``
275 ``tahoe put [FROMLOCAL|-] mutable-file-writecap``
277 ``tahoe get FROMPATH [TOLOCAL|-]``
279 ``tahoe cp [-r] FROMPATH TOPATH``
283 ``tahoe mv FROMPATH TOPATH``
285 ``tahoe ln FROMPATH TOPATH``
287 ``tahoe backup FROMLOCAL TOPATH``
289 In these summaries, ``PATH``, ``TOPATH`` or ``FROMPATH`` can be one of:
291 * ``[SUBDIRS/]FILENAME`` for a path relative to the default ``tahoe:`` alias;
292 * ``ALIAS:[SUBDIRS/]FILENAME`` for a path relative to another alias;
293 * ``DIRCAP/[SUBDIRS/]FILENAME`` or ``DIRCAP:./[SUBDIRS/]FILENAME`` for a path
294 relative to a directory cap.
296 See `CLI Command Overview`_ above for information on using wildcards with
297 local paths, and different treatment of colons between Unix and Windows.
299 ``FROMLOCAL`` or ``TOLOCAL`` is a path in the local filesystem.
305 ``tahoe add-alias ALIAS[:] DIRCAP``
307 An example would be::
309 tahoe add-alias fun URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
311 This creates an alias ``fun:`` and configures it to use the given directory
312 cap. Once this is done, "``tahoe ls fun:``" will list the contents of this
313 directory. Use "``tahoe add-alias tahoe DIRCAP``" to set the contents of the
314 default ``tahoe:`` alias.
316 Since Tahoe-LAFS v1.8.2, the alias name can be given with or without the
319 On Windows, the alias should not be a single character, because it would be
320 confused with the drive letter of a local path.
322 ``tahoe create-alias fun``
324 This combines "``tahoe mkdir``" and "``tahoe add-alias``" into a single step.
326 ``tahoe list-aliases``
328 This displays a table of all configured aliases.
332 This creates a new empty unlinked directory, and prints its write-cap to
333 stdout. The new directory is not attached to anything else.
335 ``tahoe mkdir subdir``
337 ``tahoe mkdir /subdir``
339 This creates a new empty directory and attaches it below the root directory
340 of the default ``tahoe:`` alias with the name "``subdir``".
350 All four list the root directory of the default ``tahoe:`` alias.
354 This lists a subdirectory of your filesystem.
358 ``tahoe webopen tahoe:``
360 ``tahoe webopen tahoe:subdir/``
362 ``tahoe webopen subdir/``
364 This uses the python 'webbrowser' module to cause a local web browser to
365 open to the web page for the given directory. This page offers interfaces to
366 add, download, rename, and unlink files and subdirectories in that directory.
367 If no alias or path is given, this command opens the root directory of the
368 default ``tahoe:`` alias.
370 ``tahoe put file.txt``
372 ``tahoe put ./file.txt``
374 ``tahoe put /tmp/file.txt``
376 ``tahoe put ~/file.txt``
378 These upload the local file into the grid, and prints the new read-cap to
379 stdout. The uploaded file is not attached to any directory. All one-argument
380 forms of "``tahoe put``" perform an unlinked upload.
386 These also perform an unlinked upload, but the data to be uploaded is taken
389 ``tahoe put file.txt uploaded.txt``
391 ``tahoe put file.txt tahoe:uploaded.txt``
393 These upload the local file and add it to your ``tahoe:`` root with the name
396 ``tahoe put file.txt subdir/foo.txt``
398 ``tahoe put - subdir/foo.txt``
400 ``tahoe put file.txt tahoe:subdir/foo.txt``
402 ``tahoe put file.txt DIRCAP/foo.txt``
404 ``tahoe put file.txt DIRCAP/subdir/foo.txt``
406 These upload the named file and attach them to a subdirectory of the given
407 root directory, under the name "``foo.txt``". When a directory write-cap is
408 given, you can use either ``/`` (as shown above) or ``:./`` to separate it
409 from the following path. When the source file is named "``-``", the contents
410 are taken from stdin.
412 ``tahoe put file.txt --mutable``
414 Create a new (SDMF) mutable file, fill it with the contents of ``file.txt``,
415 and print the new write-cap to stdout.
417 ``tahoe put file.txt MUTABLE-FILE-WRITECAP``
419 Replace the contents of the given mutable file with the contents of
420 ``file.txt`` and print the same write-cap to stdout.
422 ``tahoe cp file.txt tahoe:uploaded.txt``
424 ``tahoe cp file.txt tahoe:``
426 ``tahoe cp file.txt tahoe:/``
428 ``tahoe cp ./file.txt tahoe:``
430 These upload the local file and add it to your ``tahoe:`` root with the name
433 ``tahoe cp tahoe:uploaded.txt downloaded.txt``
435 ``tahoe cp tahoe:uploaded.txt ./downloaded.txt``
437 ``tahoe cp tahoe:uploaded.txt /tmp/downloaded.txt``
439 ``tahoe cp tahoe:uploaded.txt ~/downloaded.txt``
441 This downloads the named file from your ``tahoe:`` root, and puts the result on
442 your local filesystem.
444 ``tahoe cp tahoe:uploaded.txt fun:stuff.txt``
446 This copies a file from your ``tahoe:`` root to a different directory, set up
447 earlier with "``tahoe add-alias fun DIRCAP``" or "``tahoe create-alias fun``".
449 ``tahoe unlink uploaded.txt``
451 ``tahoe unlink tahoe:uploaded.txt``
453 This unlinks a file from your ``tahoe:`` root (that is, causes there to no
454 longer be an entry ``uploaded.txt`` in the root directory that points to it).
455 Note that this does not delete the file from the grid.
456 For backward compatibility, ``tahoe rm`` is accepted as a synonym for
459 ``tahoe mv uploaded.txt renamed.txt``
461 ``tahoe mv tahoe:uploaded.txt tahoe:renamed.txt``
463 These rename a file within your ``tahoe:`` root directory.
465 ``tahoe mv uploaded.txt fun:``
467 ``tahoe mv tahoe:uploaded.txt fun:``
469 ``tahoe mv tahoe:uploaded.txt fun:uploaded.txt``
471 These move a file from your ``tahoe:`` root directory to the directory
472 set up earlier with "``tahoe add-alias fun DIRCAP``" or
473 "``tahoe create-alias fun``".
475 ``tahoe backup ~ work:backups``
477 This command performs a full versioned backup of every file and directory
478 underneath your "``~``" home directory, placing an immutable timestamped
479 snapshot in e.g. ``work:backups/Archives/2009-02-06_04:00:05Z/`` (note that
480 the timestamp is in UTC, hence the "Z" suffix), and a link to the latest
481 snapshot in work:backups/Latest/ . This command uses a small SQLite database
482 known as the "backupdb", stored in ``~/.tahoe/private/backupdb.sqlite``, to
483 remember which local files have been backed up already, and will avoid
484 uploading files that have already been backed up. It compares timestamps and
485 filesizes when making this comparison. It also re-uses existing directories
486 which have identical contents. This lets it run faster and reduces the
487 number of directories created.
489 If you reconfigure your client node to switch to a different grid, you
490 should delete the stale backupdb.sqlite file, to force "``tahoe backup``"
491 to upload all files to the new grid.
493 ``tahoe backup --exclude=*~ ~ work:backups``
495 Same as above, but this time the backup process will ignore any
496 filename that will end with '~'. ``--exclude`` will accept any standard
497 Unix shell-style wildcards, as implemented by the
498 `Python fnmatch module <http://docs.python.org/library/fnmatch.html>`__.
499 You may give multiple ``--exclude`` options. Please pay attention that
500 the pattern will be matched against any level of the directory tree;
501 it's still impossible to specify absolute path exclusions.
503 ``tahoe backup --exclude-from=/path/to/filename ~ work:backups``
505 ``--exclude-from`` is similar to ``--exclude``, but reads exclusion
506 patterns from ``/path/to/filename``, one per line.
508 ``tahoe backup --exclude-vcs ~ work:backups``
510 This command will ignore any file or directory name known to be used by
511 version control systems to store metadata. The excluded names are:
532 Storage Grid Maintenance
533 ========================
535 ``tahoe manifest tahoe:``
537 ``tahoe manifest --storage-index tahoe:``
539 ``tahoe manifest --verify-cap tahoe:``
541 ``tahoe manifest --repair-cap tahoe:``
543 ``tahoe manifest --raw tahoe:``
545 This performs a recursive walk of the given directory, visiting every file
546 and directory that can be reached from that point. It then emits one line to
547 stdout for each object it encounters.
549 The default behavior is to print the access cap string (like ``URI:CHK:..``
550 or ``URI:DIR2:..``), followed by a space, followed by the full path name.
552 If ``--storage-index`` is added, each line will instead contain the object's
553 storage index. This (string) value is useful to determine which share files
554 (on the server) are associated with this directory tree. The ``--verify-cap``
555 and ``--repair-cap`` options are similar, but emit a verify-cap and repair-cap,
556 respectively. If ``--raw`` is provided instead, the output will be a
557 JSON-encoded dictionary that includes keys for pathnames, storage index
558 strings, and cap strings. The last line of the ``--raw`` output will be a JSON
559 encoded deep-stats dictionary.
561 ``tahoe stats tahoe:``
563 This performs a recursive walk of the given directory, visiting every file
564 and directory that can be reached from that point. It gathers statistics on
565 the sizes of the objects it encounters, and prints a summary to stdout.
571 For a list of all debugging commands, use "``tahoe debug``". For more detailed
572 help on any of these commands, use "``tahoe debug COMMAND --help``".
574 "``tahoe debug find-shares STORAGEINDEX NODEDIRS..``" will look through one or
575 more storage nodes for the share files that are providing storage for the
578 "``tahoe debug catalog-shares NODEDIRS..``" will look through one or more
579 storage nodes and locate every single share they contain. It produces a report
580 on stdout with one line per share, describing what kind of share it is, the
581 storage index, the size of the file is used for, etc. It may be useful to
582 concatenate these reports from all storage hosts and use it to look for
585 "``tahoe debug dump-share SHAREFILE``" will take the name of a single share file
586 (as found by "``tahoe find-shares``") and print a summary of its contents to
587 stdout. This includes a list of leases, summaries of the hash tree, and
588 information from the UEB (URI Extension Block). For mutable file shares, it
589 will describe which version (seqnum and root-hash) is being stored in this
592 "``tahoe debug dump-cap CAP``" will take any Tahoe-LAFS URI and unpack it
593 into separate pieces. The most useful aspect of this command is to reveal the
594 storage index for any given URI. This can be used to locate the share files
595 that are holding the encoded+encrypted data for this file.
597 "``tahoe debug repl``" will launch an interactive Python interpreter in which
598 the Tahoe-LAFS packages and modules are available on ``sys.path`` (e.g. by using
599 '``import allmydata``'). This is most useful from a source tree: it simply sets
600 the PYTHONPATH correctly and runs the Python executable.
602 "``tahoe debug corrupt-share SHAREFILE``" will flip a bit in the given
603 sharefile. This can be used to test the client-side verification/repair code.
604 Obviously, this command should not be used during normal operation.
606 "``tahoe debug trial [OPTIONS] [TESTSUITE]``" will run the tests specified by
607 TESTSUITE (defaulting to the whole Tahoe test suite), using Twisted Trial.