Troubleshooting

Answers to the problems people run into most.

I forgot the administrator password

docker exec -it thirtyfile thirtyfile reset-password admin

Type the new password when asked, so it doesn't stay in your shell history. This also switches the account back on if it was disabled.

docker exec thirtyfile sh doesn't work

The image contains only ThirtyFile itself: no shell and no other programs, which leaves less to keep up to date. Commands of ThirtyFile work as shown in these guides, such as docker exec thirtyfile thirtyfile reset-password …. To look at the files, use the data and storage folders on the host, or docker cp.

An administrator lost their phone and recovery codes

Another administrator can reset it under Control panel › Users. If there is none, turn it off on the server:

docker exec thirtyfile thirtyfile reset-two-factor admin

Share links start with http://127.0.0.1:8080

Set the address people use under Control panel › General › Site URL.

I am signed out right after signing in

THIRTYFILE_SECURE_COOKIE is true, but the site is opened with http://. Open it with https://, or set it to false if you don't use HTTPS.

Everyone gets "too many failed attempts"

Behind a reverse proxy, THIRTYFILE_TRUST_PROXY must be true (or list the proxy's address when it runs on another computer), and the proxy must pass on the visitor's address as in the examples. Otherwise everyone counts as one visitor.

The block lifts by itself after 15 minutes.

After many wrong passwords for one account, from any address, each further attempt for that account has to wait a little longer, up to a minute. The account itself is never locked.

Large uploads fail

For error 413, check both THIRTYFILE_MAX_UPLOAD_MB and the reverse proxy's request size limit. The browser uploader uses 32 MB chunks; allow at least 64 MB per request as in the nginx example. WebDAV sends a whole file in one request and needs a request limit large enough for that file; see WebDAV troubleshooting. Also check the space's quota and free storage.

"Permission denied" when starting

On start, the container gives its folders to user 1000. This can't work in two cases:

• The container is started with --user. Make the folders writable for that user: sudo chown -R 1000:1000 /srv/thirtyfile, with the user's number instead of 1000.
• A folder is on a network share that doesn't let the owner be changed. The log says Can't give the folder … to user. Set THIRTYFILE_RUN_AS to the user and group that own the files on the share, for example 1026:100.

Looking at the log

docker logs --tail 100 thirtyfile

Checking that it is running

http://files.example.com:8080/api/health answers with the state of the server: "status": "ok", or "degraded" when /data or /storage has less than 1 GB free, a storage location can't be reached, or a background task stopped on an error in the last day and was started again (the log says which). It also lists the free and total space of both folders and whether each storage location is ok or offline, so a monitoring tool can warn you before the disk is full. Uploads and files sent over WebDAV arrive in /data first, so they are refused when they would leave it less than 64 MB free. Configure the monitor to inspect the JSON status: degraded health still returns HTTP 200. A database check failure returns HTTP 503 with "status": "error". Docker's health probe accepts HTTP 200, so low disk space or an offline location does not by itself restart the container. The log warns about degraded health at most once an hour.

These details are given only to a request made on the server itself, not through a reverse proxy, and to a signed-in administrator. Anyone else gets the status alone.

Anyone can ask for it, so it doesn't say which version runs: that would tell a stranger which release to look up for known problems. Signed in, you find the version on the last line of the account menu, such as ThirtyFile 0.5.0. Administrators also see it at the bottom right of the Control panel, linked to that release's notes. On the server, docker exec thirtyfile thirtyfile --version prints it.

Checking the stored files

To see whether every file in the database is still in its storage location, and whether a location holds files the database doesn't know (left behind by hand, for example), run:

docker exec thirtyfile thirtyfile check

It lists missing files, files with the wrong size and unknown files, for every storage location, and exits with 1 when something is wrong. Unknown files are never deleted. With --verify it also reads every file back and compares its content with its fingerprint (SHA-256), which takes as long as reading everything. Folder spaces aren't part of it: their files are ordinary files on the disk.

The fingerprint is computed while a file is being uploaded, also across a paused upload and a restart of ThirtyFile, so finishing a large upload doesn't read the whole file a second time. --verify is what tells you whether the disk still holds the same content later.

How your files are protected

• Passwords, app passwords, recovery codes and sign-in sessions are stored in a form that cannot be read back.
• Two-factor sign-in can be required for everyone who signs in with a password.
• App passwords only reach files, never the account or the Control panel. See Your account.
• Uploaded files cannot run scripts on the site.
• A share link stops working when the person who made it loses access to the item.
• Repeated wrong passwords and app passwords are blocked for 15 minutes.

Still stuck?

Report the problem on GitHub, with what you did, what you expected and what happened instead.