# When something is broken > Source: https://www.allsweb.com/sixpanel/docs/troubleshooting > Markdown for agents: https://www.allsweb.com/sixpanel/docs/troubleshooting.md > Publisher: AllsWeb (www.allsweb.com) Part of: SixPanel documentation **What this page is for:** find the cause, in the order these things actually happen, and fix it with one command or one panel button. **You need** - SSH access to the server, as root or with `sudo`. Every fix here is a command you can paste, because the panel is often the thing that is broken. ## Start here **Step 0 — if the panel opens:** go to **Server → Health**. It runs over thirty checks and every failure carries its own fix. **Step 1 — if the panel does not open:** run the check that needs nothing from the panel. ``` sudo sixpanel doctor --self ``` It reports the services, the settings file, the panel port, the panel certificate, free disk, and which services are not running. Each failure names the next command. Then find your symptom below. --- ## The panel will not open **What it means:** four causes, in the order they occur. Work down the list. **1. The port is closed at your hosting provider.** This is the number one cause on AWS, Oracle and Google Cloud. Nothing on the server can detect it — the packets never arrive. ``` sudo sixpanel server firewall ``` Open those three ports in your provider's firewall or security group. See [Firewall and ports](https://www.allsweb.com/sixpanel/docs/firewall). **2. You are opening the address without its secret code.** The panel answers only at `https://IP:PORT/SECRET-CODE`. The bare address is a blank "not found" page on purpose, so scanners cannot find your login. ``` sudo sixpanel info # the full link, the admin user, and what is running sudo sixpanel url # the link on its own sudo sixpanel open # the link, large, with a QR code for your phone ``` **3. The panel has its own domain, and that domain or its certificate is broken.** Once a panel domain has a certificate, the address with the IP and the port stops working — so the web interface cannot be used to repair the web interface. The way back is always SSH: ``` sudo sixpanel ssl status sudo sixpanel domain none sudo sixpanel info ``` `sixpanel domain none` puts the panel back on `https://IP:PORT/CODE`. It writes the state before it touches the web server, so it still rescues a server whose web server is broken. **4. The panel service is not running.** ``` sudo sixpanel service status panel sudo sixpanel service start panel sudo sixpanel logs panel -n 50 ``` If the log shows the panel's own code failing to load rather than a configuration problem, the server's Node.js version is the thing to check — something changed it out from under the panel. One command puts it back: ``` sudo bash /opt/sixpanel/installer/install.sh --node-only ``` See [Update SixPanel itself](https://www.allsweb.com/sixpanel/docs/update-sixpanel) for why that matters. **A certificate warning is not a fault.** Reaching the panel by IP address always warns, because the certificate is for a domain. Click through it (Advanced → proceed). **Forgot the username:** ``` sudo sixpanel username ``` The name you type on the login page was generated at install — it is `admin` plus a few random characters, not plain `admin`. This prints it, together with the panel link. **Forgot the password:** ``` sudo sixpanel password reset ``` It says what it will change, asks you to confirm, then prints a new password. The old one is stored as a one-way hash and cannot be recovered — if you had it written down, this throws that copy away. To choose your own without it landing in your shell history: ``` read -rs NEW && printf '%s' "$NEW" | sudo sixpanel password --stdin ``` **Lost the phone with the 6-digit codes:** ``` sudo sixpanel 2fa off ``` It forgets the phone you set up. Log in with your username and password as usual, and the panel shows a fresh QR code to scan with the new phone. If you have no phone at that moment, that screen also offers **Not now — continue without two-factor login** — it opens the panel on your password alone, is written to your activity log, and leaves the Security page showing two-factor as off with the enrol button there. There is no command to enrol a new phone, because enrolling has to show you a QR code. **The login page loads and refuses a password you know is right:** after enough failed tries the panel stops accepting logins from your address. Two counters do that — 20 wrong passwords or 5 wrong codes lock the address for 30 minutes, and 30 login attempts in 15 minutes trip a flood shield as well. The second one is held in the panel's memory, so there is nothing in any file to explain it. ``` sudo sixpanel unlock sudo sixpanel unlock ``` The first lists what is locked, with how long is left on each, and changes nothing. The second lets that address log in again, straight away. Use `sudo sixpanel unlock all` if you do not know which address you are on. Your password, your 6-digit code, the address list and the secret entry code are all left exactly as they are. **The login page loads but refuses you, and you once set up a login IP allowlist:** your internet address has changed, so the list no longer has you on it. Nothing inside the panel can help, because the list is what keeps you out of the panel. ``` sudo sixpanel allowlist sudo sixpanel allowlist clear ``` The first prints the list. The second empties it, which switches the feature off, so login is accepted from anywhere again. Your password, your 6-digit code and the secret entry code stay as they are. Add your new address afterwards — see [Security](https://www.allsweb.com/sixpanel/docs/security). *If it persists:* send us the support bundle (bottom of this page). --- ## The site is down, or every page shows a 500 error **What it means:** either the app was never finished, an update broke it, or a service is not running. Look first: ``` sudo sixpanel doctor sudo sixpanel service status ``` **Right after a fresh install:** if you chose the browser wizard, 6ammart's own installer was not finished, so the database is still empty. Open `https://YOUR-DOMAIN/install`, complete every step, then press the finish button on the **Deploys** page. See [Install your 6ammart code](https://www.allsweb.com/sixpanel/docs/install-app). **Right after an update:** put the code back. ``` sudo sixpanel deploy history sudo sixpanel deploy rollback last ``` > **A restore cannot be undone.** It writes the snapshot over your live > database and files. Every order, user and upload made since that snapshot was > taken is lost. Take a fresh backup first — `sudo sixpanel backup run full` — > so today's data still exists if the restore is not the answer. Full steps and > the panel version: see [Backups](https://www.allsweb.com/sixpanel/docs/backups). ``` sudo sixpanel backup list sudo sixpanel backup restore SNAPSHOT_ID ``` **Neither one reverses database changes.** If an update changed the database and the site is still broken after a rollback, restore a backup taken *before* the update instead of chasing the code. **A service is not running:** ``` sudo sixpanel service start all sudo sixpanel logs app -n 100 ``` **The web server keeps failing to start:** ``` sudo sixpanel logs nginx -n 50 ``` The message names the file and the line. Broken web-server files usually come from hand editing. Do not repair them by hand — send us the support bundle. *If it persists:* send us the support bundle. --- ## The services are all green and the site still answers nothing **What it means:** the machine is fine and the **application** is not. This is its own symptom because everything you would normally look at is green. The health check **The app answers requests** is the one that catches it. The panel dials your project's own hostname on this server — with the real name in the request — and reports what `/api/v1/config` gives back. That is the first call every 6ammart phone app makes, so it is the difference between "the server is running" and "customers can order". If that check is red with a **404 on every address**, the usual cause is a copy of the code that is not complete — an update-only package installed as if it were a full one, so the app binds classes whose files are not there. Read the newest lines on the project's **Logs** page; then re-install the admin app from the full source on the **Deploys** page. If it is red with a **500**, the newest entry in the application log names the reason. Start there rather than restarting things. --- ## Order times and reports are wrong by a few hours **What it means:** 6ammart keeps the shop's timezone in its own admin panel and applies it on every request. If that value is a name this server's PHP does not know, PHP falls back to UTC with only a notice — so every order time, report boundary and scheduled task is out by the offset while every page renders perfectly normally. The health check **Shop timezone** reads the stored value and says whether the server really has it. Two fixes, either is fine: - set a current timezone name in 6ammart's own admin panel (for example `Asia/Kolkata` rather than the older `Asia/Calcutta`); or - install the legacy timezone names on the server: ``` sudo apt-get install -y tzdata-legacy ``` Fresh installs already have the second one. This bites servers installed before it was added, and datasets carrying old names. --- ## SSL failed, or the padlock is missing **What it means:** the certificate could not be issued, almost always because of DNS or a closed port 80. See what the server actually holds: ``` sudo sixpanel ssl status ``` For each certificate it prints the domain, whether it is a real Let's Encrypt certificate or a self-signed one, the issuer, the **days left**, which site uses it and where it is. It reads the files directly, so it answers even when the panel is unreachable. Self-signed is **normal** in two places: the panel before you give it a domain, and a Cloudflare-proxied name issued without a Cloudflare token, running SSL/TLS mode **Full**. It is a problem only where you expected a real one. Issuing and renewing happen in the panel — **Domain & SSL** → **Get free SSL** — because it checks DNS, writes the web-server file and reloads it as one operation, and undoes all of it if the certificate does not arrive. The job log names the failing step: - **"does not resolve to …"** — the A record does not point at this server yet. Fix DNS, wait a few minutes, press **Re-check DNS**, try again. - **Cloudflare error 526** — the zone is on **Full (strict)** but your origin certificate is self-signed. Either press **Get free SSL** again (it upgrades to a real certificate when the check can pass), or set the zone's SSL/TLS mode to **Full**. Connecting a Cloudflare token removes this case entirely: the panel then proves the name over DNS and always gets a real certificate. - **A name the panel refused** — it would sit more than one level below your Cloudflare domain, where Cloudflare's free certificate does not reach. Use the spelling the panel offered. - **Timeouts from the certificate tool** — when the panel is using the port-80 method, port **80** must be reachable. Behind Cloudflare it must be open to Cloudflare's addresses; see [Firewall and ports](https://www.allsweb.com/sixpanel/docs/firewall). - **"too many certificates"** — a Let's Encrypt limit of 5 per week for the same set of names. Wait, or use a slightly different set. Renewal is automatic and runs daily. Each certificate reloads the web server on its own as it renews, so one certificate with a problem can never freeze the others. *If it persists:* send us the support bundle. --- ## A deploy failed, or a git push does nothing **What it means:** either the deploy itself stopped on a step, or the push never reached the server, or the server cannot read the repository. ``` sudo sixpanel deploy history sudo sixpanel deploy preview ``` `preview` changes nothing — it shows what would be pulled. On an install that is not a git checkout it says so and stops, which is an answer, not an error. **"could not read the repository"** — the server has no read access of its own. The token you typed at install time was deliberately not kept. Open **Deploys** → the read-access card, create the deploy key and paste it into your repository's **Deploy keys** with write access off. See section 5 of [Put your code in a git repository](https://www.allsweb.com/sixpanel/docs/put-your-code-in-git). **Push-to-deploy returns 401** — it is the secret, almost every time. Each repository has its own webhook and its own secret: the admin app and the customer website are separate, and pasting one secret into the other's webhook fails exactly like this. Press **Replace the secret** on the right block in the panel, paste the new secret into your git host, then use **Redeliver** on a recent delivery. A 401 has only three other causes, and none of them is the content type: - that repository's webhook is switched off in the panel; - your git host sent no signature header at all, or a damaged one (GitHub sends `X-Hub-Signature-256`, Gitea sends `X-Gitea-Signature`); - the request arrived with an empty body. Check the address too. Copy it from the panel rather than typing it: the admin app is `https://YOUR-DOMAIN/.stack/webhook/admin` and the customer website is `https://YOUR-DOMAIN/.stack/webhook/react`, with no slash at the end. The web server matches these paths exactly, so any other spelling never reaches the panel and answers something other than 401. **Push looks green but nothing happens** — the push landed on the other repository's webhook address, or it went to a branch that automatic deploys are not watching, or a deploy was already running, or the job itself failed after the push was accepted. Check **Deploys** → history, and **Security** → the activity log, which records the ignored deliveries and why. *If it persists:* send us the support bundle. --- ## The disk is full **What it means:** a full disk stops the site and the database, and it stops the panel too — so clean it from SSH. ``` sudo sixpanel disk ``` Then: ``` sudo sixpanel prune ``` `prune` trims the system journal to the last seven days, clears the package manager's cache and empties this project's application log. It asks first and prints free space before and after. It can never remove a database, an upload or a backup. If backups are the biggest line, shorten how many are kept (**Backups** → custom schedule), or move the backup storage off this server. See [Backups](https://www.allsweb.com/sixpanel/docs/backups). **Server → Health** warns before this becomes an outage, and **Server → Resources** shows where the space went with a tick-list of safe things to remove. Take that warning seriously. *If it persists:* send us the support bundle. --- ## The server is slow **What it means:** usually not enough memory, or one heavy database query. ``` sudo sixpanel top sudo sixpanel db slow ``` `top` shows memory, tasks and CPU time per service, plus the host's load and free disk. `db slow` lists the slowest recorded queries. Common answers: - **Check the Database page first.** If its **Speed** card says some measured indexes are missing, press the button and re-test. Your project keeps shortcuts that let it find orders and products without reading through every row, and depending on where your 6ammart code came from some of them may never have been created. A project works perfectly well without them until it has enough orders for it to matter — which is exactly when it starts feeling slow, with nothing looking broken. Safe to press while the site is busy; nothing is deleted. - Memory near its ceiling: give the server more RAM, then **Settings** → **Auto-tune** → **Apply tuning**. - Several projects on a small server: see [More than one project on this server](https://www.allsweb.com/sixpanel/docs/multiple-projects) for sizing. - Peaks of junk traffic: put the domain behind Cloudflare and close the rest at your provider's edge. See [Firewall and ports](https://www.allsweb.com/sixpanel/docs/firewall). *If it persists:* send us the support bundle — it carries the numbers we need. --- ## Emails are not sending, or orders are stuck **What it means:** the queue worker does this work. When it stops, mail and order processing stop with it. ``` sudo sixpanel logs queue -n 100 sudo sixpanel service restart queue ``` That restart is the fix most of the time, and it is harmless. Two things worth knowing: - Your shop's own mail settings live **inside the 6ammart admin panel**, not in this panel. This panel's **Settings** → **Email alerts** only sends *you* alerts about the server. - Timed jobs run through the **scheduler**. The project's **Advanced → Cron** tab shows whether it is alive. *If it persists:* send us the support bundle. --- ## I changed a setting and nothing happened **What it means:** the application keeps its configuration in a cache on disk, and the workers hold their own copy. ``` sudo sixpanel cache clear ``` That clears the cached configuration, routes and views, rebuilds the fast ones and restarts the PHP, queue and scheduler services. If the behaviour is still the old one afterwards, it was never a cache — run `sudo sixpanel doctor`. A second cause worth knowing: several of 6ammart's settings live in its **own admin panel and its database**, not in the `.env` file — mail, timezone, payment gateways among them. Editing the file does nothing for those. The **App .env** page says so at the top of the affected settings. --- ## Live updates are dead Turn them on again from the project's **Advanced → Services** tab, and read the websocket log: ``` sudo sixpanel logs reverb -n 100 ``` Full steps and the Cloudflare settings: see [Live order updates](https://www.allsweb.com/sixpanel/docs/live-updates). --- ## A helper says the panel refuses them **What it means:** they are signed in with a login that is not allowed to do that, and that is working as designed. - *the read-only demo — it can look at everything and change nothing* — they used the demo link. Send them a temporary login instead. - *temporary logins cannot …* — a temporary login may run the site but may not change who gets in, take data off the server, or touch your secrets. Do that one step yourself. The full list of what each login can and cannot do, and how to end either of them at once: [Let someone else in](https://www.allsweb.com/sixpanel/docs/share-access). To throw everyone out from SSH: ``` sudo sixpanel temp-login revoke-all sudo sixpanel demo off ``` Your own login is untouched by both. --- ## The backup test says FAILED **What it means:** the backup finished, but loading it back produced a database that is not complete. Until this passes, do not rely on those backups. Run a fresh full backup and test it again on the **Backups** page. Full steps and the usual causes: [Backups](https://www.allsweb.com/sixpanel/docs/backups). --- ## A backup fails with "repository is already locked" **What it means:** an earlier run stopped in the middle and left a marker behind. Wait one minute and run it again: ``` sudo sixpanel backup run full ``` If it keeps saying this, send us the support bundle. Clearing that marker by hand is a root-level repair and we would rather do it with you. --- ## A page fails with "Table … doesn't exist" **What it means:** the database is older than the code — usually a dump imported from an earlier 6ammart, or a vendor installer that marked some database changes as done without creating their tables. Open **Database** for that project and run the pending database changes. Or over SSH: ``` sudo sixpanel db migrate ``` --- ## Files: uploads stopped working after I copied something in by hand **What it means:** ownership. Your project's PHP runs as its own Linux user — `six-default` for the first project, `six-` for the others — not as `www-data` and not as `root`. Files left owned by somebody else are readable but not writable, so pages render and then the app fails the moment it writes. ``` sudo chown -R six-default:six-default /var/www/admin/storage/app/public ``` See the hand-import section of [Move an existing site here](https://www.allsweb.com/sixpanel/docs/move-existing-site). **If you moved a folder onto a second disk**, there is a second thing to do. PHP is confined to writing inside `/var/www` and a short list of server folders, so if you linked, say, `/var/www/admin/storage` to somewhere like `/mnt/media`, that new location has to be added to the list. SixPanel works it out for itself — it follows the link and adds wherever it really points — but only when it next looks, which is when a project is created or deleted, or when the panel restarts. After moving a folder by hand, tell it to look now: ``` sudo systemctl restart sixpanel ``` Uploads work again immediately afterwards. Nothing else on the server is touched, and your sites keep serving while it happens. --- ## An image will not save, and nothing says why **What it looks like:** you pick a product photo or a store banner, press save, and the page comes back as if nothing happened. A smaller photo works. Nothing appears in any log, because from the server's point of view nothing went wrong. **What it is:** 6ammart's own size rule, not your server's. The number is in your 6ammart code, at `app/Library/Constant.php`: ``` grep 'const MAX_FILE_SIZE' /var/www/admin/app/Library/Constant.php ``` - **2** on the CodeCanyon 6ammart code as it ships — so images over **2 MB** are refused. - **5** on our optimised build — so images over **5 MB** are refused. Several forms carry a fixed 2 MB rule of their own regardless of that constant, and at least one refusal message says *"Image must be less than 2mb"* even where the real limit is 5 MB. So the message is a reason, not a measurement. **Your server is not what refuses it.** SixPanel allows **100 MB per file and 128 MB per request**, at both the web server and PHP. Measured on a real install: a 50 MB upload reaches the application intact. Raising anything in nginx or `php.ini` will not move this ceiling, because the ceiling is not there. **What to do** - **Resize the picture.** This is the real answer nine times out of ten. A product photo above about 500 KB makes your storefront slower for every shopper who loads it, on every phone, forever. 6ammart's limit is protecting you. - **Or raise 6ammart's own number**, if you genuinely need bigger files — change `MAX_FILE_SIZE` in `app/Library/Constant.php`. It is a change to your application code, so keep a note of it: a 6ammart update from CodeCanyon replaces that file and puts the old number back. **To see what your server really allows**, open **SixPreflight** from the panel — it reports the upload limit the server is enforcing, which is the number to check if a file is refused *before* it ever reaches 6ammart (you would see a "413" error page rather than a form that quietly comes back). --- ## The Files tab only shows the app and the website That is intended, not a fault. The file manager is fenced to one project's code. SixPanel's own folders, the database files and the server's configuration are deliberately out of reach, so a wrong click cannot break the machine. Server-level files are edited over SSH. For the same reason, extracting an archive is refused when it contains a symbolic link, a `.git` entry, or a `..` path. Repackage it without those. --- ## The installer refuses my server The installer checks the server before it downloads anything, and stops with the exact reason: - **Operating system** — **Ubuntu 26.04 LTS, Ubuntu 24.04 LTS or Debian 13 (trixie).** Not 22.04, not Debian 12 (refused by name — use Debian 13 instead). Rebuild the server with one of those images; there is no flag that relaxes this. - **Root** — become root first: `sudo su root`. - **A fresh server** — no other control panel (aaPanel, CloudPanel, cPanel, Plesk), no existing install, and ports 80 and 443 free. It prints exactly what it found. `--force` skips **only** this check; it does not relax the operating-system, root or memory checks. - **Memory** — at least about 1.2 GB, and 2 GB or more is recommended. - **Processor type** — x86_64 or arm64, and the release you are installing must have been built for it. A **checksum mismatch** means the download did not match what was expected and nothing was installed. Re-run the installer; if it happens again, contact support. --- ## Still stuck? Send one file ``` sudo sixpanel support-bundle ``` It writes a single `.tgz` file — by default into `/root/` — and prints the path. It contains versions, the health report, service states, disk usage, the service configuration and the last 500 lines of every log. What is taken out before it is written: the SixPanel settings file is reduced to key names only, with every value replaced; the panel's own state file (which holds the password hash and the backup password) is **not** included at all; and the secret code from your panel link plus common password-looking values are masked in the collected logs. Send us that file with one sentence about what you were doing. Most support threads finish in one round trip. Two more places worth a look before you write: - the project's **Logs** page, where the newest error usually explains itself in one line; - **Security** → **Activity log**, which shows what changed recently, and from which address.