[{"data":1,"prerenderedAt":7778},["ShallowReactive",2],{"page-\u002Fbyodt-cloud\u002Ftroubleshooting":3,"navigation":7457},{"id":4,"title":5,"body":6,"description":7443,"extension":7444,"meta":7445,"navigation":7452,"path":7453,"seo":7454,"stem":7455,"__hash__":7456},"docs\u002F02.byodt-cloud\u002F05.troubleshooting.md","Troubleshooting the BYODt Deployment",{"type":7,"value":8,"toc":7250},"minimark",[9,13,17,20,25,28,58,67,83,110,112,116,123,131,145,151,166,173,181,187,194,199,203,218,224,231,245,249,257,269,275,282,305,310,319,322,328,335,361,381,391,403,449,457,466,489,495,502,505,536,561,567,574,584,615,629,635,642,670,675,681,688,709,724,730,736,771,792,817,831,835,840,845,853,859,867,874,880,888,926,931,974,981,987,994,1008,1013,1018,1048,1054,1060,1067,1073,1091,1114,1120,1127,1138,1149,1154,1163,1170,1176,1188,1203,1212,1221,1231,1238,1250,1255,1260,1269,1272,1278,1285,1306,1317,1323,1329,1338,1344,1350,1357,1366,1382,1389,1395,1403,1414,1417,1432,1447,1452,1501,1515,1517,1521,1535,1541,1548,1567,1582,1588,1595,1600,1614,1624,1636,1651,1662,1668,1675,1683,1692,1698,1705,1713,1719,1726,1737,1753,1762,1768,1775,1780,1788,1794,1801,1813,1847,1853,1860,1874,1879,1888,1894,1901,1908,1917,1925,1931,1938,1944,1964,2002,2018,2031,2037,2044,2053,2058,2064,2071,2086,2107,2112,2134,2149,2155,2172,2178,2194,2206,2212,2224,2240,2251,2257,2269,2308,2323,2329,2336,2343,2354,2359,2365,2372,2386,2392,2404,2412,2428,2434,2441,2449,2469,2475,2482,2495,2509,2515,2522,2531,2550,2556,2563,2589,2601,2607,2614,2619,2625,2632,2639,2646,2652,2659,2668,2683,2689,2701,2712,2721,2733,2742,2748,2755,2768,2780,2786,2793,2810,2826,2832,2839,2854,2860,2867,2876,2888,2897,2900,2906,2913,2923,2928,2934,2942,2952,2960,2966,2973,2982,2995,3005,3011,3025,3043,3045,3049,3053,3062,3068,3073,3088,3094,3098,3133,3138,3194,3198,3268,3277,3289,3318,3326,3341,3358,3371,3378,3386,3392,3405,3423,3432,3443,3472,3584,3606,3612,3620,3628,3640,3648,3658,3664,3671,3682,3697,3703,3710,3715,3720,3725,3743,3752,3757,3771,3777,3785,3790,3795,3809,3814,3816,3819,3831,3836,3906,3924,3930,3939,3956,3962,3982,4155,4158,4197,4203,4210,4224,4243,4249,4256,4272,4282,4288,4295,4301,4318,4347,4363,4369,4376,4386,4410,4416,4422,4430,4453,4459,4466,4471,4484,4493,4502,4507,4514,4524,4529,4562,4567,4572,4588,4595,4608,4618,4621,4628,4656,4664,4679,4682,4699,4711,4713,4717,4725,4735,4740,4746,4757,4762,4766,4775,4778,4787,4790,4796,4804,4810,4815,4819,4833,4839,4845,4850,4855,4870,4876,4881,4885,4898,4901,4910,4916,4921,4925,4939,4943,4954,4957,4967,4972,4976,4984,4987,4989,4993,4999,5004,5008,5020,5023,5027,5032,5036,5050,5060,5064,5069,5073,5088,5093,5099,5107,5124,5128,5136,5154,5160,5172,5187,5189,5193,5199,5206,5210,5218,5226,5232,5237,5245,5254,5266,5286,5301,5307,5314,5319,5327,5333,5338,5343,5352,5359,5364,5369,5375,5380,5385,5391,5398,5410,5425,5431,5438,5447,5452,5458,5465,5473,5481,5487,5494,5499,5503,5517,5521,5526,5531,5539,5545,5552,5560,5562,5566,5570,5573,5645,5651,5658,5663,5683,5698,5704,5712,5720,5734,5741,5747,5754,5762,5769,5775,5780,5793,5799,5804,5814,5820,5825,5830,5834,5839,5847,5853,5860,5877,5896,5902,5909,5914,5922,5928,5935,5940,5959,5966,5972,5979,5987,5997,6003,6010,6015,6032,6037,6043,6050,6059,6064,6070,6077,6082,6092,6098,6105,6110,6124,6130,6137,6142,6150,6156,6163,6171,6185,6191,6198,6203,6212,6218,6225,6234,6245,6251,6258,6263,6270,6274,6285,6293,6302,6305,6311,6318,6331,6338,6349,6371,6397,6399,6403,6409,6416,6421,6441,6447,6452,6464,6470,6475,6486,6490,6495,6499,6507,6510,6516,6523,6528,6538,6545,6550,6564,6575,6589,6599,6605,6612,6619,6629,6634,6638,6668,6678,6684,6689,6754,6760,6767,6772,6777,6783,6796,6802,6809,6811,6818,6823,6828,6834,6841,6848,6856,6863,6869,6876,6881,6889,6896,6900,6905,6909,6917,6920,6922,6926,6934,6941,6945,6950,6964,6968,6973,6989,6996,7000,7005,7014,7022,7025,7030,7045,7047,7051,7062,7067,7072,7080,7094,7098,7103,7112,7121,7126,7132,7138,7153,7159,7161,7165,7168,7192,7195,7217,7221,7246],[10,11,5],"h1",{"id":12},"troubleshooting-the-byodt-deployment",[14,15,16],"p",{},"Every entry below is a real state this deployment can report, with the message you will actually see. Find your symptom, read the cause, apply the fix.",[18,19],"hr",{},[21,22,24],"h2",{"id":23},"first-gather-the-facts","First, gather the facts",[14,26,27],{},"Three commands and one page answer most questions:",[29,30,35],"pre",{"className":31,"code":32,"language":33,"meta":34,"style":34},"language-sh shiki shiki-themes github-light github-dark-dimmed",".\u002Fbyodt status                # which services are running, and their health\n.\u002Fbyodt logs console-init     # what the first-run one-shot did\n.\u002Fbyodt logs platform         # what the platform is doing\n","sh","",[36,37,38,46,52],"code",{"__ignoreMap":34},[39,40,43],"span",{"class":41,"line":42},"line",1,[39,44,45],{},".\u002Fbyodt status                # which services are running, and their health\n",[39,47,49],{"class":41,"line":48},2,[39,50,51],{},".\u002Fbyodt logs console-init     # what the first-run one-shot did\n",[39,53,55],{"class":41,"line":54},3,[39,56,57],{},".\u002Fbyodt logs platform         # what the platform is doing\n",[29,59,61],{"className":31,"code":60,"language":33,"meta":34,"style":34},".\u002Fbyodt console               # open the operator console\n",[36,62,63],{"__ignoreMap":34},[39,64,65],{"class":41,"line":42},[39,66,60],{},[14,68,69,70,74,75,78,79,82],{},"The console is the fastest diagnosis. It reports a verdict — ",[71,72,73],"strong",{},"Healthy",", ",[71,76,77],{},"Degraded",", or ",[71,80,81],{},"Fault"," — plus a banner for each specific problem, and it keeps working while the rest of the deployment is down. Read its banners before anything else.",[14,84,85,86,89,90,93,94,97,98,101,102,105,106,109],{},"A note on reading ",[36,87,88],{},".\u002Fbyodt status",": ",[36,91,92],{},"console-init"," is a one-shot, so plain ",[36,95,96],{},"status"," does not list it once it has exited. Run ",[36,99,100],{},".\u002Fbyodt status -a"," to see it. ",[71,103,104],{},"Exited"," is correct; what matters is its exit code — ",[36,107,108],{},"Exited (0)"," is success.",[18,111],{},[21,113,115],{"id":114},"starting-the-deployment","Starting the deployment",[117,118,120],"h3",{"id":119},"no-usable-container-engine",[36,121,122],{},"No usable container engine",[124,125,126],"blockquote",{},[14,127,128],{},[36,129,130],{},"error: No usable container engine — install Docker (with the Compose plugin) or Podman 4.1+ (a Compose provider, plus a running machine on macOS), or set CONTAINER_ENGINE in .env.",[14,132,133,136,137,140,141,144],{},[71,134,135],{},"Cause."," Neither ",[36,138,139],{},"docker compose"," nor ",[36,142,143],{},"podman compose"," ran successfully. Usually an engine is installed but its Compose support is not, or the engine's service is not running.",[14,146,147,150],{},[71,148,149],{},"Fix."," Check directly:",[29,152,154],{"className":31,"code":153,"language":33,"meta":34,"style":34},"docker compose version\npodman compose version\n",[36,155,156,161],{"__ignoreMap":34},[39,157,158],{"class":41,"line":42},[39,159,160],{},"docker compose version\n",[39,162,163],{"class":41,"line":48},[39,164,165],{},"podman compose version\n",[14,167,168,169,172],{},"Install whichever piece is missing. A bare engine with no Compose provider is not enough. If both are installed and one works, name it in ",[36,170,171],{},".env",":",[29,174,179],{"className":175,"code":177,"language":178},[176],"language-text","CONTAINER_ENGINE=docker\n","text",[36,180,177],{"__ignoreMap":34},[117,182,184],{"id":183},"container_enginepodman-but-podman-compose-failed",[36,185,186],{},"CONTAINER_ENGINE=podman, but 'podman compose' failed",[124,188,189],{},[14,190,191],{},[36,192,193],{},"error: CONTAINER_ENGINE=podman, but 'podman compose' failed — check that podman and its Compose provider are installed, and (macOS\u002FPodman) that its machine is running ('podman machine start'); or set a different CONTAINER_ENGINE in .env.",[14,195,196,198],{},[71,197,135],{}," On macOS, almost always the Podman machine is not running. Otherwise, no Compose provider is available to Podman.",[14,200,201],{},[71,202,149],{},[29,204,206],{"className":31,"code":205,"language":33,"meta":34,"style":34},"podman machine start\n.\u002Fbyodt up\n",[36,207,208,213],{"__ignoreMap":34},[39,209,210],{"class":41,"line":42},[39,211,212],{},"podman machine start\n",[39,214,215],{"class":41,"line":48},[39,216,217],{},".\u002Fbyodt up\n",[117,219,221],{"id":220},"not-set-up-yet",[36,222,223],{},"Not set up yet",[124,225,226],{},[14,227,228],{},[36,229,230],{},"error: Not set up yet — run '.\u002Fbyodt bootstrap' (or just '.\u002Fbyodt up', which does it for you).",[14,232,233,235,236,74,238,78,241,244],{},[71,234,135],{}," A command that needs a configured deployment ran against a bundle that has not been set up — a fresh extract, or one where ",[36,237,171],{},[36,239,240],{},".env.secrets",[36,242,243],{},"mode\u002Fmode.env"," was removed.",[14,246,247],{},[71,248,149],{},[29,250,251],{"className":31,"code":217,"language":33,"meta":34,"style":34},[36,252,253],{"__ignoreMap":34},[39,254,255],{"class":41,"line":42},[39,256,217],{},[14,258,259,260,262,263,268],{},"That repairs the layout and starts the deployment. If ",[36,261,240],{}," was deleted while a graph already exists, read ",[264,265,267],"a",{"href":266},"#the-database-will-not-become-healthy","The database will not become healthy"," before running anything.",[117,270,272],{"id":271},"refusing-v",[36,273,274],{},"Refusing '-v'",[124,276,277],{},[14,278,279],{},[36,280,281],{},"error: Refusing '-v' — it deletes data\u002Fimages this command keeps by design. Remove the graph explicitly instead ('.\u002Fbyodt destroy' prints how).",[14,283,284,286,287,74,290,78,293,296,297,300,301,304],{},[71,285,135],{}," You passed ",[36,288,289],{},"-v",[36,291,292],{},"--volumes",[36,294,295],{},"--rmi"," to ",[36,298,299],{},"down"," or ",[36,302,303],{},"destroy",". These commands keep your data by design, so they refuse flags that would contradict that rather than silently obeying.",[14,306,307,309],{},[71,308,149],{}," If you did want to erase the graph, do it explicitly:",[29,311,313],{"className":31,"code":312,"language":33,"meta":34,"style":34},".\u002Fbyodt destroy\n",[36,314,315],{"__ignoreMap":34},[39,316,317],{"class":41,"line":42},[39,318,312],{},[14,320,321],{},"and run the wipe command it prints for your storage setting.",[117,323,325],{"id":324},"embedding_modelembeddinggemma-in-env-names-the-old-embedding-servers-model",[36,326,327],{},"EMBEDDING_MODEL=embeddinggemma in .env names the old embedding server's model",[124,329,330],{},[14,331,332],{},[36,333,334],{},"error: EMBEDDING_MODEL=embeddinggemma in .env names the old embedding server's model, which this release no longer runs. Remove the EMBEDDING_MODEL line from .env: the platform embeds in process with its default model.",[14,336,337,339,340,342,343,346,347,349,350,74,353,356,357,360],{},[71,338,135],{}," Your ",[36,341,171],{}," was carried over from a release that ran the old ",[36,344,345],{},"ollama"," service, and still selects that service's model. This release has no ",[36,348,345],{}," service: the platform embeds in process. ",[36,351,352],{},".\u002Fbyodt up",[36,354,355],{},".\u002Fbyodt update"," and ",[36,358,359],{},".\u002Fbyodt models pull"," refuse the setting before anything starts, however the value is quoted, exported, or followed by a comment.",[14,362,363,365,366,369,370,372,373,380],{},[71,364,149],{}," Delete the ",[36,367,368],{},"EMBEDDING_MODEL"," line from ",[36,371,171],{}," (or comment it out), then run the command again. Leaving the key unset selects the platform's default model. See ",[264,374,376,377,379],{"href":375},"\u002Fbyodt-cloud\u002Foperations#upgrading-from-a-release-with-the-ollama-service","Operations → Upgrading from a release with the ",[36,378,345],{}," service",".",[117,382,384,387,388],{"id":383},"is-no-longer-used-notices-and-dataollama",[36,385,386],{},"… is no longer used"," notices, and ",[36,389,390],{},"data\u002Follama",[124,392,393,398],{},[14,394,395],{},[36,396,397],{},"==> OLLAMA_IMAGE in .env is no longer used (this bundle has no Ollama service); you can remove the line.",[14,399,400],{},[36,401,402],{},"==> data\u002Follama (…) holds the old embedding server's model and is no longer used. Once the new start has worked: sudo rm -rf data\u002Follama",[14,404,405,407,408,74,410,356,412,414,415,418,419,300,422,425,426,428,429,431,432,434,435,437,438,300,441,444,445,448],{},[71,406,135],{}," Notices, not errors. ",[36,409,352],{},[36,411,355],{},[36,413,359],{}," report every ",[36,416,417],{},"OLLAMA_*"," line, and an ",[36,420,421],{},"EMBEDDING_URL",[36,423,424],{},"EMBEDDING_SIMILARITY_THRESHOLD"," line, left in ",[36,427,171],{}," by an older release, and a leftover ",[36,430,390],{}," directory with its size. None of them stops the start. These commands never remove the lines or delete ",[36,433,390],{}," for you: they never change your settings in ",[36,436,171],{},", and only record a missing ",[36,439,440],{},"CONTAINER_ENGINE",[36,442,443],{},"DB_ENGINE"," (on Neo4j, ",[36,446,447],{},"NEO4J_IMAGE"," too).",[14,450,451,453,454,456],{},[71,452,149],{}," Optional. Remove the named lines from ",[36,455,171],{}," whenever convenient. Once the new release has started and works, reclaim the disk:",[29,458,460],{"className":31,"code":459,"language":33,"meta":34,"style":34},"sudo rm -rf data\u002Follama\n",[36,461,462],{"__ignoreMap":34},[39,463,464],{"class":41,"line":42},[39,465,459],{},[14,467,468,471,472,474,475,477,478,481,482,485,486,488],{},[36,469,470],{},"sudo"," is usually needed (rootful Docker on Linux): the old ",[36,473,345],{}," service wrote the directory as root. If ",[36,476,390],{}," is a symbolic link, ",[36,479,480],{},"byodt"," reports only that it is one: it does not name or measure the link's target. Check where it points yourself (",[36,483,484],{},"ls -l data\u002Follama",") before you remove anything. Keep ",[36,487,390],{}," while you might still roll back to the previous release, which uses it.",[117,490,492],{"id":491},"db_engine-is-but-its-data-directory-is-empty",[36,493,494],{},"DB_ENGINE is …, but its data directory (…) is empty",[124,496,497],{},[14,498,499],{},[36,500,501],{},"error: DB_ENGINE is neo4j, but its data directory (.\u002Fdata\u002Fneo4j) is empty while memgraph's (.\u002Fdata\u002Fmemgraph) holds a graph. Starting would bring up an empty graph. To keep using memgraph, set DB_ENGINE=memgraph in .env (and unset an exported DB_ENGINE). To move to neo4j, move .\u002Fdata\u002Fmemgraph aside: the neo4j graph starts empty, and a backup taken on memgraph cannot be loaded into it.",[14,503,504],{},"The same message appears with the engines the other way round.",[14,506,507,509,510,512,513,515,516,74,518,74,521,356,523,526,527,356,529,532,533,535],{},[71,508,135],{}," ",[36,511,443],{}," now names the other engine — changed in ",[36,514,171],{},", or exported for this command — while your graph is in the first engine's data directory. Nothing converts one engine's data into the other's, so starting would bring up an empty graph. ",[36,517,352],{},[36,519,520],{},".\u002Fbyodt restart",[36,522,355],{},[36,524,525],{},".\u002Fbyodt bootstrap"," refuse, before they record or create anything: ",[36,528,171],{},[36,530,531],{},"data\u002F"," are left as they were, so an exported ",[36,534,443],{}," that is refused is not recorded either.",[14,537,538,540,541,543,544,546,547,549,550,554,555,558,559,380],{},[71,539,149],{}," To stay on the engine that holds your graph, set ",[36,542,443],{}," back in ",[36,545,171],{}," and unset any exported ",[36,548,443],{},". To switch on purpose, follow ",[264,551,553],{"href":552},"\u002Fbyodt-cloud\u002Fconfiguration#the-database-engine","Configuration → The database engine",": back up, ",[36,556,557],{},".\u002Fbyodt down",", move the old data directory aside, ",[36,560,352],{},[117,562,564],{"id":563},"db_engine-is-not-a-database-this-bundle-runs",[36,565,566],{},"DB_ENGINE=… is not a database this bundle runs",[124,568,569],{},[14,570,571],{},[36,572,573],{},"error: DB_ENGINE=… in .env is not a database this bundle runs — set memgraph or neo4j.",[14,575,576,577,580,581,380],{},"When the value is exported, the message says ",[36,578,579],{},"in your shell's environment"," instead of ",[36,582,583],{},"in .env",[14,585,586,509,588,590,591,593,594,140,597,600,601,603,604,606,607,610,611,614],{},[71,587,135],{},[36,589,443],{}," in ",[36,592,171],{},", or exported, is neither ",[36,595,596],{},"memgraph",[36,598,599],{},"neo4j",". ",[36,602,480],{}," reads the ",[36,605,171],{}," line as compose does: an ",[36,608,609],{},"export "," prefix, quotes, and a trailing ",[36,612,613],{}," # comment"," are fine; the value itself must be one of the two.",[14,616,617,619,620,300,623,590,626,628],{},[71,618,149],{}," Set ",[36,621,622],{},"DB_ENGINE=memgraph",[36,624,625],{},"DB_ENGINE=neo4j",[36,627,171],{},", unset any exported value, and run the command again.",[117,630,632],{"id":631},"neo4j_username-in-env-is-not-used-on-neo4j",[36,633,634],{},"NEO4J_USERNAME=… in .env is not used on Neo4j",[124,636,637],{},[14,638,639],{},[36,640,641],{},"==> NEO4J_USERNAME=dethernety in .env is not used on Neo4j: the platform connects with NEO4J_USERNAME=neo4j. You can remove the line.",[14,643,644,646,647,649,650,652,653,356,656,590,659,661,662,590,664,666,667,669],{},[71,645,135],{}," A notice, not an error. On Neo4j the platform always connects as ",[36,648,599],{}," to the database ",[36,651,599],{},", so ",[36,654,655],{},"NEO4J_USERNAME",[36,657,658],{},"NEO4J_DATABASE",[36,660,171],{}," are not used. On the first Neo4j run — the one that records ",[36,663,447],{},[36,665,171],{}," — ",[36,668,480],{}," says so for each one set to another value. It does not repeat the notice on later runs.",[14,671,672,674],{},[71,673,149],{}," None needed. You can remove the lines, or leave them.",[117,676,678],{"id":677},"is-not-loaded-byodt-reads-local-changes-from-composeoverrideyaml-only",[36,679,680],{},"… is not loaded: byodt reads local changes from compose.override.yaml only",[124,682,683],{},[14,684,685],{},[36,686,687],{},"warning: compose.override.yml is not loaded: byodt reads local changes from compose.override.yaml only. Rename it to use it.",[14,689,690,509,692,694,695,698,699,74,702,300,705,708],{},[71,691,135],{},[36,693,480],{}," names the compose files it passes, and ",[36,696,697],{},"compose.override.yaml"," is the only override file among them. Compose no longer picks up ",[36,700,701],{},"compose.override.yml",[36,703,704],{},"docker-compose.override.yaml",[36,706,707],{},"docker-compose.override.yml"," on its own.",[14,710,711,713,714,716,717,719,720,380],{},[71,712,149],{}," Rename the file to ",[36,715,697],{},", then ",[36,718,352],{},". See ",[264,721,723],{"href":722},"\u002Fbyodt-cloud\u002Fconfiguration#local-changes-to-the-compose-files","Configuration → Local changes to the compose files",[117,725,727,728],{"id":726},"the-platform-does-not-start-or-keeps-restarting-after-byodt-restart","The platform does not start, or keeps restarting, after ",[36,729,520],{},[14,731,732,735],{},[71,733,734],{},"Symptom."," One of two, depending on the command:",[737,738,739,756],"ul",{},[740,741,742,743,74,747,749,750,753,754,380],"li",{},"After ",[71,744,745],{},[36,746,520],{},[36,748,88],{}," shows the platform not running, and ",[36,751,752],{},".\u002Fbyodt logs console-init"," ends with a refusal that names ",[36,755,368],{},[740,757,742,758,74,763,765,766,753,769,380],{},[71,759,760],{},[36,761,762],{},".\u002Fbyodt restart platform",[36,764,88],{}," shows the platform restarting over and over, and ",[36,767,768],{},".\u002Fbyodt logs platform",[36,770,368],{},[14,772,773,509,775,356,777,779,780,356,782,784,785,787,788,791],{},[71,774,135],{},[36,776,520],{},[36,778,762],{}," skip the pre-flight checks that ",[36,781,352],{},[36,783,355],{}," run. A stale ",[36,786,171],{}," — typically one that still sets ",[36,789,790],{},"EMBEDDING_MODEL=embeddinggemma"," after an upgrade — is therefore not caught before the start. What happens next depends on what the command recreates:",[737,793,794,810],{},[740,795,796,800,801,803,804,806,807,809],{},[71,797,798],{},[36,799,520],{}," recreates the whole stack, the one-shot ",[36,802,92],{}," included. ",[36,805,92],{}," refuses the model, and the platform starts only once ",[36,808,92],{}," has completed successfully — so the platform stays down. It does not loop.",[740,811,812,816],{},[71,813,814],{},[36,815,762],{}," recreates only the platform, without the services it depends on. The platform refuses the model at every start, and the engine starts it again: a restart loop.",[14,818,819,821,822,824,825,827,828,830],{},[71,820,149],{}," Run ",[36,823,352],{},". Its checks stop before anything starts and say what to change in ",[36,826,171],{},"; change it, then run ",[36,829,352],{}," again.",[117,832,834],{"id":833},"the-port-is-already-in-use","The port is already in use",[14,836,837,839],{},[71,838,734],{}," The engine reports that the host port cannot be allocated.",[14,841,842,844],{},[71,843,135],{}," Something else on the machine is bound to port 3000.",[14,846,847,849,850,852],{},[71,848,149],{}," Pick another port in ",[36,851,171],{}," and apply it:",[29,854,857],{"className":855,"code":856,"language":178},[176],"FRONT_DOOR_PORT=3100\n",[36,858,856],{"__ignoreMap":34},[29,860,861],{"className":31,"code":217,"language":33,"meta":34,"style":34},[36,862,863],{"__ignoreMap":34},[39,864,865],{"class":41,"line":42},[39,866,217],{},[14,868,869,870,380],{},"Note that port 3000 is a pre-registered loopback callback address, so moving off it means registering your callbacks explicitly if you later connect the deployment. See ",[264,871,873],{"href":872},"\u002Fbyodt-cloud\u002Fconfiguration#front-door","Configuration → Front door",[117,875,877],{"id":876},"this-bundles-compose-project-is-already-used-by-another-directory",[36,878,879],{},"this bundle's compose project is already used by another directory",[124,881,882],{},[29,883,886],{"className":884,"code":885,"language":178},[176],"error: this bundle's compose project is already used by another directory:\n    \u002Fhome\u002Fyou\u002Fdethernety-old\nRunning this here would act on its containers. Upgrade that deployment instead ('.\u002Fbyodt upgrade' in it), or\nstop it there ('.\u002Fbyodt down'). If this deployment was moved here from that directory, run '.\u002Fbyodt down --take-over'\nhere once to remove the old containers, then start it here.\n",[36,887,885],{"__ignoreMap":34},[14,889,890,892,893,896,897,74,900,74,903,74,906,74,908,74,911,74,913,74,916,74,919,356,922,925],{},[71,891,135],{}," Every bundle's deployment has the compose project name ",[36,894,895],{},"dethernety",", and containers of that project, running or stopped, were started from the folder it names. Acting here would act on them: start this folder's services in their place, or stop, back up, restore or remove the other folder's. ",[36,898,899],{},"up",[36,901,902],{},"update",[36,904,905],{},"restart",[36,907,299],{},[36,909,910],{},"stop",[36,912,303],{},[36,914,915],{},"backup",[36,917,918],{},"restore",[36,920,921],{},"upgrade",[36,923,924],{},"setup --start"," all refuse, and change nothing.",[14,927,928,930],{},[71,929,149],{}," It depends on what the other folder is:",[737,932,933,942,962],{},[740,934,935,938,939,941],{},[71,936,937],{},"Another deployment you keep:"," only one runs at a time. Run ",[36,940,557],{}," in that folder, then the command here. To move it to a newer release, upgrade it in its own folder instead of installing a new one.",[740,943,944,947,948],{},[71,945,946],{},"This deployment, before you moved it here:"," remove the old containers once from here, then start here:",[29,949,951],{"className":31,"code":950,"language":33,"meta":34,"style":34},".\u002Fbyodt down --take-over\n.\u002Fbyodt up\n",[36,952,953,958],{"__ignoreMap":34},[39,954,955],{"class":41,"line":42},[39,956,957],{},".\u002Fbyodt down --take-over\n",[39,959,960],{"class":41,"line":48},[39,961,217],{},[740,963,964,509,967,969,970,973],{},[71,965,966],{},"An old folder you no longer need:",[36,968,557],{}," in it, or ",[36,971,972],{},".\u002Fbyodt down --take-over"," here.",[14,975,976,977,380],{},"See ",[264,978,980],{"href":979},"\u002Fbyodt-cloud\u002Foperations#a-deployment-in-another-folder","Operations → A deployment in another folder",[117,982,984],{"id":983},"the-volume-dethernety_-remains-from-an-earlier-deployment-of-this-bundle-and-this-one-would-mount-it",[36,985,986],{},"The volume dethernety_… remains from an earlier deployment of this bundle, and this one would mount it",[124,988,989],{},[14,990,991],{},[36,992,993],{},"error: The volume dethernety_memgraph-data remains from an earlier deployment of this bundle, and this one would mount it: that graph's database users were made with another password, so the platform would be locked out. Set DB_DATA=.\u002Fdata\u002Fmemgraph in .env to keep the database in a folder instead (less robust on a VM-backed engine), or upgrade the deployment it belongs to; if you no longer need that graph, remove it with 'docker volume rm dethernety_memgraph-data' (this deletes it for good), and run the command again.",[14,995,996,997,1000,1001,1004,1005,1007],{},"From ",[36,998,999],{},".\u002Fbyodt setup --start"," the advice reads ",[36,1002,1003],{},"Run setup with --db-data bind"," instead of the ",[36,1006,171],{}," setting. Setup also warns about such a volume before it writes anything, whether or not it starts.",[14,1009,1010,1012],{},[71,1011,135],{}," This folder has not started yet, and it keeps its database in the named volume, which an earlier deployment of the bundle left. Its database users were created with that deployment's password, not this folder's, so the platform would be locked out of it.",[14,1014,1015,1017],{},[71,1016,149],{}," Choose one:",[737,1019,1020,1026,1042],{},[740,1021,1022,1025],{},[71,1023,1024],{},"You want that graph:"," start the deployment it belongs to instead, or upgrade it.",[740,1027,1028,1031,1032,444,1035,1038,1039,1041],{},[71,1029,1030],{},"You want both:"," keep this one's database in a folder: set ",[36,1033,1034],{},"DB_DATA=.\u002Fdata\u002Fmemgraph",[36,1036,1037],{},"NEO4J_DATA=.\u002Fdata\u002Fneo4j",") in ",[36,1040,171],{},", and start again.",[740,1043,1044,1047],{},[71,1045,1046],{},"You no longer need that graph:"," remove the volume with the command the message gives. This deletes it for good.",[14,1049,976,1050,380],{},[264,1051,1053],{"href":1052},"\u002Fbyodt-cloud\u002Finstallation#database-volumes-an-earlier-deployment-left","Installation → Database volumes an earlier deployment left",[117,1055,1057],{"id":1056},"there-is-no-terminal-to-confirm-the-notice-above-on",[36,1058,1059],{},"There is no terminal to confirm the notice above on",[124,1061,1062],{},[14,1063,1064],{},[36,1065,1066],{},"error: There is no terminal to confirm the notice above on. Run the command at a terminal, or add --yes. Nothing has been downloaded yet.",[14,1068,1069,1070],{},"The installer's form reads ",[36,1071,1072],{},"Run this at a terminal, or add --yes.",[14,1074,1075,1077,1078,1082,1083,1086,1087,1090],{},[71,1076,135],{}," The deployment has not run yet, and its first download is waiting for the ",[264,1079,1081],{"href":1080},"\u002Fbyodt-cloud\u002Finstallation#the-third-party-notice","third-party notice"," to be confirmed: by ",[36,1084,1085],{},"y"," at a terminal, or by ",[36,1088,1089],{},"--yes",". A script or a provisioning tool has no terminal.",[14,1092,1093,1095,1096,1098,1099,1102,1103,1106,1107,1109,1110,1113],{},[71,1094,149],{}," Run the command at a terminal, or add ",[36,1097,1089],{},", which counts as the confirmation. The notice is printed either way. On a deployment that has already run, a notice that is due is asked for at a terminal, where ",[36,1100,1101],{},"n"," stops the command with ",[36,1104,1105],{},"Not confirmed. Nothing has changed yet.","; with no terminal and no ",[36,1108,1089],{},", it never stops a command: it is printed with a warning, and ",[36,1111,1112],{},".\u002Fbyodt acknowledge"," records it later.",[117,1115,1117],{"id":1116},"other-accounts-can-change-this-directory-so-byodt-does-not-record-the-third-party-notice-here",[36,1118,1119],{},"Other accounts can change this directory (…), so byodt does not record the third-party notice here",[124,1121,1122],{},[14,1123,1124],{},[36,1125,1126],{},"error: Other accounts can change this directory (\u002Fsrv\u002Fshared\u002Fbyodt), so byodt does not record the third-party notice here. Make it yours and not writable by others (chmod go-w .), and run the command again.",[14,1128,1129,356,1132,1134,1135,380],{},[36,1130,1131],{},".\u002Fbyodt setup",[36,1133,1112],{}," say ",[36,1136,1137],{},"does not record the notice here",[14,1139,1140,509,1142,1144,1145,1148],{},[71,1141,135],{},[36,1143,480],{}," keeps the record of the notice, ",[36,1146,1147],{},"third-party-acknowledgement.log",", only in a folder that is yours and that no other account can write to. A group that may write counts as another account, unless it is your own private group (the group named after you).",[14,1150,1151,1153],{},[71,1152,149],{}," Make the folder yours and not writable by others, from inside it:",[29,1155,1157],{"className":31,"code":1156,"language":33,"meta":34,"style":34},"chmod go-w .\n",[36,1158,1159],{"__ignoreMap":34},[39,1160,1161],{"class":41,"line":42},[39,1162,1156],{},[14,1164,1165,1166,1169],{},"If another account owns it, give it to yours (",[36,1167,1168],{},"sudo chown \"$(id -u):$(id -g)\" .","), or install into a folder of your own. On a deployment that has already run, the command only warns and goes on.",[117,1171,1173],{"id":1172},"failed-to-connect-to-the-docker-api-at-unixrunuserpodmanpodmansock",[36,1174,1175],{},"failed to connect to the docker API at unix:\u002F\u002F\u002Frun\u002Fuser\u002F…\u002Fpodman\u002Fpodman.sock",[124,1177,1178,1183],{},[14,1179,1180],{},[36,1181,1182],{},"failed to connect to the docker API at unix:\u002F\u002F\u002Frun\u002Fuser\u002F\u003Cuid>\u002Fpodman\u002Fpodman.sock; check if the path is correct and if the daemon is running: …",[14,1184,1185],{},[36,1186,1187],{},"error: The start was refused or failed: '.\u002Fbyodt status' shows which service; if console-init stopped it, '.\u002Fbyodt logs console-init' says why.",[14,1189,1190,1192,1193,1195,1196,1199,1200,1202],{},[71,1191,135],{}," Podman, on a host that also has Docker. ",[36,1194,143],{}," found Docker's ",[36,1197,1198],{},"docker-compose"," and ran it, and ",[36,1201,1198],{}," reaches Podman through the Podman API socket, which is not running.",[14,1204,1205,1207,1208,1211],{},[71,1206,149],{}," Make Podman use ",[36,1209,1210],{},"podman-compose",", in this shell and in your shell profile, then run the command again:",[29,1213,1215],{"className":31,"code":1214,"language":33,"meta":34,"style":34},"export PODMAN_COMPOSE_PROVIDER=podman-compose\n",[36,1216,1217],{"__ignoreMap":34},[39,1218,1219],{"class":41,"line":42},[39,1220,1214],{},[14,1222,1223,1224,719,1227,380],{},"Or start the socket: ",[36,1225,1226],{},"systemctl --user start podman.socket",[264,1228,1230],{"href":1229},"\u002Fbyodt-cloud\u002Finstallation#podman-specifics","Installation → Podman specifics",[117,1232,1234,1235,1237],{"id":1233},"the-platform-never-starts-and-console-init-exited-non-zero","The platform never starts, and ",[36,1236,92],{}," exited non-zero",[14,1239,1240,509,1242,300,1244,1246,1247],{},[71,1241,734],{},[36,1243,352],{},[36,1245,355],{}," fails with an error that ends ",[36,1248,1249],{},"'.\u002Fbyodt logs console-init' says why.",[14,1251,1252,1254],{},[71,1253,135],{}," The one-shot aborted the start. It does that for exactly three classes of problem: the pinned versions disagree, the platform's embedding model is not the one the reference data was embedded with, or the schema could not be placed. In each case the platform is deliberately held back — a schema that disagrees with the code serving it must not serve, and a model that did not make the reference vectors would not match them.",[14,1256,1257,1259],{},[71,1258,149],{}," Read the reason:",[29,1261,1263],{"className":31,"code":1262,"language":33,"meta":34,"style":34},".\u002Fbyodt logs console-init\n",[36,1264,1265],{"__ignoreMap":34},[39,1266,1267],{"class":41,"line":42},[39,1268,1262],{},[14,1270,1271],{},"Then see the next three entries.",[117,1273,1275],{"id":1274},"console-image-version-does-not-match-platform_version",[36,1276,1277],{},"console image version … does not match PLATFORM_VERSION",[124,1279,1280],{},[14,1281,1282],{},[36,1283,1284],{},"console image version \"A.B.C\" does not match PLATFORM_VERSION \"X.Y.Z\" — the operator has pinned a version this image cannot serve",[14,1286,1287,339,1289,1291,1292,1295,1296,1299,1300,1302,1303,1305],{},[71,1288,135],{},[36,1290,171],{}," sets ",[36,1293,1294],{},"CONSOLE_IMAGE"," to an image whose tag is not ",[36,1297,1298],{},"PLATFORM_VERSION",". The console image normally follows ",[36,1301,1298],{}," on its own, so this only happens if the key was deliberately uncommented — to point at a mirror — and its tag was left behind, or if an ",[36,1304,171],{}," carried over from an older bundle still pins it.",[14,1307,1308,1310,1311,1313,1314,1316],{},[71,1309,149],{}," Open ",[36,1312,171],{}," and comment the key out so it follows ",[36,1315,1298],{}," again:",[29,1318,1321],{"className":1319,"code":1320,"language":178},[176],"# CONSOLE_IMAGE=ghcr.io\u002Fdether-net\u002Fbyodt-console:${PLATFORM_VERSION}\n",[36,1322,1320],{"__ignoreMap":34},[14,1324,1325,1326,1328],{},"If you need the override because the console image comes from your own mirror, keep it but set its tag to the same value as ",[36,1327,1298],{},". Then apply:",[29,1330,1332],{"className":31,"code":1331,"language":33,"meta":34,"style":34},".\u002Fbyodt update\n",[36,1333,1334],{"__ignoreMap":34},[39,1335,1336],{"class":41,"line":42},[39,1337,1331],{},[14,1339,976,1340,380],{},[264,1341,1343],{"href":1342},"\u002Fbyodt-cloud\u002Foperations#upgrading-to-a-new-release","Upgrading to a new release",[117,1345,1347],{"id":1346},"embedding_model-does-not-match-this-releases-mitre-data",[36,1348,1349],{},"EMBEDDING_MODEL … does not match this release's MITRE data",[124,1351,1352],{},[14,1353,1354],{},[36,1355,1356],{},"EMBEDDING_MODEL \"…\" does not match this release's MITRE data, which was embedded with \"embeddinggemma-300m-retrieval-v1\". Remove EMBEDDING_MODEL from .env; the default is embeddinggemma-300m-retrieval-v1",[14,1358,1359,509,1361,1291,1363,1365],{},[71,1360,135],{},[36,1362,171],{},[36,1364,368],{}," to a model other than the one this release's MITRE reference data was embedded with. The platform would search those vectors with another model's queries, which matches nothing reliably, so the one-shot stops the start before it ingests anything, and the platform does not start.",[14,1367,1368,1370,1371,369,1373,716,1375,1377,1378,380],{},[71,1369,149],{}," Remove the ",[36,1372,368],{},[36,1374,171],{},[36,1376,352],{},". The platform's default is the right model. See ",[264,1379,1381],{"href":1380},"\u002Fbyodt-cloud\u002Fconfiguration#embedding","Configuration → Embedding",[14,1383,1384,1385,1388],{},"If the message instead says the platform's ",[71,1386,1387],{},"default"," embedding profile does not match and that the console image is broken, nothing in your configuration caused it: the release's console image and its data do not belong together. Report it, and stay on your current release.",[117,1390,1392],{"id":1391},"platform_version-is-not-set",[36,1393,1394],{},"PLATFORM_VERSION is not set",[14,1396,1397,1399,1400,1402],{},[71,1398,135],{}," The key is missing or empty in ",[36,1401,171],{}," — usually a hand-edited or partially copied file.",[14,1404,1405,1407,1408,1411,1412,380],{},[71,1406,149],{}," Restore it from ",[36,1409,1410],{},".env.example",", which carries the version this bundle shipped with, then ",[36,1413,352],{},[117,1415,267],{"id":1416},"the-database-will-not-become-healthy",[14,1418,1419,509,1421,1423,1424,1427,1428,1431],{},[71,1420,734],{},[36,1422,88],{}," shows ",[36,1425,1426],{},"db"," unhealthy or perpetually starting, and the platform never starts because it waits for the database. ",[36,1429,1430],{},".\u002Fbyodt logs db"," shows authentication failures.",[14,1433,1434,1436,1437,1439,1440,1442,1443,1446],{},[71,1435,135],{}," The database's credentials and ",[36,1438,240],{}," no longer match. The database created its user from the password that existed when it first started; if ",[36,1441,240],{}," was deleted, a ",[71,1444,1445],{},"new"," password was generated on the next start, and the existing database still expects the old one.",[14,1448,1449],{},[71,1450,1451],{},"Fix, in order of preference:",[1453,1454,1455,1466],"ol",{},[740,1456,1457,1462,1463,1465],{},[71,1458,1459,1460],{},"Restore the original ",[36,1461,240],{}," from your backup of it, then ",[36,1464,352],{},". Your graph is intact.",[740,1467,1468,1471,1472,1497,1500],{},[71,1469,1470],{},"If the password is gone for good",", the existing graph cannot be opened. Restore from a backup onto a fresh database:",[29,1473,1475],{"className":31,"code":1474,"language":33,"meta":34,"style":34},".\u002Fbyodt down\n# remove the graph — .\u002Fbyodt destroy prints the exact command for your storage setting\n.\u002Fbyodt up\n.\u002Fbyodt restore backups\u002F\u003Cyour latest backup>\n",[36,1476,1477,1482,1487,1491],{"__ignoreMap":34},[39,1478,1479],{"class":41,"line":42},[39,1480,1481],{},".\u002Fbyodt down\n",[39,1483,1484],{"class":41,"line":48},[39,1485,1486],{},"# remove the graph — .\u002Fbyodt destroy prints the exact command for your storage setting\n",[39,1488,1489],{"class":41,"line":54},[39,1490,217],{},[39,1492,1494],{"class":41,"line":1493},4,[39,1495,1496],{},".\u002Fbyodt restore backups\u002F\u003Cyour latest backup>\n",[1498,1499],"br",{},"A fresh database adopts the password currently on disk, and a backup carries no credentials, so this works.",[14,1502,1503,1504,1507,1508,1510,1511,380],{},"This is why ",[36,1505,1506],{},".\u002Fbyodt destroy"," prints a warning about ",[36,1509,240],{}," every time. Back that file up separately — see ",[264,1512,1514],{"href":1513},"\u002Fbyodt-cloud\u002Fconfiguration#the-generated-secret-file","Configuration → The generated secret file",[18,1516],{},[21,1518,1520],{"id":1519},"installing-and-upgrading","Installing and upgrading",[14,1522,1523,1524,1527,1528,1531,1532,1534],{},"Every refusal below changes nothing unless it says otherwise: the installer and ",[36,1525,1526],{},".\u002Fbyodt upgrade"," check before they act. The installer prints its messages as ",[36,1529,1530],{},"error: …",", as ",[36,1533,480],{}," does.",[117,1536,1538],{"id":1537},"there-is-a-deployment-in",[36,1539,1540],{},"There is a deployment in …",[124,1542,1543],{},[14,1544,1545],{},[36,1546,1547],{},"error: There is a deployment in \u002Fhome\u002Fyou\u002Fbyodt. Upgrade it (--upgrade), or name another folder for a new one with --dir. Nothing was changed.",[14,1549,1550,1552,1553,1556,1557,1559,1560,1563,1564,1566],{},[71,1551,135],{}," The installer found a deployment: in ",[36,1554,1555],{},"--dir",", or, without ",[36,1558,1555],{},", in a folder the container engine started this bundle's deployment from, or in a ",[36,1561,1562],{},"byodt*"," folder of the directory you ran it in. It never installs over one. Without a terminal, or with ",[36,1565,1089],{},", it does not ask whether to upgrade it.",[14,1568,1569,1571,1572,1575,1576,1578,1579,1581],{},[71,1570,149],{}," To upgrade that deployment, add ",[36,1573,1574],{},"--upgrade"," (and ",[36,1577,1555],{}," to name it). To install a second one, name a new folder with ",[36,1580,1555],{},"; only one of the two can run at a time.",[117,1583,1585],{"id":1584},"already-exists-choose-another-folder-with-dir",[36,1586,1587],{},"… already exists. Choose another folder with --dir",[124,1589,1590],{},[14,1591,1592],{},[36,1593,1594],{},"error: .\u002Fbyodt already exists. Choose another folder with --dir, or upgrade the deployment in it (--upgrade); a folder a refused setup left behind holds nothing yet, and can be removed.",[14,1596,1597,1599],{},[71,1598,135],{}," The folder the installer would create exists, and is not a deployment. Often it is one an earlier run unpacked, whose setup then refused.",[14,1601,1602,1604,1605,1607,1608,1610,1611,1613],{},[71,1603,149],{}," Name another folder with ",[36,1606,1555],{},". If the folder is one a refused setup left (it holds the bundle's files and no ",[36,1609,171],{},"), remove it, or run ",[36,1612,1131],{}," inside it.",[117,1615,1617,1620,1621],{"id":1616},"the-deployment-in-already-runs-release-already-holds-release-and-has-not-been-started-yet",[36,1618,1619],{},"The deployment in … already runs release …"," \u002F ",[36,1622,1623],{},"… already holds release …, and has not been started yet",[124,1625,1626,1631],{},[14,1627,1628],{},[36,1629,1630],{},"error: The deployment in \u002Fhome\u002Fyou\u002Fbyodt already runs release X.Y.Z; '\u002Fhome\u002Fyou\u002Fbyodt\u002Fbyodt update' applies it again. To install another one, name its folder with --dir. Nothing was changed.",[14,1632,1633],{},[36,1634,1635],{},"error: The deployment in \u002Fhome\u002Fyou\u002Fbyodt already holds release X.Y.Z, and has not been started yet; '\u002Fhome\u002Fyou\u002Fbyodt\u002Fbyodt up' starts it. To install another one, name its folder with --dir. Nothing was changed.",[14,1637,1638,1640,1641,600,1644,1647,1648],{},[71,1639,135],{}," You ran the installer of the release the deployment is already on. The second message is for a folder that was set up but never started, such as one whose setup ran without ",[36,1642,1643],{},"--start",[36,1645,1646],{},".\u002Fbyodt upgrade X.Y.Z"," says ",[36,1649,1650],{},"Already on X.Y.Z.",[14,1652,1653,1655,1656,1658,1659,1661],{},[71,1654,149],{}," Nothing to upgrade. ",[36,1657,355],{}," pulls the pinned images and applies them again; on a folder that has not been started yet, ",[36,1660,352],{}," starts it.",[117,1663,1665],{"id":1664},"an-upgrade-is-half-done-in",[36,1666,1667],{},"An upgrade is half done in …",[124,1669,1670],{},[14,1671,1672],{},[36,1673,1674],{},"error: An upgrade is half done in \u002Fhome\u002Fyou\u002Fbyodt. '\u002Fhome\u002Fyou\u002Fbyodt\u002Fbyodt upgrade' goes on with it, or '\u002Fhome\u002Fyou\u002Fbyodt\u002Fbyodt upgrade --abandon' undoes it. Nothing was changed.",[14,1676,1677,1679,1680,1682],{},[71,1678,135],{}," An upgrade to this release stopped partway, and the deployment's own ",[36,1681,480],{}," is already this release's.",[14,1684,1685,1687,1688,380],{},[71,1686,149],{}," Run the command it names. See ",[264,1689,1691],{"href":1690},"\u002Fbyodt-cloud\u002Foperations#if-an-upgrade-stops","Operations → If an upgrade stops",[117,1693,1695],{"id":1694},"more-than-one-deployment-was-found",[36,1696,1697],{},"More than one deployment was found",[124,1699,1700],{},[14,1701,1702],{},[36,1703,1704],{},"error: More than one deployment was found (above). Name the one to upgrade with --dir.",[14,1706,1707,1709,1710,1712],{},[71,1708,149],{}," Run the installer again with ",[36,1711,1555],{}," naming the deployment to upgrade, or a new folder to install into.",[117,1714,1716],{"id":1715},"holds-a-deployment-but-another-account-owns-it-or-can-change-it",[36,1717,1718],{},"… holds a deployment, but another account owns it or can change it",[124,1720,1721],{},[14,1722,1723],{},[36,1724,1725],{},"error: \u002Fsrv\u002Fbyodt holds a deployment, but another account owns it or can change it; this script does not act on it. To install a new one elsewhere, name its folder with --dir.",[14,1727,1728,1647,1730,1733,1734],{},[36,1729,1526],{},[36,1731,1732],{},"… can be changed by other accounts, or is not yours: byodt does not upgrade it. Nothing was changed.",", or names a file: ",[36,1735,1736],{},"…\u002F.env is missing, a link, or not yours: byodt does not upgrade it. Nothing was changed.",[14,1738,1739,1741,1742,74,1744,356,1746,1748,1749,380],{},[71,1740,135],{}," An upgrade runs the new release's code in place of the deployment's, so it acts only on a folder, ",[36,1743,480],{},[36,1745,171],{},[36,1747,1410],{}," that are yours (or root's), not links, in a folder no other account can write to. A group that may write counts as another account, unless it is your own private group. See ",[264,1750,1752],{"href":1751},"\u002Fbyodt-cloud\u002Finstallation#folders-other-accounts-can-change","Installation → Folders other accounts can change",[14,1754,1755,1757,1758,1761],{},[71,1756,149],{}," Run the upgrade as the account that owns the deployment, or make the folder yours and not writable by others (",[36,1759,1760],{},"chmod go-w \u003Cfolder>",").",[117,1763,1765],{"id":1764},"other-accounts-can-change-install-where-only-you-can-dir",[36,1766,1767],{},"Other accounts can change …; install where only you can (--dir)",[124,1769,1770],{},[14,1771,1772],{},[36,1773,1774],{},"error: Other accounts can change \u002Ftmp; install where only you can (--dir). The deployment holds its own data and secrets, so a shared folder such as \u002Ftmp is the wrong place for it anyway.",[14,1776,1777,1779],{},[71,1778,135],{}," The folder the installer would create the deployment in is writable by other accounts, so one of them could change where it lands.",[14,1781,1782,1784,1785,1787],{},[71,1783,149],{}," Install into a folder of your own, with ",[36,1786,1555],{},", for example under your home directory. A folder writable only by your own private group is accepted.",[117,1789,1791],{"id":1790},"give-https-proxy-without-a-login",[36,1792,1793],{},"Give --https-proxy without a login",[124,1795,1796],{},[14,1797,1798],{},[36,1799,1800],{},"error: Give --https-proxy without a login (http:\u002F\u002Fhost:port): an argument shows in the process list. A login comes only from HTTPS_PROXY in the environment.",[14,1802,1803,509,1805,1808,1809,1812],{},[71,1804,135],{},[36,1806,1807],{},"--https-proxy"," carried ",[36,1810,1811],{},"user:password@",". Any account that lists processes can read a command's arguments.",[14,1814,1815,1817,1818,1821,1822,1826,1827,1829,1830,1833,1834,74,1837,300,1840,1843,1844,380],{},[71,1816,149],{}," Give the login through ",[36,1819,1820],{},"HTTPS_PROXY"," in your shell, as in ",[264,1823,1825],{"href":1824},"\u002Fbyodt-cloud\u002Finstallation#_2-get-the-bundle-through-the-proxy","Installation → Behind an outbound proxy → 2",", and leave ",[36,1828,1807],{}," out. The installer also refuses a proxy it cannot use as given: ",[36,1831,1832],{},"The proxy is …: write it as http:\u002F\u002Fhost:port.",", or, for a space, a double quote, ",[36,1835,1836],{},"#",[36,1838,1839],{},"?",[36,1841,1842],{},"$"," in it, ",[36,1845,1846],{},"percent-encode its login",[117,1848,1850],{"id":1849},"is-larger-than-a-releases-file-is",[36,1851,1852],{},"… is larger than a release's file is",[124,1854,1855],{},[14,1856,1857],{},[36,1858,1859],{},"error: https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases\u002Fdownload\u002FvX.Y.Z\u002Fbyodt-X.Y.Z.tar.gz is larger than a release's file is.",[14,1861,1862,1863,1866,1867,1870,1871,1873],{},"With ",[36,1864,1865],{},"curl",", the same case reads ",[36,1868,1869],{},"error: Could not download the bundle.",", after ",[36,1872,1865],{},"'s own message.",[14,1875,1876,1878],{},[71,1877,135],{}," The download was larger than 50 MiB, which no release's bundle is. Something between you and the release host, such as a proxy's error page or a captive portal, answered instead. Nothing was kept.",[14,1880,1881,1883,1884,1887],{},[71,1882,149],{}," Check the URL, and what your proxy returns for it. ",[36,1885,1886],{},"Could not download the bundle."," on its own also means the release host could not be reached, or there is no such release.",[117,1889,1891],{"id":1890},"the-bundles-sha-256-is-not-the-this-release-published",[36,1892,1893],{},"The bundle's SHA-256 is …, not the … this release published",[124,1895,1896],{},[14,1897,1898],{},[36,1899,1900],{},"error: The bundle's SHA-256 is …, not the … this release published. It was not used.",[14,1902,1903,1647,1905],{},[36,1904,1526],{},[36,1906,1907],{},"The downloaded bundle is not the one release X.Y.Z published (SHA-256 mismatch). Nothing was changed.",[14,1909,1910,1912,1913,1916],{},[71,1911,135],{}," The file is not the release's bundle: a download cut short or altered on the way, or a ",[36,1914,1915],{},"--tarball"," file from another release.",[14,1918,1919,1921,1922,1924],{},[71,1920,149],{}," Run it again. With ",[36,1923,1915],{},", use the bundle file of the installer's own release. If it keeps failing, do not work around it: something is changing the download.",[117,1926,1928],{"id":1927},"neither-sha256sum-nor-shasum-is-installed",[36,1929,1930],{},"Neither sha256sum nor shasum is installed",[124,1932,1933],{},[14,1934,1935],{},[36,1936,1937],{},"error: Neither sha256sum nor shasum is installed; files cannot be checked.",[14,1939,1940,1941],{},"The installer says ",[36,1942,1943],{},"Neither sha256sum nor shasum is installed; the download cannot be checked.",[14,1945,1946,1948,1949,1951,1952,74,1954,74,1956,74,1959,356,1961,1963],{},[71,1947,135],{}," The installer checks the bundle by its SHA-256. ",[36,1950,480],{}," needs one of these tools for two things only: to record your confirmation of the third-party notice, and to upgrade. Other commands, such as ",[36,1953,299],{},[36,1955,96],{},[36,1957,1958],{},"logs",[36,1960,915],{},[36,1962,918],{},", do not.",[737,1965,1966,1973,1982],{},[740,1967,1968,1972],{},[71,1969,1970],{},[36,1971,1526],{}," stops when it checks the downloaded bundle, before it changes anything.",[740,1974,1975,1981],{},[71,1976,1977,356,1979],{},[36,1978,1131],{},[36,1980,1112],{}," stop when they would record the confirmation. Setup removes what it wrote.",[740,1983,1984,1995,1996,1998,1999,2001],{},[71,1985,1986,74,1988,74,1990,356,1992],{},[36,1987,352],{},[36,1989,902],{},[36,1991,905],{},[36,1993,1994],{},"models pull"," cannot tell, without a tool, that the notice you confirmed is unchanged, so it counts as not yet confirmed. On a first start, at a terminal, or with ",[36,1997,1089],{},", they ask for it, and stop when they would record your confirmation. Without a terminal and without ",[36,2000,1089],{},", on a deployment that has run, they print the notice with a warning and go on.",[14,2003,2004,2005,356,2007,2009,2010,2013,2014,2017],{},"On a first run, ",[36,2006,1131],{},[36,2008,525],{}," also warn: ",[36,2011,2012],{},"Neither sha256sum nor shasum is installed, so .byodt-release was not written; the first upgrade will not be able to check local edits."," Setup then stops as above; ",[36,2015,2016],{},"bootstrap",", which shows no notice, goes on.",[14,2019,2020,2022,2023,2026,2027,2030],{},[71,2021,149],{}," Install one: ",[36,2024,2025],{},"sha256sum"," comes with GNU coreutils on Linux, and ",[36,2028,2029],{},"shasum"," with Perl on macOS. Then run the command again.",[117,2032,2034],{"id":2033},"cosign-could-not-verify-the-bundles-signature",[36,2035,2036],{},"cosign could not verify the bundle's signature",[124,2038,2039],{},[14,2040,2041],{},[36,2042,2043],{},"error: cosign could not verify the bundle's signature against this release's identity (above). It was not used.",[14,2045,2046,2048,2049,2052],{},[71,2047,135],{}," cosign is installed and checked the bundle's signature against the release workflow of ",[36,2050,2051],{},"dether-net\u002Fdethernety-oss"," at this release's tag, and it did not match. Its own output is above the message. A signature from another release, or a bundle file that was changed, fails here.",[14,2054,2055,2057],{},[71,2056,149],{}," Read cosign's output. It may need to reach Sigstore's public services; behind a proxy, cosign uses the same proxy as the download. Do not use the bundle until it verifies.",[117,2059,2061],{"id":2060},"an-unattended-upgrade-does-not-run-code-it-cannot-verify",[36,2062,2063],{},"an unattended upgrade does not run code it cannot verify",[124,2065,2066],{},[14,2067,2068],{},[36,2069,2070],{},"error: cosign did not verify the bundle, and an unattended upgrade does not run code it cannot verify. Install cosign (https:\u002F\u002Fgithub.com\u002Fsigstore\u002Fcosign), or pass --allow-unsigned knowingly. Nothing was changed.",[14,2072,2073,1647,2075,2078,2079,2082,2083,2085],{},[36,2074,1526],{},[36,2076,2077],{},"cosign is not installed, so the bundle's signature was not checked, and an unattended upgrade …",", with ",[36,2080,2081],{},"and it came through wget, which cannot hold the download to HTTPS"," added when ",[36,2084,1865],{}," is not installed.",[14,2087,2088,2090,2091,2093,2094,2096,2097,2100,2101,2103,2104,380],{},[71,2089,135],{}," The upgrade runs without a terminal, or with ",[36,2092,1089],{},", and cosign did not verify the bundle: it is not installed, or, with ",[36,2095,1915],{},", there is no ",[36,2098,2099],{},".bundle"," file beside the tarball. An unattended upgrade does not run code whose signature nobody checked. ",[36,2102,1089],{}," never implies ",[36,2105,2106],{},"--allow-unsigned",[14,2108,2109,2111],{},[71,2110,149],{}," Either:",[737,2113,2114,2126],{},[740,2115,2116,2125],{},[71,2117,2118,2119],{},"Install ",[264,2120,2124],{"href":2121,"rel":2122},"https:\u002F\u002Fgithub.com\u002Fsigstore\u002Fcosign",[2123],"nofollow","cosign",", and run the upgrade again. It then verifies the signature.",[740,2127,2128,2133],{},[71,2129,2130,2131],{},"Or pass ",[36,2132,2106],{},", once you have decided that the SHA-256 check alone is enough. The bundle's integrity is still checked; its authenticity is not. The SHA-256 comes from the same release, so it shows the download is intact, not who made it.",[14,2135,2136,2137,2139,2140,2142,2143,2148],{},"At a terminal, without ",[36,2138,1089],{},", the upgrade asks instead, unless you pass ",[36,2141,2106],{},". A signature cosign rejects is a different error, ",[264,2144,2146],{"href":2145},"#cosign-could-not-verify-the-bundles-signature",[36,2147,2036],{},", and no flag lets the upgrade go on.",[117,2150,2152],{"id":2151},"a-signature-is-required-but",[36,2153,2154],{},"A signature is required, but …",[124,2156,2157,2162,2167],{},[14,2158,2159],{},[36,2160,2161],{},"error: A signature is required, but cosign is not installed (https:\u002F\u002Fgithub.com\u002Fsigstore\u002Fcosign).",[14,2163,2164],{},[36,2165,2166],{},"error: A signature is required, but there is no …\u002Fbyodt-X.Y.Z.tar.gz.bundle beside the tarball to verify.",[14,2168,2169],{},[36,2170,2171],{},"error: A signature is required, but cosign is not installed, so the bundle's signature was not checked. Nothing was changed.",[14,2173,2174,2175,2177],{},"The first two are the installer's; the third is ",[36,2176,1526],{},"'s.",[14,2179,2180,2182,2183,2186,2187,2190,2191,2193],{},[71,2181,135],{}," A signature is required, by ",[36,2184,2185],{},"--require-signature"," or by ",[36,2188,2189],{},"UPGRADE_REQUIRE_SIGNATURE=true"," in the deployment's ",[36,2192,171],{},", and none could be checked.",[14,2195,2196,2198,2199,2201,2202,2205],{},[71,2197,149],{}," Install cosign. With ",[36,2200,1915],{},", put the release's ",[36,2203,2204],{},"byodt-X.Y.Z.tar.gz.bundle"," beside the tarball.",[117,2207,2209],{"id":2208},"sets-upgrade_require_signaturetrue-so-allow-unsigned-does-not-apply",[36,2210,2211],{},"… sets UPGRADE_REQUIRE_SIGNATURE=true, so --allow-unsigned does not apply",[124,2213,2214,2219],{},[14,2215,2216],{},[36,2217,2218],{},"error: \u002Fhome\u002Fyou\u002Fbyodt\u002F.env sets UPGRADE_REQUIRE_SIGNATURE=true, so --allow-unsigned does not apply. Nothing was changed.",[14,2220,2221],{},[36,2222,2223],{},"error: .env sets UPGRADE_REQUIRE_SIGNATURE=true, so --allow-unsigned does not apply. Nothing was changed.",[14,2225,2226,2228,2229,2233,2234,2236,2237,2239],{},[71,2227,135],{}," The deployment requires a signature for every upgrade (see ",[264,2230,2232],{"href":2231},"\u002Fbyodt-cloud\u002Fconfiguration#upgrades","Configuration → Upgrades","), and the installer or ",[36,2235,1526],{}," was given ",[36,2238,2106],{},". It is refused before anything is downloaded, whether or not cosign is installed.",[14,2241,2242,2244,2245,2247,2248,2250],{},[71,2243,149],{}," Install cosign and drop ",[36,2246,2106],{},". To allow an unverified upgrade, remove the setting from ",[36,2249,171],{}," first: a decision for whoever owns the deployment.",[117,2252,2254],{"id":2253},"sets-upgrade_require_signature-which-is-neither-true-nor-false",[36,2255,2256],{},"… sets UPGRADE_REQUIRE_SIGNATURE=…, which is neither true nor false",[124,2258,2259,2264],{},[14,2260,2261],{},[36,2262,2263],{},"error: \u002Fhome\u002Fyou\u002Fbyodt\u002F.env sets UPGRADE_REQUIRE_SIGNATURE=yes, which is neither true nor false. Nothing was changed.",[14,2265,2266],{},[36,2267,2268],{},"error: .env sets UPGRADE_REQUIRE_SIGNATURE=yes, which is neither true nor false. Nothing was changed.",[14,2270,2271,2273,2274,1291,2276,2279,2280,74,2283,2286,2287,74,2290,300,2293,2296,2297,2299,2300,356,2302,2304,2305,2307],{},[71,2272,135],{}," The deployment's ",[36,2275,171],{},[36,2277,2278],{},"UPGRADE_REQUIRE_SIGNATURE"," to a value other than ",[36,2281,2282],{},"true",[36,2284,2285],{},"false"," (in any case) or empty. A value such as ",[36,2288,2289],{},"yes",[36,2291,2292],{},"1",[36,2294,2295],{},"on"," may have been meant as ",[36,2298,2282],{},", so the installer's ",[36,2301,1574],{},[36,2303,1526],{}," stop before anything is downloaded rather than count it as off. ",[36,2306,1526],{}," stops on it before it resumes or abandons an upgrade too.",[14,2309,2310,2312,2313,300,2315,590,2317,2319,2320,2322],{},[71,2311,149],{}," Set it to ",[36,2314,2282],{},[36,2316,2285],{},[36,2318,171],{}," (see ",[264,2321,2232],{"href":2231},"), or remove the line, and run the command again.",[117,2324,2326],{"id":2325},"cannot-read-env-which-may-require-a-signature",[36,2327,2328],{},"Cannot read …\u002F.env, which may require a signature",[124,2330,2331],{},[14,2332,2333],{},[36,2334,2335],{},"error: Cannot read \u002Fhome\u002Fyou\u002Fbyodt\u002F.env, which may require a signature (UPGRADE_REQUIRE_SIGNATURE). Run this as the account that owns it. Nothing was changed.",[14,2337,2338,1647,2340],{},[36,2339,1526],{},[36,2341,2342],{},"byodt cannot read .env, which may require a signature (UPGRADE_REQUIRE_SIGNATURE). Run the upgrade as the account that owns it. Nothing was changed.",[14,2344,2345,2347,2348,2350,2351,2353],{},[71,2346,135],{}," The account running the upgrade cannot read the deployment's ",[36,2349,171],{},", so it cannot tell whether ",[36,2352,171],{}," requires a signature, and does not guess.",[14,2355,2356,2358],{},[71,2357,149],{}," Run the upgrade as the account that owns the deployment.",[117,2360,2362],{"id":2361},"setup-asks-its-questions-at-a-terminal",[36,2363,2364],{},"setup asks its questions at a terminal",[124,2366,2367],{},[14,2368,2369],{},[36,2370,2371],{},"error: setup asks its questions at a terminal. Without one, add --yes, with flags for anything other than the defaults ('.\u002Fbyodt setup --help'). Nothing was changed.",[14,2373,2374,2376,2377,2379,2380,380],{},[71,2375,149],{}," Run it at a terminal, or add ",[36,2378,1089],{}," and give the settings as flags. See ",[264,2381,2383,2384],{"href":2382},"\u002Fbyodt-cloud\u002Finstallation#set-up-with-byodt-setup","Installation → Set up with ",[36,2385,1131],{},[117,2387,2389],{"id":2388},"env-exists-this-folder-is-already-set-up",[36,2390,2391],{},".env exists: this folder is already set up",[124,2393,2394,2399],{},[14,2395,2396],{},[36,2397,2398],{},"error: .env exists: this folder is already set up. Edit .env, or move it aside to run setup again.",[14,2400,2401],{},[36,2402,2403],{},"error: .env.secrets exists: this folder has run before. Restore its .env instead of running setup, or move .env.secrets aside.",[14,2405,2406,2408,2409,2411],{},[71,2407,135],{}," Setup is the first run of a folder only. A folder with ",[36,2410,240],{}," has started before, and that file holds the database password its graph was created with.",[14,2413,2414,2416,2417,2419,2420,2424,2425,2427],{},[71,2415,149],{}," Edit ",[36,2418,171],{}," to change a setting (see ",[264,2421,2423],{"href":2422},"\u002Fbyodt-cloud\u002Fconfiguration","Configuration","). Do not move ",[36,2426,240],{}," aside while the folder holds a graph: the platform would be locked out of it.",[117,2429,2431],{"id":2430},"the-proxy-login-the-installer-was-given-is-not-saved",[36,2432,2433],{},"The proxy login the installer was given is not saved",[124,2435,2436],{},[14,2437,2438],{},[36,2439,2440],{},"warning: The proxy login the installer was given is not saved: add --proxy-login-from-env to save it, or put HTTPS_PROXY_USERINFO in .env.secrets yourself.",[14,2442,2443,2445,2446,2448],{},[71,2444,135],{}," Your shell's ",[36,2447,1820],{}," carried a login, which the installer used for its own download. Setup saves it into the deployment only when you say so: a shell's proxy login is often a personal or domain credential.",[14,2450,2451,2453,2454,296,2457,2459,2460,2464,2465,2468],{},[71,2452,149],{}," If the deployment should use it, add ",[36,2455,2456],{},"HTTPS_PROXY_USERINFO",[36,2458,240],{}," yourself (see ",[264,2461,2463],{"href":2462},"\u002Fbyodt-cloud\u002Fconfiguration#the-outbound-proxys-login","Configuration → The outbound proxy's login","). If the deployment has never been started, you can instead remove its folder and run the installer again with ",[36,2466,2467],{},"--proxy-login-from-env",". Running the installer again over the folder does not work: it refuses a folder that already holds a deployment.",[117,2470,2472],{"id":2471},"these-files-here-are-not-release-s-as-shipped",[36,2473,2474],{},"These files here are not release …'s as shipped",[124,2476,2477],{},[14,2478,2479],{},[36,2480,2481],{},"error: These files here are not release X.Y.Z's as shipped: compose.yaml. An upgrade replaces them. Local changes belong in compose.override.yaml, which no bundle ships; move them there, or add --replace-edited (they are kept in the backup). Nothing was changed.",[14,2483,2484,2486,2487,2490,2491,2494],{},[71,2485,135],{}," You edited a file that the old release shipped and the new release ships too, or a file of your own sits where the new release adds one. An upgrade replaces those files, so it stops before it changes anything. A file the new release no longer ships does not count, edited or not: it is left in place as it is, and listed as one the new release no longer ships. Neither does a ",[36,2488,2489],{},".DS_Store"," that macOS Finder leaves: the record of shipped files, ",[36,2492,2493],{},".byodt-release",", leaves it out.",[14,2496,2497,2499,2500,2319,2502,2504,2505,2508],{},[71,2498,149],{}," Move your change into ",[36,2501,697],{},[264,2503,723],{"href":722},") and put the file back as shipped, or add ",[36,2506,2507],{},"--replace-edited",": the edited file is replaced, and kept in the upgrade's backup.",[117,2510,2512],{"id":2511},"the-database-is-not-running-so-the-graph-cannot-be-backed-up-first",[36,2513,2514],{},"The database is not running, so the graph cannot be backed up first",[124,2516,2517],{},[14,2518,2519],{},[36,2520,2521],{},"error: The database is not running, so the graph cannot be backed up first. Start it ('.\u002Fbyodt up'), or add --skip-graph-backup. Nothing was changed.",[14,2523,2524,2526,2527,2530],{},[71,2525,149],{}," Start the deployment and run the upgrade again. Use ",[36,2528,2529],{},"--skip-graph-backup"," only when you have a backup of your own, or the graph does not matter: the rollback steps then have no graph to restore, and the database is not moved.",[14,2532,2533,2536,2537,2539,2540,2542,2543,2545,2546,380],{},[71,2534,2535],{},"On an upgrade from 0.12.x with 0.14.0's installer",", this message appears although the database is running: 0.14.0's ",[36,2538,480],{}," cannot read a 0.12.x folder's compose files until its own files have moved in, so its database check fails. With a ",[36,2541,697],{},", a warning that it could not read that file comes with it. Nothing was changed. Do not add ",[36,2544,2529],{},": upgrade with the installer of a release later than 0.14.0, as in ",[264,2547,2549],{"href":2548},"\u002Fbyodt-cloud\u002Foperations#upgrading-from-012x","Operations → Upgrading from 0.12.x",[117,2551,2553],{"id":2552},"failed-to-copy-the-snapshot-out-of-the-db-container",[36,2554,2555],{},"Failed to copy the snapshot out of the db container",[124,2557,2558],{},[14,2559,2560],{},[36,2561,2562],{},"error: Failed to copy the snapshot out of the db container.",[14,2564,2565,2567,2568,2570,2571,2573,2574,2577,2578,2580,2581,2584,2585,2588],{},[71,2566,135],{}," On an upgrade from 0.12.x or 0.13.0 of a Memgraph deployment, on Podman with ",[36,2569,1210],{},": the graph backup is taken by the old release's own ",[36,2572,480],{},", which copies with ",[36,2575,2576],{},"compose cp",", and ",[36,2579,1210],{}," has none. The upgrade stops with nothing changed. This release's ",[36,2582,2583],{},".\u002Fbyodt backup"," copies with the engine's own ",[36,2586,2587],{},"cp",", so elsewhere this message means the copy itself failed.",[14,2590,2591,2593,2594,2596,2597,380],{},[71,2592,149],{}," Take the snapshot by hand and upgrade with ",[36,2595,2529],{},", as in ",[264,2598,2600],{"href":2599},"\u002Fbyodt-cloud\u002Foperations#upgrading-on-podman","Operations → Upgrading on Podman",[117,2602,2604],{"id":2603},"only-mib-is-free-here",[36,2605,2606],{},"Only … MiB is free here",[124,2608,2609],{},[14,2610,2611],{},[36,2612,2613],{},"error: Only 1500 MiB is free here; an upgrade needs at least 2048 MiB for the new images and the backups. Nothing was changed.",[14,2615,2616,2618],{},[71,2617,149],{}," Free disk space on the file system that holds the deployment, then run the upgrade again.",[117,2620,2622],{"id":2621},"console_image-in-env-is-pinned-to-which-serves-neither",[36,2623,2624],{},"CONSOLE_IMAGE in .env is pinned to …, which serves neither …",[124,2626,2627],{},[14,2628,2629],{},[36,2630,2631],{},"error: CONSOLE_IMAGE in .env is pinned to …, which serves neither A nor B. Set its tag to B, or comment it out. Nothing was changed.",[14,2633,2634,509,2636,2638],{},[71,2635,135],{},[36,2637,1294],{}," points at a mirror with a tag of neither release. The upgrade retags a pin only when its tag is the old release.",[14,2640,2641,2643,2644,380],{},[71,2642,149],{}," Set the tag to the new release, or comment the line out so that the console image follows ",[36,2645,1298],{},[117,2647,2649],{"id":2648},"this-bundle-is-release-but-env-runs",[36,2650,2651],{},"This bundle is release …, but .env runs …",[124,2653,2654],{},[14,2655,2656],{},[36,2657,2658],{},"error: This bundle is release A, but .env runs B: an earlier upgrade by hand is half done. Finish or undo it first.",[14,2660,2661,509,2663,590,2665,2667],{},[71,2662,135],{},[36,2664,1298],{},[36,2666,171],{}," and the bundle's files name different releases: an upgrade by hand that set one but not the other.",[14,2669,2670,2672,2673,2677,2678,2680,2681,380],{},[71,2671,149],{}," Finish the hand upgrade (",[264,2674,2676],{"href":2675},"\u002Fbyodt-cloud\u002Foperations#upgrading-by-hand","Operations → Upgrading by hand","), or set ",[36,2679,1298],{}," back to the bundle's release, then run ",[36,2682,1526],{},[117,2684,2686],{"id":2685},"an-upgrade-asks-before-it-changes-anything-without-a-terminal-add-yes",[36,2687,2688],{},"An upgrade asks before it changes anything. Without a terminal, add --yes.",[124,2690,2691,2696],{},[14,2692,2693],{},[36,2694,2695],{},"error: An upgrade asks before it changes anything. Without a terminal, add --yes. Nothing was changed.",[14,2697,2698],{},[36,2699,2700],{},"error: '.\u002Fbyodt upgrade' with no version moves to the latest release. Without a terminal to confirm that, give the version or add --yes.",[14,2702,2703,2376,2705,2707,2708,380],{},[71,2704,149],{},[36,2706,1089],{}," and name the version. See ",[264,2709,2711],{"href":2710},"\u002Fbyodt-cloud\u002Foperations#without-a-terminal","Operations → Without a terminal",[117,2713,2715,1620,2718],{"id":2714},"already-on-is-older-than-a-downgrade-is-a-rollback-not-an-upgrade",[36,2716,2717],{},"Already on …",[36,2719,2720],{},"… is older than …: a downgrade is a rollback, not an upgrade",[124,2722,2723,2728],{},[14,2724,2725],{},[36,2726,2727],{},"error: Already on X.Y.Z. '.\u002Fbyodt update' applies it again.",[14,2729,2730],{},[36,2731,2732],{},"error: A is older than B: a downgrade is a rollback, not an upgrade. Roll back with the steps the upgrade to B printed, from its backup.",[14,2734,2735,2737,2738,380],{},[71,2736,149],{}," An upgrade only moves forward. To go back, run the rollback steps the earlier upgrade printed; see ",[264,2739,2741],{"href":2740},"\u002Fbyodt-cloud\u002Foperations#rolling-back-an-upgrade","Operations → Rolling back an upgrade",[117,2743,2745],{"id":2744},"an-upgrade-to-is-half-done",[36,2746,2747],{},"An upgrade to … is half done",[124,2749,2750],{},[14,2751,2752],{},[36,2753,2754],{},"error: An upgrade to B is half done (phase moved). Finish it with '.\u002Fbyodt upgrade', or undo it with '.\u002Fbyodt upgrade --abandon'.",[14,2756,2757,509,2759,74,2761,300,2763,2765,2766,380],{},[71,2758,135],{},[36,2760,352],{},[36,2762,902],{},[36,2764,905],{}," ran while an upgrade had moved the new files in but not yet applied them. Starting now would run the new files with the old ",[36,2767,171],{},[14,2769,2770,821,2772,2774,2775,719,2778,380],{},[71,2771,149],{},[36,2773,1526],{}," to finish it, or ",[36,2776,2777],{},".\u002Fbyodt upgrade --abandon",[264,2779,1691],{"href":1690},[117,2781,2783],{"id":2782},"byodt-upgradestate-is-not-this-deployments-own",[36,2784,2785],{},".byodt-upgrade.state is not this deployment's own",[124,2787,2788],{},[14,2789,2790],{},[36,2791,2792],{},"error: .byodt-upgrade.state is not this deployment's own (a link, another account's, or readable by others); byodt does not act on it. Check it, and remove it to drop the upgrade.",[14,2794,2795,2797,2798,2800,2801,74,2803,356,2805,2807,2808,380],{},[71,2796,135],{}," The upgrade's journal is not a regular file owned by you (or root) with mode 600. It names the folders an upgrade moves and removes, so ",[36,2799,480],{}," does not read it. ",[36,2802,352],{},[36,2804,902],{},[36,2806,905],{}," stop on it, whatever phase it names, and so does ",[36,2809,1526],{},[14,2811,2812,2814,2815,2818,2819,2821,2822,2825],{},[71,2813,149],{}," Look at it (",[36,2816,2817],{},"ls -l .byodt-upgrade.state","). If you do not know where it came from, remove it: that drops the upgrade, and the commands run again. If an upgrade had started moving its files in, roll back with the steps it printed, from its backup (see ",[264,2820,2741],{"href":2740},"). If it is your upgrade's own journal and only its mode changed, ",[36,2823,2824],{},"chmod 600 .byodt-upgrade.state"," lets the upgrade go on.",[117,2827,2829],{"id":2828},"the-new-files-were-being-moved-in-when-the-upgrade-stopped",[36,2830,2831],{},"The new files were being moved in when the upgrade stopped",[124,2833,2834],{},[14,2835,2836],{},[36,2837,2838],{},"error: The new files were being moved in when the upgrade stopped. Without a terminal, add --yes to finish the move, or run '.\u002Fbyodt upgrade --abandon' to put the old files back.",[14,2840,2841,2843,2844,2846,2847,2850,2851,2853],{},[71,2842,149],{}," At a terminal, ",[36,2845,1526],{}," asks which way to go. Without one, ",[36,2848,2849],{},".\u002Fbyodt upgrade --yes"," finishes the move and the upgrade; ",[36,2852,2777],{}," puts the old files back.",[117,2855,2857],{"id":2856},"another-upgrade-is-running-here",[36,2858,2859],{},"Another upgrade is running here",[124,2861,2862],{},[14,2863,2864],{},[36,2865,2866],{},"error: Another upgrade is running here (.byodt-upgrade.lock, process 12345). Wait for it. If none is running, remove .byodt-upgrade.lock (and .byodt-upgrade.lock.takeover, if it is there) and run the command again.",[14,2868,2869,2871,2872,2875],{},[71,2870,135],{}," Another upgrade holds the lock, or is taking it over. A lock that names no process yet (",[36,2873,2874],{},"process unknown",") counts as held: another upgrade may be taking it at that moment.",[14,2877,2878,2880,2881,2884,2885,2887],{},[71,2879,149],{}," Wait for the other upgrade. If no such process runs (",[36,2882,2883],{},"ps -p 12345","), or the message still says ",[36,2886,2874],{}," when you run the command again, remove the lock and the takeover lock beside it, if there is one, then run the command again:",[29,2889,2891],{"className":31,"code":2890,"language":33,"meta":34,"style":34},"rm -rf .byodt-upgrade.lock .byodt-upgrade.lock.takeover\n",[36,2892,2893],{"__ignoreMap":34},[39,2894,2895],{"class":41,"line":42},[39,2896,2890],{},[14,2898,2899],{},"A lock whose process has ended is normally taken over without this message.",[117,2901,2903],{"id":2902},"could-not-download-httpsget-byodtsh",[36,2904,2905],{},"Could not download https:\u002F\u002F…\u002Fget-byodt.sh",[124,2907,2908],{},[14,2909,2910],{},[36,2911,2912],{},"error: Could not download https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases\u002Fdownload\u002FvX.Y.Z\u002Fget-byodt.sh.",[14,2914,2915,509,2917,2919,2920,2922],{},[71,2916,135],{},[36,2918,1526],{}," reads the release's version and SHA-256 from that release's installer, and could not fetch it: there is no such release, the release publishes no installer, or the release host is not reachable (through the proxy ",[36,2921,171],{}," names, if any).",[14,2924,2925,2927],{},[71,2926,149],{}," Check the version on the releases page, and the network. Behind a TLS-inspecting proxy, the host's trust store must hold its CA.",[117,2929,2931],{"id":2930},"applying-failed",[36,2932,2933],{},"Applying … failed",[124,2935,2936],{},[14,2937,2938,2941],{},[36,2939,2940],{},"error: Applying B failed (above). If the pull failed, the old containers are still running. Fix what it names and run '.\u002Fbyodt upgrade' to go on, or roll back:"," followed by the rollback steps.",[14,2943,2944,2946,2947,716,2949,2951],{},[71,2945,135],{}," The upgrade moved the new files in and set ",[36,2948,171],{},[36,2950,355],{}," failed: most often an image pull (no route to the registry, or no proxy for the container engine). A failed pull leaves the old containers running.",[14,2953,2954,2956,2957,2959],{},[71,2955,149],{}," Fix what the output above names, then run ",[36,2958,1526],{},". It applies again from where it stopped. Or roll back with the printed steps.",[117,2961,2963],{"id":2962},"release-did-not-report-healthy-within-seconds",[36,2964,2965],{},"Release … did not report healthy within … seconds",[124,2967,2968],{},[14,2969,2970,2941],{},[36,2971,2972],{},"error: Release B did not report healthy within 1200 seconds. Still starting? '.\u002Fbyodt upgrade' checks again. To go back instead (everything since the backup is lost):",[14,2974,2975,2977,2978,2981],{},[71,2976,135],{}," After the apply, the platform or the front door was not healthy, or the console not running, within ",[36,2979,2980],{},"--health-timeout"," seconds. A first start after an upgrade can re-ingest the reference data and download the model, and take longer.",[14,2983,2984,2986,2987,356,2989,2991,2992,2994],{},[71,2985,149],{}," Look at ",[36,2988,88],{},[36,2990,768],{},". Then run ",[36,2993,1526],{}," to wait again, or roll back with the printed steps.",[117,2996,2998,3000,3001,3004],{"id":2997},"byodt-upgrade-xyz-on-012x-or-0130-prints-updated-and-stays-on-the-old-release",[36,2999,1646],{}," on 0.12.x or 0.13.0 prints ",[36,3002,3003],{},"Updated."," and stays on the old release",[29,3006,3009],{"className":3007,"code":3008,"language":178},[176],"==> Pulling the pinned images…\n==> Applying…\n==> Updated.\n",[36,3010,3008],{"__ignoreMap":34},[14,3012,3013,3015,3016,3018,3019,3021,3022,3024],{},[71,3014,135],{}," The ",[36,3017,480],{}," of releases 0.12.x and 0.13.0 has no upgrade: its ",[36,3020,921],{}," is another name for ",[36,3023,902],{},", and it ignores the version.",[14,3026,3027,3029,3030,3032,3033,300,3037,3039,3040,3042],{},[71,3028,149],{}," Upgrade with the new release's installer and ",[36,3031,1574],{},"; see ",[264,3034,3036],{"href":3035},"\u002Fbyodt-cloud\u002Foperations#upgrading-from-0130","Operations → Upgrading from 0.13.0",[264,3038,2549],{"href":2548},". From 0.12.x, use the installer of a release later than 0.14.0, not 0.14.0's. If that upgrade stopped before the first file moved in, the deployment still has the old release's ",[36,3041,480],{},": run the installer again, which takes the upgrade over.",[18,3044],{},[21,3046,3048],{"id":3047},"the-first-run","The first run",[117,3050,3052],{"id":3051},"it-is-taking-a-very-long-time","It is taking a very long time",[14,3054,3055,3057,3058,3061],{},[71,3056,135],{}," Normal, on a fresh machine and especially on a slow connection. The first start pulls four container images, downloads and verifies the module payloads, and ingests the reference corpus. The platform then downloads the embedding model's weights (about 1.26 GB) and ",[71,3059,3060],{},"embeds every class once, at about 0.2 s per class on a 4-vCPU host: seconds for the bundled modules (about 80 classes, 15–20 s), a few minutes with cloud content packages (about 1,200 classes). Matching uses names meanwhile."," The health checks are deliberately patient, so a slow start is waited out rather than failed, and the model download does not hold the start at all.",[14,3063,3064,3065,3067],{},"The first start after an upgrade from a release with the ",[36,3066,345],{}," service does the same model work once, and the one-shot also re-ingests the MITRE reference data, which takes about a minute with the platform down meanwhile.",[14,3069,3070,3072],{},[71,3071,149],{}," Watch it rather than restarting it:",[29,3074,3076],{"className":31,"code":3075,"language":33,"meta":34,"style":34},".\u002Fbyodt logs platform         # the model download, load, and class embedding\n.\u002Fbyodt logs console-init     # modules and the data ingest\n",[36,3077,3078,3083],{"__ignoreMap":34},[39,3079,3080],{"class":41,"line":42},[39,3081,3082],{},".\u002Fbyodt logs platform         # the model download, load, and class embedding\n",[39,3084,3085],{"class":41,"line":48},[39,3086,3087],{},".\u002Fbyodt logs console-init     # modules and the data ingest\n",[14,3089,3090,3091,3093],{},"Restarting mid-pull only starts the downloads again. Next time, ",[36,3092,359],{}," downloads the model ahead of the start.",[117,3095,3097],{"id":3096},"matching-uses-names-after-a-start","Matching uses names after a start",[14,3099,3100,3102,3103,3106,3107,3110,3111,3114,3115,74,3118,78,3121,3124,3125,3128,3129,3132],{},[71,3101,734],{}," Class matching and MITRE technique search find entries only by name, not by meaning. In the standalone configuration, ",[36,3104,3105],{},"curl -fsS http:\u002F\u002F127.0.0.1:3000\u002Fhealth"," reports ",[36,3108,3109],{},"\"status\": \"degraded\"",", and its ",[36,3112,3113],{},"services.embedder.state"," is ",[36,3116,3117],{},"downloading",[36,3119,3120],{},"loading",[36,3122,3123],{},"failed",". Or ",[36,3126,3127],{},"\u002Fhealth"," already reports ",[36,3130,3131],{},"healthy",", but class matching still finds classes only by name.",[14,3134,3135,3137],{},[71,3136,135],{}," The platform serves while it downloads the model's weights and loads the model, and while it embeds the classes; name matching answers meanwhile.",[737,3139,3140,3160,3178],{},[740,3141,3142,509,3145,356,3147,3149,3150,3152,3153,3156,3157,3159],{},[71,3143,3144],{},"The embedder is not ready.",[36,3146,3117],{},[36,3148,3120],{}," are normal after a first start or an upgrade. ",[36,3151,3123],{}," means the download or the load gave up. The ",[36,3154,3155],{},"error"," beside the state, and ",[36,3158,768],{},", give the reason.",[740,3161,3162,509,3165,3106,3167,3169,3170,3173,3174,3177],{},[71,3163,3164],{},"The classes are still embedding.",[36,3166,3127],{},[36,3168,3131],{}," once the log says ",[36,3171,3172],{},"Embedder ready",", but the classes may still be embedding then, at about 0.2 s per class on a 4-vCPU host. Class matching uses names until they are done; the log shows ",[36,3175,3176],{},"Embeddings resolved"," for each module as its classes are.",[740,3179,3180,3183,3184,3186,3187,3189,3190,3193],{},[71,3181,3182],{},"A download that keeps failing looks normal at first."," The state stays ",[36,3185,3117],{}," while the platform retries: after 10 seconds, 30 seconds, 2 minutes, 10 minutes and 30 minutes, about 42 minutes in all. Only then does it turn ",[36,3188,3123],{},", and the embedder stays off until the platform restarts. Meanwhile the platform log shows ",[36,3191,3192],{},"weight acquisition failed, retrying",", with the reason.",[14,3195,3196],{},[71,3197,149],{},[737,3199,3200,3215,3245],{},[740,3201,3202,3203,300,3205,3207,3208,3210,3211,716,3213,380],{},"For ",[36,3204,3117],{},[36,3206,3120],{},", wait, and follow ",[36,3209,768],{}," until it logs ",[36,3212,3172],{},[36,3214,3176],{},[740,3216,3217,3218,3220,3221,3223,3224,3227,3228,3230,3231,3233,3234,3238,3239,3241,3242,3244],{},"If the platform log shows ",[36,3219,3192],{},", or the state is ",[36,3222,3123],{}," after a download, the cause is almost always the network: the platform needs to reach ",[36,3225,3226],{},"huggingface.co"," and the host it redirects downloads to, directly or through the proxy ",[36,3229,1820],{}," names in ",[36,3232,171],{},". The error names the host that failed. Fix the host's network access (behind a proxy, see ",[264,3235,3237],{"href":3236},"#behind-an-outbound-proxy","Behind an outbound proxy","), then ",[36,3240,762],{},". Running ",[36,3243,359],{}," first shows whether the download now works.",[740,3246,3247,3248,3250,3251,3254,3255,3258,3259,3262,3263,3267],{},"On a host without internet access, run ",[36,3249,359],{}," on a connected machine and copy its ",[36,3252,3253],{},"data\u002Fmodels"," over as the account that runs ",[36,3256,3257],{},".\u002Fbyodt",", keeping its ",[36,3260,3261],{},"\u003Crepo>\u002F\u003Crevision>\u002F\u003Cfile>"," layout; see ",[264,3264,3266],{"href":3265},"\u002Fbyodt-cloud\u002Finstallation#optional-download-the-embedding-model-ahead","Installation → Download the embedding model ahead",". The platform verifies every file's sha256 and downloads only what is missing or wrong.",[117,3269,3271,300,3274],{"id":3270},"in-the-models-directory-is-owned-by-uid-or-is-writable-by-accounts-other-than-its-owner",[36,3272,3273],{},"in the models directory is owned by uid",[36,3275,3276],{},"is writable by accounts other than its owner",[124,3278,3279,3284],{},[14,3280,3281],{},[36,3282,3283],{},"The weights could not be placed: config.json: onnx-community in the models directory is owned by uid 65534, which is not the platform's, root's or the models directory's owner; remove it and place the weights again (the platform downloads them on its start; in the BYODt bundle, .\u002Fbyodt models pull)",[14,3285,3286],{},[36,3287,3288],{},"… onnx-community\u002Fembeddinggemma-300m-ONNX in the models directory is writable by accounts other than its owner; remove it and place the weights again (…)",[14,3290,3291,3293,3294,3296,3297,3299,3300,3302,3303,3305,3306,3308,3309,3311,3312,3314,3315,380],{},[71,3292,135],{}," A file or directory in ",[36,3295,3253],{},", on the path to one of the model's files, is one another local account could change: it is owned by an account other than the platform's, root or the owner of ",[36,3298,3253],{},", or accounts other than its owner (its group, or every account) can write to it. The platform checks each weight file and then loads it, so it refuses such a file rather than load a model someone else could have swapped in. The usual source is a ",[36,3301,3253],{}," copied from another machine under a different account or as root, or unpacked with group- or world-writable permissions. ",[36,3304,359],{}," prints the message; the platform logs it as ",[36,3307,3192],{}," and, once it gives up, reports it as the embedder's ",[36,3310,3155],{},". The named entry is relative to ",[36,3313,3253],{},". The uid is the one the platform sees inside its container: under rootless Podman, an account other than yours, root included, usually shows as ",[36,3316,3317],{},"65534",[14,3319,3320,3322,3323,3325],{},[71,3321,149],{}," Remove the named entry and place the weights again (",[36,3324,470],{}," may be needed when another account owns it):",[29,3327,3329],{"className":31,"code":3328,"language":33,"meta":34,"style":34},"sudo rm -rf data\u002Fmodels\u002Fonnx-community\n.\u002Fbyodt models pull\n",[36,3330,3331,3336],{"__ignoreMap":34},[39,3332,3333],{"class":41,"line":42},[39,3334,3335],{},"sudo rm -rf data\u002Fmodels\u002Fonnx-community\n",[39,3337,3338],{"class":41,"line":48},[39,3339,3340],{},".\u002Fbyodt models pull\n",[14,3342,3343,3344,3346,3347,3032,3349,3351,3352,3355,3356,380],{},"On a host without internet access, copy the weights again as the account that runs ",[36,3345,3257],{}," instead of running ",[36,3348,1994],{},[264,3350,3266],{"href":3265},". If the entry is your own and only too widely writable, ",[36,3353,3354],{},"chmod -R go-w data\u002Fmodels\u002F\u003Centry>"," is enough: the platform still checks every file's sha256 before it loads it. Then ",[36,3357,762],{},[14,3359,3360,3361,3364,3365,3367,3368,3370],{},"If the message names the models directory itself (",[36,3362,3363],{},"the models directory is writable by accounts other than its owner without the sticky bit","), run ",[36,3366,352],{},": it makes ",[36,3369,3253],{}," sticky again.",[117,3372,3374,3377],{"id":3373},"the-data-ingest-failed-with-a-memory-limit",[36,3375,3376],{},"the data ingest failed"," with a memory limit",[124,3379,3380],{},[14,3381,3382,3385],{},[71,3383,3384],{},"Ingest Failed"," — the data ingest failed — the deployment runs without the MITRE corpus: memory limit exceeded (…) — the database needs a larger memory limit (Memgraph's --memory-limit, set in the bundle's compose.memgraph.yaml; override it in compose.override.yaml); this is terminal and was not retried: …",[14,3387,3388,3389,380],{},"On Neo4j the middle reads ",[36,3390,3391],{},"the database needs more memory (Neo4j's heap, NEO4J_HEAP_SIZE in the bundle's .env)",[14,3393,3394,3396,3397,3400,3401,3404],{},[71,3395,135],{}," The database ran out of memory partway through the reference-data ingest. Memgraph is started with a 4096 MiB limit, which is the measured floor for this ingest; Neo4j parses the large ingest statements on its heap, ",[36,3398,3399],{},"NEO4J_HEAP_SIZE"," (default ",[36,3402,3403],{},"2G","). Either can only use memory the container engine is actually able to give it.",[14,3406,3407,3409,3410,590,3412,3414,3415,3418,3419,3422],{},[71,3408,149],{}," On Neo4j, raise ",[36,3411,3399],{},[36,3413,171],{}," (for example to ",[36,3416,3417],{},"3G","). On either engine, make sure the container engine can give the database that memory. On a VM-backed runtime, one that runs containers in a virtual machine (such as Docker Desktop, or a Podman machine on macOS or Windows), the constraint is the ",[71,3420,3421],{},"virtual machine's"," memory allocation, not the host's. Raise it to comfortably more than 4 GB, then re-run the one-shot:",[29,3424,3426],{"className":31,"code":3425,"language":33,"meta":34,"style":34},".\u002Fbyodt restart\n",[36,3427,3428],{"__ignoreMap":34},[39,3429,3430],{"class":41,"line":42},[39,3431,3425],{},[14,3433,3434,3435,3438,3439,3442],{},"The ingest re-runs because the corpus is not yet recorded as loaded. Confirm the console's ",[71,3436,3437],{},"Data ingest"," panel reads ",[36,3440,3441],{},"ok"," and the statement count is no longer zero.",[14,3444,3445,3446,590,3449,3451,3452,3455,3456,3458,3459,3462,3463,74,3465,3468,3469,3471],{},"To raise Memgraph's limit itself, set ",[36,3447,3448],{},"--memory-limit",[36,3450,697],{},". A ",[36,3453,3454],{},"command:"," there replaces the db service's whole ",[36,3457,3454],{}," list rather than merging into it, so repeat every flag from ",[36,3460,3461],{},"compose.memgraph.yaml","'s ",[36,3464,3454],{},[36,3466,3467],{},"--telemetry-enabled=false"," included, and change only ",[36,3470,3448],{}," (the value is in MiB):",[29,3473,3477],{"className":3474,"code":3475,"language":3476,"meta":34,"style":34},"language-yaml shiki shiki-themes github-light github-dark-dimmed","services:\n  db:\n    command:\n      - \"--bolt-num-workers=4\"\n      - \"--query-plan-cache-max-size=100\"\n      - \"--query-execution-timeout-sec=600\"\n      - \"--query-max-plans=100\"\n      - \"--cartesian-product-enabled=true\"\n      - \"--storage-gc-cycle-sec=300\"\n      - \"--storage-snapshot-interval-sec=${SNAPSHOT_INTERVAL_SEC:-300}\"\n      - \"--memory-limit=6144\"\n      - \"--query-vertex-count-to-expand-existing=10\"\n      - \"--telemetry-enabled=false\"\n","yaml",[36,3478,3479,3489,3496,3503,3512,3520,3528,3536,3544,3552,3560,3568,3576],{"__ignoreMap":34},[39,3480,3481,3485],{"class":41,"line":42},[39,3482,3484],{"class":3483},"sIAta","services",[39,3486,3488],{"class":3487},"sYgZi",":\n",[39,3490,3491,3494],{"class":41,"line":48},[39,3492,3493],{"class":3483},"  db",[39,3495,3488],{"class":3487},[39,3497,3498,3501],{"class":41,"line":54},[39,3499,3500],{"class":3483},"    command",[39,3502,3488],{"class":3487},[39,3504,3505,3508],{"class":41,"line":1493},[39,3506,3507],{"class":3487},"      - ",[39,3509,3511],{"class":3510},"s-HuK","\"--bolt-num-workers=4\"\n",[39,3513,3515,3517],{"class":41,"line":3514},5,[39,3516,3507],{"class":3487},[39,3518,3519],{"class":3510},"\"--query-plan-cache-max-size=100\"\n",[39,3521,3523,3525],{"class":41,"line":3522},6,[39,3524,3507],{"class":3487},[39,3526,3527],{"class":3510},"\"--query-execution-timeout-sec=600\"\n",[39,3529,3531,3533],{"class":41,"line":3530},7,[39,3532,3507],{"class":3487},[39,3534,3535],{"class":3510},"\"--query-max-plans=100\"\n",[39,3537,3539,3541],{"class":41,"line":3538},8,[39,3540,3507],{"class":3487},[39,3542,3543],{"class":3510},"\"--cartesian-product-enabled=true\"\n",[39,3545,3547,3549],{"class":41,"line":3546},9,[39,3548,3507],{"class":3487},[39,3550,3551],{"class":3510},"\"--storage-gc-cycle-sec=300\"\n",[39,3553,3555,3557],{"class":41,"line":3554},10,[39,3556,3507],{"class":3487},[39,3558,3559],{"class":3510},"\"--storage-snapshot-interval-sec=${SNAPSHOT_INTERVAL_SEC:-300}\"\n",[39,3561,3563,3565],{"class":41,"line":3562},11,[39,3564,3507],{"class":3487},[39,3566,3567],{"class":3510},"\"--memory-limit=6144\"\n",[39,3569,3571,3573],{"class":41,"line":3570},12,[39,3572,3507],{"class":3487},[39,3574,3575],{"class":3510},"\"--query-vertex-count-to-expand-existing=10\"\n",[39,3577,3579,3581],{"class":41,"line":3578},13,[39,3580,3507],{"class":3487},[39,3582,3583],{"class":3510},"\"--telemetry-enabled=false\"\n",[14,3585,3586,3588,3589,2319,3591,3593,3594,3596,3597,3599,3600,3602,3603,3605],{},[36,3587,480],{}," loads the override after ",[36,3590,3461],{},[264,3592,723],{"href":722},"). ",[36,3595,520],{}," recreates the stack with it, and the ingest runs again. The override is loaded on either engine, so remove this ",[36,3598,1426],{}," block before you switch to Neo4j. A bundle upgrade leaves the override alone, so compare its ",[36,3601,3454],{}," list with ",[36,3604,3461],{},"'s after each upgrade.",[117,3607,3609],{"id":3608},"the-module-release-channel-was-unreachable",[36,3610,3611],{},"the module release channel was unreachable",[124,3613,3614],{},[14,3615,3616,3619],{},[71,3617,3618],{},"Module Fetch Failed"," — the module release channel was unreachable — no code modules were installed",[14,3621,3622,3624,3625,3627],{},[71,3623,135],{}," The one-shot could not reach the release host to download the module payloads. A firewall, a proxy, an offline machine, or a transient outage. ",[36,3626,752],{}," gives the exact error.",[14,3629,3630,3632,3633,3636,3637,3639],{},[71,3631,149],{}," Give the machine access to ",[36,3634,3635],{},"github.com"," and its release-asset host (behind a proxy, see ",[264,3638,3237],{"href":3236},", which lists the errors a proxy produces here), then re-run the one-shot:",[29,3641,3642],{"className":31,"code":3425,"language":33,"meta":34,"style":34},[36,3643,3644],{"__ignoreMap":34},[39,3645,3646],{"class":41,"line":42},[39,3647,3425],{},[14,3649,3650,3651,3654,3655,380],{},"Verify in the console that ",[71,3652,3653],{},"Modules"," now shows each module ",[36,3656,3657],{},"placed",[117,3659,3661],{"id":3660},"the-named-release-carries-no-module-assets",[36,3662,3663],{},"the named release carries no module assets",[124,3665,3666],{},[14,3667,3668,3670],{},[71,3669,3618],{}," — the named release carries no module assets — no code modules were installed",[14,3672,3673,3675,3676,3678,3679,3681],{},[71,3674,135],{}," The release named by ",[36,3677,1298],{}," exists but has no module payloads at that version. Usually ",[36,3680,1298],{}," has been set to a version that was never published, or to one whose assets are not available.",[14,3683,3684,619,3686,3688,3689,3694,3695,380],{},[71,3685,149],{},[36,3687,1298],{}," to a published release — check the ",[264,3690,3693],{"href":3691,"rel":3692},"https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases",[2123],"releases page"," — then ",[36,3696,355],{},[117,3698,3700],{"id":3699},"a-module-signature-did-not-verify",[36,3701,3702],{},"a module signature did not verify",[124,3704,3705],{},[14,3706,3707,3709],{},[71,3708,3618],{}," — a module signature did not verify — the module was rejected",[14,3711,3712,3714],{},[71,3713,135],{}," A downloaded payload did not verify against the signing identity pinned to that exact release. The module was rejected rather than installed. Possible causes: a corrupted or truncated download, a proxy or other device on the path that modifies the content it passes on, or an artifact that genuinely is not the published one.",[14,3716,3717,3718,1761],{},"TLS inspection alone does not cause this. A proxy that inspects TLS, with its CA trusted, re-encrypts the same bytes, and the signature is checked offline, against a trusted root embedded in the console image. Without its CA trusted, the download does not happen at all, and the console reports an unreachable release channel instead (see ",[264,3719,3237],{"href":3236},[14,3721,3722,3724],{},[71,3723,149],{}," This is a security event — do not work around it.",[1453,3726,3727,3733,3736],{},[740,3728,3729,3730,3732],{},"Re-run the one-shot (",[36,3731,520],{},") in case the download was simply corrupt.",[740,3734,3735],{},"If it persists, check whether something between the machine and the release host modifies the content it passes on.",[740,3737,3738,3739,380],{},"Verify the bundle you are running is the published one, using the signature check in ",[264,3740,3742],{"href":3741},"\u002Fbyodt-cloud\u002Finstallation#get-the-bundle","Installation",[117,3744,3746,1620,3749],{"id":3745},"some-modules-installed-and-some-failed-every-module-failed-to-install",[36,3747,3748],{},"some modules installed and some failed",[36,3750,3751],{},"every module failed to install",[14,3753,3754,3756],{},[71,3755,135],{}," Partial or total install failure, for a reason recorded per module.",[14,3758,3759,3761,3762,3764,3765,3767,3768,3770],{},[71,3760,149],{}," Open the console's ",[71,3763,3653],{}," table on the Overview tab. Each row shows its outcome, and a failed row carries the specific reason. ",[36,3766,752],{}," has the full record. Then ",[36,3769,520],{}," to retry.",[117,3772,3774],{"id":3773},"the-init-one-shot-has-not-written-its-state",[36,3775,3776],{},"the init one-shot has not written its state",[124,3778,3779],{},[14,3780,3781,3784],{},[71,3782,3783],{},"Init Not Run"," — the init one-shot has not written its state — it may not have run yet",[14,3786,3787,3789],{},[71,3788,135],{}," The console is running but the one-shot has not finished — normal during the first minutes of a first start. If it persists, the one-shot never ran or could not write its state file.",[14,3791,3792,3794],{},[71,3793,149],{}," Wait, then check:",[29,3796,3798],{"className":31,"code":3797,"language":33,"meta":34,"style":34},".\u002Fbyodt status                # did console-init run? what was its exit code?\n.\u002Fbyodt logs console-init\n",[36,3799,3800,3805],{"__ignoreMap":34},[39,3801,3802],{"class":41,"line":42},[39,3803,3804],{},".\u002Fbyodt status                # did console-init run? what was its exit code?\n",[39,3806,3807],{"class":41,"line":48},[39,3808,1262],{},[14,3810,3811,3812,380],{},"If it never ran, ",[36,3813,352],{},[18,3815],{},[21,3817,3237],{"id":3818},"behind-an-outbound-proxy",[14,3820,3821,3822,3826,3827,380],{},"The setup is in ",[264,3823,3825],{"href":3824},"\u002Fbyodt-cloud\u002Finstallation#behind-an-outbound-proxy","Installation → Behind an outbound proxy",", and the reference in ",[264,3828,3830],{"href":3829},"\u002Fbyodt-cloud\u002Fconfiguration#outbound-proxy","Configuration → Outbound proxy",[14,3832,3833],{},[71,3834,3835],{},"Where the errors show.",[3837,3838,3844],"div",{"className":3839,"tabIndex":3841,"role":3842,"ariaLabel":3843},[3840],"table-frame",0,"region","Table: Behind an outbound proxy",[3845,3846,3847,3860],"table",{},[3848,3849,3850],"thead",{},[3851,3852,3853,3857],"tr",{},[3854,3855,3856],"th",{},"From",[3854,3858,3859],{},"Where to read it",[3861,3862,3863,3877,3894],"tbody",{},[3851,3864,3865,3871],{},[3866,3867,3868,3870],"td",{},[36,3869,480],{}," itself",[3866,3872,3873,3874,380],{},"The terminal, before anything starts. Its messages mask any login as ",[36,3875,3876],{},"***",[3851,3878,3879,3884],{},[3866,3880,3881,3883],{},[36,3882,92],{}," (the module downloads)",[3866,3885,3886,3888,3889,666,3891,380],{},[36,3887,752],{},". The console then shows ",[71,3890,3618],{},[3892,3893,3611],"em",{},[3851,3895,3896,3899],{},[3866,3897,3898],{},"The platform (the model download, cloud content, sign-in keys)",[3866,3900,3901,3903,3904,380],{},[36,3902,768],{},", and the output of ",[36,3905,359],{},[14,3907,3908,3909,356,3912,3915,3916,3919,3920,3923],{},"In the messages below, ",[36,3910,3911],{},"\u003Cproxy-host>",[36,3913,3914],{},"\u003Cport>"," stand for your proxy's name and port, ",[36,3917,3918],{},"\u003Cdns-server>"," for the resolver the containers use, and ",[36,3921,3922],{},"X.Y.Z"," for the release.",[14,3925,3926,3929],{},[71,3927,3928],{},"Test the proxy from the host"," before you look at the deployment. This asks the proxy for one of the hosts the first start needs:",[29,3931,3933],{"className":31,"code":3932,"language":33,"meta":34,"style":34},"curl -sSI -x http:\u002F\u002F\u003Cproxy-host>:\u003Cport> https:\u002F\u002Fhuggingface.co\n",[36,3934,3935],{"__ignoreMap":34},[39,3936,3937],{"class":41,"line":42},[39,3938,3932],{},[14,3940,3941,3942,3945,3946,3948,3949,3952,3953,3955],{},"If the proxy needs a login, add ",[36,3943,3944],{},"-U 'user'",": curl then asks for the password, which keeps it off the command line. curl takes the user name and the password as they are, not percent-encoded as in ",[36,3947,2456],{},". An ",[36,3950,3951],{},"HTTP\u002F1.1 200"," line for the tunnel, then the site's own answer, means the proxy lets the host through. The host can resolve ",[36,3954,3911],{}," differently from the containers, so a pass here does not settle a name-resolution error in the deployment.",[117,3957,3959,3961],{"id":3958},"byodt-refuses-the-proxy-setting",[36,3960,480],{}," refuses the proxy setting",[14,3963,3964,3966,3967,356,3969,590,3972,74,3974,590,3976,2577,3978,3981],{},[36,3965,480],{}," checks ",[36,3968,1820],{},[36,3970,3971],{},"NO_PROXY",[36,3973,171],{},[36,3975,2456],{},[36,3977,240],{},[36,3979,3980],{},"proxy-ca\u002F",", before anything starts. Each refusal says what to change; the common ones:",[3837,3983,3986],{"className":3984,"tabIndex":3841,"role":3842,"ariaLabel":3985},[3840],"Table: byodt refuses the proxy setting",[3845,3987,3988,3998],{},[3848,3989,3990],{},[3851,3991,3992,3995],{},[3854,3993,3994],{},"Message (beginning)",[3854,3996,3997],{},"Fix",[3861,3999,4000,4010,4027,4048,4062,4076,4086,4096,4108,4118,4130,4142],{},[3851,4001,4002,4007],{},[3866,4003,4004],{},[36,4005,4006],{},"error: HTTPS_PROXY in .env is http:\u002F\u002F\u003Cproxy-host>: it needs the proxy's port, as http:\u002F\u002Fhost:port.",[3866,4008,4009],{},"Add the port.",[3851,4011,4012,4017],{},[3866,4013,4014],{},[36,4015,4016],{},"error: HTTPS_PROXY in .env is …: write it as http:\u002F\u002Fhost:port",[3866,4018,4019,4020,300,4023,4026],{},"Use ",[36,4021,4022],{},"http:\u002F\u002F",[36,4024,4025],{},"https:\u002F\u002F",", a numeric port, and nothing after the port.",[3851,4028,4029,4034],{},[3866,4030,4031],{},[36,4032,4033],{},"error: HTTPS_PROXY in .env carries a login (…)",[3866,4035,4036,4037,4039,4040,4042,4043,4045,4046,380],{},"Remove ",[36,4038,1811],{}," from ",[36,4041,171],{},", and put the login in ",[36,4044,240],{}," as ",[36,4047,2456],{},[3851,4049,4050,4055],{},[3866,4051,4052],{},[36,4053,4054],{},"error: HTTPS_PROXY in .env is …: inside a container, … is the container itself.",[3866,4056,4057,4058,4061],{},"Do not use ",[36,4059,4060],{},"localhost"," or a loopback address. Use the host's address on the network the proxy listens on.",[3851,4063,4064,4069],{},[3866,4065,4066],{},[36,4067,4068],{},"error: HTTPS_PROXY in .env is …: inside the stack, … is one of its own services.",[3866,4070,4071,4072,4075],{},"The name is one of the deployment's services, such as ",[36,4073,4074],{},"proxy"," (the front door). Use the proxy's full name or its address.",[3851,4077,4078,4083],{},[3866,4079,4080],{},[36,4081,4082],{},"error: NO_PROXY in .env has …: address ranges and wildcards are not read the same way by every service. List the hosts.",[3866,4084,4085],{},"Replace the block, range or wildcard with the exact hosts.",[3851,4087,4088,4093],{},[3866,4089,4090],{},[36,4091,4092],{},"error: NO_PROXY in .env has a space: separate its entries with commas only.",[3866,4094,4095],{},"Remove the spaces.",[3851,4097,4098,4103],{},[3866,4099,4100],{},[36,4101,4102],{},"error: HTTPS_PROXY_USERINFO in .env.secrets must be user:password with one colon, …",[3866,4104,4105,4106,380],{},"Percent-encode the user name and the password; see ",[264,4107,2463],{"href":2462},[3851,4109,4110,4115],{},[3866,4111,4112],{},[36,4113,4114],{},"error: HTTPS_PROXY_USERINFO in .env.secrets is quoted: …",[3866,4116,4117],{},"Remove the quotes.",[3851,4119,4120,4125],{},[3866,4121,4122],{},[36,4123,4124],{},"error: proxy-ca\u002F holds …: it holds only proxy-ca.pem, …",[3866,4126,4127,4128,380],{},"Move every other file out of ",[36,4129,3980],{},[3851,4131,4132,4137],{},[3866,4133,4134],{},[36,4135,4136],{},"error: proxy-ca\u002Fproxy-ca.pem is not readable by every account, …",[3866,4138,4139],{},[36,4140,4141],{},"chmod 0644 proxy-ca\u002Fproxy-ca.pem",[3851,4143,4144,4149],{},[3866,4145,4146],{},[36,4147,4148],{},"error: … can be changed by other accounts, and what is in it is trusted as a root.",[3866,4150,4151,4154],{},[36,4152,4153],{},"chmod go-w"," on the named path.",[14,4156,4157],{},"These warnings do not stop the start:",[737,4159,4160,4169,4184],{},[740,4161,4162,4165,4166,4168],{},[36,4163,4164],{},"warning: HTTP_PROXY in .env is not used: …"," — the deployment sends only HTTPS through the proxy. Set ",[36,4167,1820],{}," instead.",[740,4170,4171,4174,4175,4177,4178,4180,4181,4183],{},[36,4172,4173],{},"warning: HTTPS_PROXY_USERINFO in .env.secrets is not used: .env sets no HTTPS_PROXY."," — set ",[36,4176,1820],{},", or remove the login. ",[36,4179,3971],{}," without ",[36,4182,1820],{}," gets the same warning.",[740,4185,4186,4189,4190,380],{},[36,4187,4188],{},"warning: HTTPS_PROXY in .env is https:\u002F\u002F…: the stack talks to the proxy itself over TLS. …"," — see ",[264,4191,4193,4194,4196],{"href":4192},"#a-tls-handshake-error-with-an-https-proxy-url","A TLS handshake error with an ",[36,4195,4025],{}," proxy URL",[117,4198,4200],{"id":4199},"your-shell-sets-https_proxy-the-stack-uses-only-the-one-in-env",[36,4201,4202],{},"Your shell sets HTTPS_PROXY (…); the stack uses only the one in .env (…)",[124,4204,4205],{},[14,4206,4207],{},[36,4208,4209],{},"==> Your shell sets HTTPS_PROXY (…); the stack uses only the one in .env (…). Set HTTPS_PROXY in .env to change it.",[14,4211,4212,4214,4215,4217,4218,4220,4221,4223],{},[71,4213,135],{}," A notice, not an error. Your shell exports a proxy that ",[36,4216,171],{}," does not name. ",[36,4219,480],{}," never adopts the shell's: the deployment uses only ",[36,4222,171],{},"'s, so an upgrade does not start sending it through a proxy it worked without.",[14,4225,4226,4228,4229,590,4231,4233,4234,4236,4237,4239,4240,4242],{},[71,4227,149],{}," If the deployment should use that proxy, set ",[36,4230,1820],{},[36,4232,171],{}," and run ",[36,4235,352],{},". Otherwise, ignore the notice. ",[36,4238,480],{}," compares the two values as text, so a shell URL that carries a login always differs from ",[36,4241,171],{},"'s, which never does. If both name the same proxy, unset it in your shell after getting the bundle.",[117,4244,4246],{"id":4245},"warning-https_proxy-is-set-in-env-but-the-docker-daemon-has-no-proxy-of-its-own",[36,4247,4248],{},"warning: HTTPS_PROXY is set in .env, but the Docker daemon has no proxy of its own",[124,4250,4251],{},[14,4252,4253],{},[36,4254,4255],{},"warning: HTTPS_PROXY is set in .env, but the Docker daemon has no proxy of its own, so image pulls go direct. If this host has no direct route out, set the daemon's proxy (a systemd drop-in, or \"proxies\" in daemon.json), restart it, and run the command again.",[14,4257,4258,4260,4261,356,4263,4265,4266,4268,4269,4271],{},[71,4259,135],{}," On Docker, ",[36,4262,352],{},[36,4264,355],{}," check the daemon's own proxy before they pull. The daemon pulls the images, and it never reads ",[36,4267,171],{}," or your shell. ",[36,4270,480],{}," does not check Podman's setting.",[14,4273,4274,4276,4277,4281],{},[71,4275,149],{}," If the host has no direct route out, give the daemon a proxy, restart it, and run the command again; see ",[264,4278,4280],{"href":4279},"\u002Fbyodt-cloud\u002Finstallation#_1-give-the-container-engine-the-proxy","Installation → Give the container engine the proxy",". If the images come from a registry mirror on your own network, ignore the warning.",[117,4283,4285],{"id":4284},"proxy-authentication-required",[36,4286,4287],{},"Proxy Authentication Required",[124,4289,4290],{},[14,4291,4292],{},[36,4293,4294],{},"fetching modules.json: Get \"https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases\u002Fdownload\u002FvX.Y.Z\u002Fmodules.json\": Proxy Authentication Required",[14,4296,4297,4298,4300],{},"from ",[36,4299,92],{},", and from the platform:",[124,4302,4303,4308],{},[14,4304,4305],{},[36,4306,4307],{},"Failed to establish tunnel to \u003Chost>:443 via http:\u002F\u002F\u003Cproxy-host>:\u003Cport>\u002F: HTTP\u002F1.1 407 Proxy Authentication Required",[14,4309,4310,4313,4314,4317],{},[36,4311,4312],{},"Request was cancelled."," (code ",[36,4315,4316],{},"UND_ERR_ABORTED",")",[14,4319,4320,4322,4323,4325,4326,4329,4330,4332,4333,4335,4336,4339,4340,4342,4343,1761],{},[71,4321,135],{}," The proxy refused the login (HTTP 407): ",[36,4324,2456],{}," is missing, wrong, or encoded wrongly. Of the platform's two texts, the first comes from its core HTTPS client, which in cloud mode fetches the keys sign-ins are checked against. The second comes from its ",[36,4327,4328],{},"fetch"," client, which the model download uses, and carries no 407 at all: behind a proxy that needs a login, a ",[36,4331,4312],{}," can be this. ",[36,4334,359],{}," may not show even that: it prints ",[36,4337,4338],{},"request to \u003Chost> failed:"," with the error's message only, and the cause appears in ",[36,4341,768],{}," when the platform downloads the model itself (see ",[264,4344,4346],{"href":4345},"#the-model-download-names-a-host-that-fails","The model download names a host that fails",[14,4348,4349,4351,4352,4354,4355,4357,4358,2577,4360,4362],{},[71,4350,149],{}," Check the user name and the password in ",[36,4353,240],{},", and the percent-encoding of every character outside the allowed set (see ",[264,4356,2463],{"href":2462},"). Then ",[36,4359,352],{},[36,4361,359],{}," to test.",[117,4364,4366],{"id":4365},"proxyconnect-tcp-no-such-host",[36,4367,4368],{},"proxyconnect tcp: … no such host",[124,4370,4371],{},[14,4372,4373],{},[36,4374,4375],{},"proxyconnect tcp: dial tcp: lookup \u003Cproxy-host> on \u003Cdns-server>:53: no such host",[14,4377,4378,4380,4381,4383,4384,380],{},[71,4379,135],{}," The containers cannot resolve the proxy's name. The stack still comes up, but ",[36,4382,92],{}," cannot download the modules, and the console reports ",[71,4385,3618],{},[14,4387,4388,4390,4391,716,4393,4395,4396,4398,4399,4401,4402,4405,4406,380],{},[71,4389,149],{}," Use a name the containers can resolve, or an address, in ",[36,4392,171],{},[36,4394,352],{},". If the name was right and the proxy was only away, run ",[36,4397,520],{}," once it is back: ",[36,4400,92],{}," runs again and installs the modules, and the platform, which reads ",[36,4403,4404],{},"modules\u002F"," only when it starts, starts after it. A proxy that is down but whose name still resolves gives a refused connection or a timeout instead; see ",[264,4407,4409],{"href":4408},"#the-proxy-is-down-when-the-deployment-starts","The proxy is down when the deployment starts",[117,4411,4413],{"id":4412},"context-deadline-exceeded-clienttimeout-exceeded-while-awaiting-headers",[36,4414,4415],{},"context deadline exceeded (Client.Timeout exceeded while awaiting headers)",[124,4417,4418],{},[14,4419,4420],{},[36,4421,4415],{},[14,4423,4424,4426,4427,4429],{},[71,4425,135],{}," The proxy accepts connections but does not answer. ",[36,4428,92],{}," waits its full 60 seconds on every run, then records the failure, so each start takes about a minute longer. The stack still comes up, without the modules this run should have installed.",[14,4431,4432,4434,4435,356,4437,4440,4441,2078,4444,4447,4448,4450,4451,830],{},[71,4433,149],{}," The fix is on the proxy: ask its operators why it holds connections to ",[36,4436,3635],{},[36,4438,4439],{},"release-assets.githubusercontent.com",". The ",[264,4442,4443],{"href":3236},"host test above",[36,4445,4446],{},"https:\u002F\u002Fgithub.com",", shows the same hang. Once it is fixed, ",[36,4449,520],{}," runs ",[36,4452,92],{},[117,4454,4456],{"id":4455},"service-unavailable",[36,4457,4458],{},"Service Unavailable",[124,4460,4461],{},[14,4462,4463],{},[36,4464,4465],{},"…modules.json\": Service Unavailable",[14,4467,4468,4470],{},[71,4469,135],{}," The proxy answered HTTP 503: it could not reach the destination itself, often because it could not resolve its name. The deployment's side of the connection worked.",[14,4472,4473,4475,4476,4479,4480,4450,4482,830],{},[71,4474,149],{}," The fix is on the proxy. A proxy on an isolated network may need its own name servers set (in squid, ",[36,4477,4478],{},"dns_nameservers","). Once it is fixed, ",[36,4481,520],{},[36,4483,92],{},[117,4485,4487,300,4490],{"id":4486},"self-signed-certificate-in-certificate-chain-or-x509-certificate-signed-by-unknown-authority",[36,4488,4489],{},"self-signed certificate in certificate chain",[36,4491,4492],{},"x509: certificate signed by unknown authority",[124,4494,4495],{},[14,4496,4497,4313,4499,4317],{},[36,4498,4489],{},[36,4500,4501],{},"SELF_SIGNED_CERT_IN_CHAIN",[14,4503,4504,4505,172],{},"from the platform, and from ",[36,4506,92],{},[124,4508,4509],{},[14,4510,4511],{},[36,4512,4513],{},"tls: failed to verify certificate: x509: certificate signed by unknown authority",[14,4515,4516,4517,4520,4521,4523],{},"With other certificate chains, the platform may report ",[36,4518,4519],{},"UNABLE_TO_GET_ISSUER_CERT_LOCALLY"," instead. The console, written in Go like ",[36,4522,92],{},", fails the same way on its cloud calls.",[14,4525,4526,4528],{},[71,4527,135],{}," The proxy inspects TLS: it re-signs every HTTPS connection with a CA of its own, and the deployment does not trust that CA.",[14,4530,4531,4533,4534,4537,4538,4540,4541,4543,4544,4546,4547,4549,4550,4552,4553,4556,4557,4561],{},[71,4532,149],{}," First ask the proxy's operators to pass the identity provider and the content service through uninspected. If they cannot, put the proxy's CA certificate in ",[36,4535,4536],{},"proxy-ca\u002Fproxy-ca.pem",", and run ",[36,4539,352],{},". If the file was already there and you replaced it, how to apply it depends on which service reported the error. When ",[36,4542,92],{}," did, or the console shows ",[71,4545,3618],{},", run ",[36,4548,520],{},": a restart that names services recreates only those, so ",[36,4551,92],{}," would not run again. When only the platform's or the console's own calls failed, ",[36,4554,4555],{},".\u002Fbyodt restart platform console"," is enough. Read what trusting it hands over first: ",[264,4558,4560],{"href":4559},"\u002Fbyodt-cloud\u002Fconfiguration#a-proxy-that-inspects-tls","Configuration → A proxy that inspects TLS",". The file must hold the CA that signs the proxy's certificates, not a certificate the proxy presents for one site.",[14,4563,4564,4565,380],{},"Image pulls through the same proxy fail the same way. The container engine needs the CA in the host's trust store and a restart; see ",[264,4566,4280],{"href":4279},[117,4568,4193,4570,4196],{"id":4569},"a-tls-handshake-error-with-an-https-proxy-url",[36,4571,4025],{},[14,4573,4574,4576,4577,590,4579,4581,4582,4584,4585,4587],{},[71,4575,734],{}," Every call through the proxy fails with a TLS handshake error, before any request is made. ",[36,4578,1820],{},[36,4580,171],{}," starts with ",[36,4583,4025],{},". Without a login, ",[36,4586,480],{}," warned about it:",[124,4589,4590],{},[14,4591,4592],{},[36,4593,4594],{},"warning: HTTPS_PROXY in .env is https:\u002F\u002F\u003Cproxy-host>:\u003Cport>: the stack talks to the proxy itself over TLS. Most proxies take http:\u002F\u002F here, and still carry HTTPS end to end.",[14,4596,4597,509,4599,4601,4602,4604,4605,4607],{},[71,4598,135],{},[36,4600,4025],{}," in the proxy URL is how the services talk to the proxy itself. A proxy that speaks plain HTTP on that port cannot complete the handshake. With a login set, ",[36,4603,480],{}," does not warn, because ",[36,4606,4025],{}," is what keeps the login off the network in clear.",[14,4609,4610,4612,4613,4615,4616,380],{},[71,4611,149],{}," Use ",[36,4614,4022],{}," unless the proxy's operators say it takes TLS on that port, then ",[36,4617,352],{},[117,4619,4346],{"id":4620},"the-model-download-names-a-host-that-fails",[124,4622,4623],{},[14,4624,4625],{},[36,4626,4627],{},"The weights could not be placed: \u003Cfile>: request to \u003Chost> failed: …",[14,4629,4630,4632,4633,4636,4637,4639,4640,4642,4643,4646,4647,74,4650,2577,4653,380],{},[36,4631,359],{}," prints this, and only this: for a network failure the end is ",[36,4634,4635],{},"fetch failed",", without the underlying cause. When the platform downloads the model itself, on a start, ",[36,4638,768],{}," shows the same error on each ",[36,4641,3192],{}," entry, with the cause beside it as ",[36,4644,4645],{},"cause",". The download's other network errors name the host the same way: ",[36,4648,4649],{},"download failed with HTTP \u003Cstatus> from \u003Chost>",[36,4651,4652],{},"no response from \u003Chost> within 30 s",[36,4654,4655],{},"no data from \u003Chost> for 60 s",[14,4657,4658,4660,4661,4663],{},[71,4659,135],{}," The download could not get through to the named host. The model hub redirects each download to another host, and a proxy that allows ",[36,4662,3226],{}," but not that host fails here.",[14,4665,4666,4668,4669,4671,4672,590,4674,3364,4676,4678],{},[71,4667,149],{}," Ask for the named host to be allowed, then run ",[36,4670,359],{}," again. If the platform has already given up (",[36,4673,3123],{},[36,4675,3127],{},[36,4677,762],{}," after that.",[117,4680,4409],{"id":4681},"the-proxy-is-down-when-the-deployment-starts",[14,4683,4684,4687,4688,4690,4691,4693,4694,89,4696,4698],{},[71,4685,4686],{},"On a first start",", the stack comes up, but ",[36,4689,92],{}," cannot download the modules: the console reports ",[71,4692,3618],{},", and no code modules are installed. If the model's weights are not on disk yet, the platform retries the download for about 42 minutes. Once the proxy is back, run ",[36,4695,520],{},[36,4697,92],{}," installs the modules, and the platform starts after it, loads them, and downloads the weights if they are still missing.",[14,4700,4701,4704,4705,4707,4708,4710],{},[71,4702,4703],{},"On a later start",", the modules and the weights are already on disk. ",[36,4706,92],{}," cannot reach the release host and the console reports ",[71,4709,3618],{},", but the modules already installed stay in use. In cloud mode, sign-in and the content service need the proxy: the platform fetches the keys sign-ins are checked against through it, so sign-ins fail until the proxy is back.",[18,4712],{},[21,4714,4716],{"id":4715},"the-console","The console",[117,4718,4720,4721,300,4723],{"id":4719},"verdict-shows-degraded-or-fault","Verdict shows ",[71,4722,77],{},[71,4724,81],{},[14,4726,4727,509,4729,4731,4732,4734],{},[71,4728,135],{},[71,4730,81],{}," means the deployment is not delivering its product: modules could not be fetched, modules were placed but never registered, or the reference data is missing. ",[71,4733,77],{}," means something milder — the platform is restarting, or the one-shot has not reported yet.",[14,4736,4737,4739],{},[71,4738,149],{}," Read the banners above the tabs. Each one is a specific problem with its own entry on this page.",[117,4741,4743],{"id":4742},"the-console-placed-modules-the-platform-did-not-register",[36,4744,4745],{},"the console placed modules the platform did not register",[124,4747,4748],{},[14,4749,4750,4753,4754],{},[71,4751,4752],{},"Fewer Modules Registered"," — the console placed modules the platform did not register\nModules: ",[36,4755,4756],{},"…",[14,4758,4759,4761],{},[71,4760,135],{}," The one-shot installed the named modules onto disk, but the platform did not load them at startup. This is the deployment's characteristic failure, and it is only detectable after the platform is running — the one-shot exits before that.",[14,4763,4764],{},[71,4765,149],{},[29,4767,4769],{"className":31,"code":4768,"language":33,"meta":34,"style":34},".\u002Fbyodt logs platform\n",[36,4770,4771],{"__ignoreMap":34},[39,4772,4773],{"class":41,"line":42},[39,4774,4768],{},[14,4776,4777],{},"Look for module-loading errors naming the modules in the banner. Then recreate the platform so it re-scans the modules directory:",[29,4779,4781],{"className":31,"code":4780,"language":33,"meta":34,"style":34},".\u002Fbyodt restart platform\n",[36,4782,4783],{"__ignoreMap":34},[39,4784,4785],{"class":41,"line":42},[39,4786,4780],{},[14,4788,4789],{},"If they still do not register, capture the platform log — it names the reason each module was rejected.",[117,4791,4793],{"id":4792},"the-platform-is-not-reachable",[36,4794,4795],{},"the platform is not reachable",[124,4797,4798],{},[14,4799,4800,4803],{},[71,4801,4802],{},"Platform Unreachable"," — the platform is not reachable — module registration could not be checked",[14,4805,4806,4807,380],{},"The top-right badge also reads ",[71,4808,4809],{},"Platform unreachable",[14,4811,4812,4814],{},[71,4813,135],{}," The console cannot reach the platform. Expected for a short window during any recreate. Otherwise the platform is down or unhealthy.",[14,4816,4817],{},[71,4818,149],{},[29,4820,4822],{"className":31,"code":4821,"language":33,"meta":34,"style":34},".\u002Fbyodt status\n.\u002Fbyodt logs platform\n",[36,4823,4824,4829],{"__ignoreMap":34},[39,4825,4826],{"class":41,"line":42},[39,4827,4828],{},".\u002Fbyodt status\n",[39,4830,4831],{"class":41,"line":48},[39,4832,4768],{},[14,4834,4835,4836,4838],{},"If the platform is not running, ",[36,4837,352],{},". If it is running but unhealthy, its log says why — a database it cannot reach is the usual reason.",[117,4840,4842],{"id":4841},"could-not-load-deployment-state",[36,4843,4844],{},"Could not load deployment state",[14,4846,4847,4849],{},[71,4848,135],{}," The console reached its own daemon but a request failed — for example the one-shot's state file exists but cannot be read.",[14,4851,4852,4854],{},[71,4853,149],{}," The console retries automatically and clears the banner on the next successful poll. If it persists:",[29,4856,4858],{"className":31,"code":4857,"language":33,"meta":34,"style":34},".\u002Fbyodt logs console\n.\u002Fbyodt restart console\n",[36,4859,4860,4865],{"__ignoreMap":34},[39,4861,4862],{"class":41,"line":42},[39,4863,4864],{},".\u002Fbyodt logs console\n",[39,4866,4867],{"class":41,"line":48},[39,4868,4869],{},".\u002Fbyodt restart console\n",[117,4871,4873],{"id":4872},"could-not-reach-the-console-reload-to-retry",[36,4874,4875],{},"Could not reach the console. Reload to retry.",[14,4877,4878,4880],{},[71,4879,135],{}," The console daemon is not answering, or the front door cannot reach it.",[14,4882,4883],{},[71,4884,149],{},[29,4886,4888],{"className":31,"code":4887,"language":33,"meta":34,"style":34},".\u002Fbyodt status\n.\u002Fbyodt restart console\n",[36,4889,4890,4894],{"__ignoreMap":34},[39,4891,4892],{"class":41,"line":42},[39,4893,4828],{},[39,4895,4896],{"class":41,"line":48},[39,4897,4869],{},[14,4899,4900],{},"Then confirm the daemon answers directly:",[29,4902,4904],{"className":31,"code":4903,"language":33,"meta":34,"style":34},"curl -fsS http:\u002F\u002F127.0.0.1:3000\u002Fconsole\u002Fhealthz\n",[36,4905,4906],{"__ignoreMap":34},[39,4907,4908],{"class":41,"line":42},[39,4909,4903],{},[117,4911,4913],{"id":4912},"the-console-session-keeps-ending-reload-to-retry",[36,4914,4915],{},"The console session keeps ending. Reload to retry.",[14,4917,4918,4920],{},[71,4919,135],{}," The console's sessions live in memory, so restarting the console daemon invalidates them. The page recovers on its own once or twice; if it keeps happening, the daemon is restarting repeatedly.",[14,4922,4923],{},[71,4924,149],{},[29,4926,4928],{"className":31,"code":4927,"language":33,"meta":34,"style":34},".\u002Fbyodt status               # is `console` restarting?\n.\u002Fbyodt logs console\n",[36,4929,4930,4935],{"__ignoreMap":34},[39,4931,4932],{"class":41,"line":42},[39,4933,4934],{},".\u002Fbyodt status               # is `console` restarting?\n",[39,4936,4937],{"class":41,"line":48},[39,4938,4864],{},[117,4940,4942],{"id":4941},"a-banner-says-a-change-is-not-yet-applied","A banner says a change is not yet applied",[124,4944,4945],{},[14,4946,4947,4950,4951],{},[71,4948,4949],{},"Cloud configuration not yet applied"," — recreate the stack to apply it: ",[36,4952,4953],{},"byodt restart",[14,4955,4956],{},"or",[124,4958,4959],{},[14,4960,4961,4964,4965],{},[71,4962,4963],{},"Revert to pure open-source not yet applied"," — recreate the stack to complete it: ",[36,4966,4953],{},[14,4968,4969,4971],{},[71,4970,135],{}," The console has written a configuration change that the platform is not yet running. This is informational, not a fault.",[14,4973,4974],{},[71,4975,149],{},[29,4977,4978],{"className":31,"code":3425,"language":33,"meta":34,"style":34},[36,4979,4980],{"__ignoreMap":34},[39,4981,4982],{"class":41,"line":42},[39,4983,3425],{},[14,4985,4986],{},"The banner clears once the platform comes back in the new mode.",[18,4988],{},[21,4990,4992],{"id":4991},"the-front-door","The front door",[117,4994,4996],{"id":4995},"_502-bad-gateway",[36,4997,4998],{},"502 Bad Gateway",[14,5000,5001,5003],{},[71,5002,135],{}," The front door is up but the platform behind it is not. This is by design: the proxy resolves the platform at request time, so a platform outage produces a 502 rather than a proxy that refuses to start at all.",[14,5005,5006],{},[71,5007,149],{},[29,5009,5010],{"className":31,"code":4821,"language":33,"meta":34,"style":34},[36,5011,5012,5016],{"__ignoreMap":34},[39,5013,5014],{"class":41,"line":42},[39,5015,4828],{},[39,5017,5018],{"class":41,"line":48},[39,5019,4768],{},[14,5021,5022],{},"During a recreate, wait — the platform has a start-up grace period before it is considered healthy.",[117,5024,5026],{"id":5025},"connection-refused","Connection refused",[14,5028,5029,5031],{},[71,5030,135],{}," The front door itself is not running, or it is bound to an address you are not connecting from. By default it binds to loopback only, so it is unreachable from another machine.",[14,5033,5034],{},[71,5035,149],{},[29,5037,5039],{"className":31,"code":5038,"language":33,"meta":34,"style":34},".\u002Fbyodt status\ncurl -fsS http:\u002F\u002F127.0.0.1:3000\u002Fhealthz     # expect: ok\n",[36,5040,5041,5045],{"__ignoreMap":34},[39,5042,5043],{"class":41,"line":42},[39,5044,4828],{},[39,5046,5047],{"class":41,"line":48},[39,5048,5049],{},"curl -fsS http:\u002F\u002F127.0.0.1:3000\u002Fhealthz     # expect: ok\n",[14,5051,5052,5053,5056,5057,5059],{},"To reach it from elsewhere, change ",[36,5054,5055],{},"FRONT_DOOR_BIND"," — and read the exposure warning in ",[264,5058,873],{"href":872}," first.",[117,5061,5063],{"id":5062},"https-is-not-served-after-generating-a-certificate","HTTPS is not served after generating a certificate",[14,5065,5066,5068],{},[71,5067,135],{}," The certificate was written, but the front door has not been recreated. It reads the certificate directory when its container starts, and adding files to a mounted directory does not by itself recreate anything.",[14,5070,5071],{},[71,5072,149],{},[29,5074,5076],{"className":31,"code":5075,"language":33,"meta":34,"style":34},".\u002Fbyodt tls status            # confirm the certificate is there\n.\u002Fbyodt restart proxy\n",[36,5077,5078,5083],{"__ignoreMap":34},[39,5079,5080],{"class":41,"line":42},[39,5081,5082],{},".\u002Fbyodt tls status            # confirm the certificate is there\n",[39,5084,5085],{"class":41,"line":48},[39,5086,5087],{},".\u002Fbyodt restart proxy\n",[14,5089,5090,5091,380],{},"Then browse to the same address over ",[36,5092,4025],{},[117,5094,5096],{"id":5095},"_400-bad-request-the-plain-http-request-was-sent-to-an-https-port",[36,5097,5098],{},"400 Bad Request — The plain HTTP request was sent to an HTTPS port",[14,5100,5101,5103,5104,5106],{},[71,5102,135],{}," A certificate is installed, so the port now serves HTTPS, but you connected over ",[36,5105,4022],{},". The port number does not change when TLS is enabled — the protocol does.",[14,5108,5109,4612,5111,5113,5114,5117,5118,5120,5121,5123],{},[71,5110,149],{},[36,5112,4025],{}," at the same address. Note that ",[36,5115,5116],{},".\u002Fbyodt console"," and the messages printed by ",[36,5119,352],{}," always show an ",[36,5122,4022],{}," address, so adjust the scheme yourself.",[117,5125,5127],{"id":5126},"the-browser-warns-that-the-certificate-is-not-trusted","The browser warns that the certificate is not trusted",[14,5129,5130,509,5132,5135],{},[71,5131,135],{},[36,5133,5134],{},".\u002Fbyodt tls generate"," produces a self-signed certificate. It encrypts the connection and makes the page a secure context; it does not attest identity, so browsers warn.",[14,5137,5138,5140,5141,356,5144,590,5147,5150,5151,380],{},[71,5139,149],{}," Accept it for a deployment you run yourself, or install a certificate from a certificate authority your browser trusts by placing ",[36,5142,5143],{},"cert.pem",[36,5145,5146],{},"key.pem",[36,5148,5149],{},"tls\u002F"," and running ",[36,5152,5153],{},".\u002Fbyodt restart proxy",[117,5155,5157],{"id":5156},"openssl-is-required-to-generate-a-certificate",[36,5158,5159],{},"openssl is required to generate a certificate",[14,5161,5162,509,5164,5167,5168,5171],{},[71,5163,135],{},[36,5165,5166],{},"openssl"," is not on the host's ",[36,5169,5170],{},"PATH",". Certificate generation runs on the host, not in a container.",[14,5173,5174,5176,5177,5179,5180,356,5182,5184,5185,380],{},[71,5175,149],{}," Install ",[36,5178,5166],{},", or generate the certificate elsewhere and copy ",[36,5181,5143],{},[36,5183,5146],{}," into ",[36,5186,5149],{},[18,5188],{},[21,5190,5192],{"id":5191},"the-database-and-backups","The database and backups",[117,5194,5196],{"id":5195},"database-is-not-reachable-running-credentials-right",[36,5197,5198],{},"Database is not reachable (running? credentials right?)",[14,5200,5201,509,5203,5205],{},[71,5202,135],{},[36,5204,2583],{}," probes the database before doing anything, on either engine, and the probe failed.",[14,5207,5208],{},[71,5209,149],{},[29,5211,5212],{"className":31,"code":4828,"language":33,"meta":34,"style":34},[36,5213,5214],{"__ignoreMap":34},[39,5215,5216],{"class":41,"line":42},[39,5217,4828],{},[14,5219,5220,5221,5223,5224,380],{},"If the database is not running, ",[36,5222,352],{},". If it is running but the probe fails on credentials, see ",[264,5225,267],{"href":266},[117,5227,5229],{"id":5228},"no-snapshot-available-to-back-up",[36,5230,5231],{},"No snapshot available to back up",[14,5233,5234,5236],{},[71,5235,135],{}," Memgraph only. The database neither produced a new snapshot nor has an existing one to copy — this is effectively an empty or very newly created database.",[14,5238,5239,5241,5242,5244],{},[71,5240,149],{}," Confirm the deployment is actually holding data — the console's ",[71,5243,3437],{}," panel shows the statement count from the reference ingest beneath its status. If the graph really is empty, there is nothing to back up yet.",[117,5246,5248,1620,5251],{"id":5247},"the-database-container-is-not-running-more-than-one-database-container-of-this-project-is-running",[36,5249,5250],{},"The database container is not running",[36,5252,5253],{},"More than one database container of this project is running",[124,5255,5256,5261],{},[14,5257,5258],{},[36,5259,5260],{},"error: The database container is not running; start it with '.\u002Fbyodt up'.",[14,5262,5263],{},[36,5264,5265],{},"error: More than one database container of this project is running ('.\u002Fbyodt status'); stop the extra one first.",[14,5267,5268,5270,5271,356,5273,5275,5276,5278,5279,300,5282,5285],{},[71,5269,135],{}," Memgraph only. ",[36,5272,915],{},[36,5274,918],{}," copy the snapshot with the container engine's own ",[36,5277,2587],{}," (",[36,5280,5281],{},"docker cp",[36,5283,5284],{},"podman cp","), into or out of the deployment's one running database container, found by its compose labels.",[14,5287,5288,5290,5291,5293,5294,5296,5297,5300],{},[71,5289,149],{}," Start the deployment (",[36,5292,352],{},"), or, for the second message, find the extra container with ",[36,5295,88],{}," and your engine's ",[36,5298,5299],{},"ps",", and stop it.",[117,5302,5304],{"id":5303},"could-not-make-private-to-you",[36,5305,5306],{},"Could not make … private to you",[124,5308,5309],{},[14,5310,5311],{},[36,5312,5313],{},"warning: Could not make backups\u002Fbyodt-snapshot-….snapshot private to you (its file system may not keep modes); keep it where only you can read it.",[14,5315,5316,5318],{},[71,5317,135],{}," Memgraph only. A backup's snapshot is made readable by you only once it is copied out, and the file system it was written to does not keep file modes, as some network and removable file systems do not.",[14,5320,5321,5323,5324,380],{},[71,5322,149],{}," The backup itself is complete. Keep it in a folder only you can read, or write backups to a file system that keeps modes: ",[36,5325,5326],{},".\u002Fbyodt backup \u002Fpath\u002Fto\u002Fdir",[117,5328,5330],{"id":5329},"that-backup-was-taken-on-version-x-this-deployment-is-y",[36,5331,5332],{},"That backup was taken on version X; this deployment is Y",[14,5334,5335,5337],{},[71,5336,135],{}," A warning, not an error. The filename records the version the backup was taken on, and it differs from what this deployment runs. Snapshots and dumps are version-sensitive and may not load across versions.",[14,5339,5340,5342],{},[71,5341,149],{}," Prefer restoring onto the version the backup was taken on. On Memgraph, if you continue and the restore fails, the current graph is left unchanged — nothing is lost by trying. On Neo4j a failed load can leave the current graph gone, so take a backup of it first.",[117,5344,5346,1620,5349],{"id":5345},"is-a-neo4j-dump-this-deployment-runs-memgraph-is-a-memgraph-snapshot-this-deployment-runs-neo4j",[36,5347,5348],{},"… is a Neo4j dump; this deployment runs Memgraph",[36,5350,5351],{},"… is a Memgraph snapshot; this deployment runs Neo4j",[124,5353,5354],{},[14,5355,5356],{},[36,5357,5358],{},"error: backups\u002F….dump is a Neo4j dump; this deployment runs Memgraph, which restores its own snapshots only.",[14,5360,5361,5363],{},[71,5362,135],{}," The backup was made by the other database engine. Each engine restores only its own format, and nothing converts between them.",[14,5365,5366,5368],{},[71,5367,149],{}," Restore a backup taken on this engine. To use that backup, restore it onto a deployment that runs the engine it came from.",[117,5370,5372],{"id":5371},"recover-snapshot-failed-the-current-graph-was-left-unchanged",[36,5373,5374],{},"RECOVER SNAPSHOT failed — the current graph was left unchanged",[14,5376,5377,5379],{},[71,5378,135],{}," Memgraph refused the snapshot. A version mismatch is the usual reason; a truncated or corrupt file is the other.",[14,5381,5382,5384],{},[71,5383,149],{}," Try a different snapshot, or pin the deployment back to the version the snapshot was taken on and restore there. Your current graph is intact either way.",[117,5386,5388],{"id":5387},"neo4j-admin-could-not-dump-the-database",[36,5389,5390],{},"neo4j-admin could not dump the database",[124,5392,5393],{},[14,5394,5395],{},[36,5396,5397],{},"error: neo4j-admin could not dump the database. If it says the store needs recovery, the database did not shut down cleanly: start it ('.\u002Fbyodt up'), let it finish starting, and run the backup again.",[14,5399,5400,5402,5403,5406,5407,5409],{},[71,5401,135],{}," Neo4j only. ",[36,5404,5405],{},"neo4j-admin"," refuses to dump a store that was not shut down cleanly; its own output above the message says why. ",[36,5408,480],{}," starts the database again either way.",[14,5411,5412,5414,5415,5417,5418,1423,5420,5422,5423,830],{},[71,5413,149],{}," Do what the message says: ",[36,5416,352],{},", wait until ",[36,5419,88],{},[36,5421,1426],{}," healthy, then ",[36,5424,2583],{},[117,5426,5428],{"id":5427},"neo4j-admin-could-not-load-the-dump",[36,5429,5430],{},"neo4j-admin could not load the dump",[124,5432,5433],{},[14,5434,5435],{},[36,5436,5437],{},"error: neo4j-admin could not load the dump — see its output above. The load replaces the graph, so the current one may be gone: restore again from a backup you know is good.",[14,5439,5440,5402,5442,5444,5445,5409],{},[71,5441,135],{},[36,5443,5405],{}," failed while loading the dump; its own output above the message says why. A version mismatch and a truncated or corrupt file are the usual reasons. The load replaces the graph, so unlike on Memgraph the current graph may already be gone. ",[36,5446,480],{},[14,5448,5449,5451],{},[71,5450,149],{}," Restore again from a backup you know is good — preferably one taken on the version this deployment runs. If the failed file was taken on another version, pin the deployment to that version and restore it there.",[117,5453,5455],{"id":5454},"could-not-copy-the-dump-to",[36,5456,5457],{},"Could not copy the dump to …",[124,5459,5460],{},[14,5461,5462],{},[36,5463,5464],{},"error: Could not copy the dump to backups\u002F….dump.",[14,5466,5467,5469,5470,5472],{},[71,5468,135],{}," Neo4j only. The dump was written, but ",[36,5471,480],{}," could not copy it into the destination directory — usually a directory you cannot write, or a full disk. The private working directory, with the dump in it, is removed on the way out, so nothing is left behind.",[14,5474,5475,5477,5478,5480],{},[71,5476,149],{}," Make sure the destination directory is writable by you and has room for the graph, then run ",[36,5479,2583],{}," again. The database is started again either way.",[117,5482,5484],{"id":5483},"could-not-start-the-database-start-it-with-byodt-up",[36,5485,5486],{},"Could not start the database — start it with '.\u002Fbyodt up'",[124,5488,5489],{},[14,5490,5491],{},[36,5492,5493],{},"warning: Could not start the database — start it with '.\u002Fbyodt up'.",[14,5495,5496,5498],{},[71,5497,135],{}," Neo4j only. A backup or restore stopped the database, and starting it again failed.",[14,5500,5501],{},[71,5502,149],{},[29,5504,5506],{"className":31,"code":5505,"language":33,"meta":34,"style":34},".\u002Fbyodt up\n.\u002Fbyodt logs db\n",[36,5507,5508,5512],{"__ignoreMap":34},[39,5509,5510],{"class":41,"line":42},[39,5511,217],{},[39,5513,5514],{"class":41,"line":48},[39,5515,5516],{},".\u002Fbyodt logs db\n",[117,5518,5520],{"id":5519},"after-a-restore-the-app-shows-old-or-empty-data","After a restore the app shows old or empty data",[14,5522,5523,5525],{},[71,5524,135],{}," The platform is holding state from before the restore.",[14,5527,5528,5530],{},[71,5529,149],{}," The restore command tells you this too:",[29,5532,5533],{"className":31,"code":4780,"language":33,"meta":34,"style":34},[36,5534,5535],{"__ignoreMap":34},[39,5536,5537],{"class":41,"line":42},[39,5538,4780],{},[117,5540,5542],{"id":5541},"aborted-nothing-was-changed",[36,5543,5544],{},"Aborted — nothing was changed",[14,5546,5547,5549,5550,380],{},[71,5548,135],{}," The restore confirmation was not typed exactly as ",[36,5551,918],{},[14,5553,5554,5556,5557,5559],{},[71,5555,149],{}," Run it again and type ",[36,5558,918],{}," at the prompt.",[18,5561],{},[21,5563,5565],{"id":5564},"cloud-connect-and-sign-in","Cloud connect and sign-in",[117,5567,5569],{"id":5568},"the-recipe-is-rejected","The recipe is rejected",[14,5571,5572],{},"The message names the problem exactly:",[3837,5574,5577],{"className":5575,"tabIndex":3841,"role":3842,"ariaLabel":5576},[3840],"Table: The recipe is rejected",[3845,5578,5579,5591],{},[3848,5580,5581],{},[3851,5582,5583,5586,5589],{},[3854,5584,5585],{},"Message",[3854,5587,5588],{},"Cause",[3854,5590,3997],{},[3861,5592,5593,5606,5619,5632],{},[3851,5594,5595,5600,5603],{},[3866,5596,5597],{},[36,5598,5599],{},"line N is not NAME=value: …",[3866,5601,5602],{},"A line in the paste is not a setting — usually stray text or a wrapped line.",[3866,5604,5605],{},"Re-copy the whole recipe and paste it unmodified.",[3851,5607,5608,5613,5616],{},[3866,5609,5610],{},[36,5611,5612],{},"X appears more than once",[3866,5614,5615],{},"The same setting is present twice, usually from pasting twice.",[3866,5617,5618],{},"Clear the box and paste once.",[3851,5620,5621,5626,5629],{},[3866,5622,5623],{},[36,5624,5625],{},"recipe is missing required variables: …",[3866,5627,5628],{},"The paste is incomplete. A partial recipe would boot the deployment into a broken state, so it is refused outright.",[3866,5630,5631],{},"Re-copy the whole recipe.",[3851,5633,5634,5639,5642],{},[3866,5635,5636],{},[36,5637,5638],{},"recipe carries variables the console will not write: …",[3866,5640,5641],{},"The paste contains settings outside the accepted set. The whole apply is refused rather than partially honoured.",[3866,5643,5644],{},"Paste the recipe exactly as issued, with nothing added.",[117,5646,5648],{"id":5647},"this-deployment-is-already-cloud-configured",[36,5649,5650],{},"this deployment is already cloud-configured",[124,5652,5653],{},[14,5654,5655],{},[36,5656,5657],{},"this deployment is already cloud-configured — disconnect from the cloud before reconfiguring",[14,5659,5660,5662],{},[71,5661,135],{}," A cloud configuration is already written. Reconfiguring over it is refused, so a mistake cannot leave the deployment half-configured.",[14,5664,5665,5667,5668,5671,5672,5675,5676,5678,5679,380],{},[71,5666,149],{}," Click ",[71,5669,5670],{},"Disconnect from cloud",", in the ",[71,5673,5674],{},"Disconnect"," section at the foot of the Cloud tab, run ",[36,5677,520],{},", then apply the new recipe. Disconnecting is administrator-only: if that control is disabled for you, ask an administrator of the deployment's team to do it — see ",[264,5680,5682],{"href":5681},"\u002Fbyodt-cloud\u002Fcloud#who-can-change-a-connected-deployment","Who can change a connected deployment",[14,5684,5685,5686,5689,5690,5693,5694,380],{},"If all you need to change is ",[71,5687,5688],{},"who may sign in",", do not disconnect at all. That one value can be replaced on a connected deployment, from section ",[71,5691,5692],{},"3 · Who may sign in"," on the same tab, and it costs none of what a disconnect costs: ",[264,5695,5697],{"href":5696},"\u002Fbyodt-cloud\u002Fcloud#changing-who-may-sign-in","Cloud → Changing who may sign in",[117,5699,5701],{"id":5700},"the-redirect-uri-over-http-is-allowed-only-on-localhost",[36,5702,5703],{},"the redirect URI over http is allowed only on localhost",[14,5705,5706,5708,5709,5711],{},[71,5707,135],{}," You are reaching the console over plain HTTP at a non-",[36,5710,4060],{}," address, so the callback the console would write is a plaintext, off-box URL. It refuses to write one.",[14,5713,5714,5716,5717,5719],{},[71,5715,149],{}," Enable TLS at the front door, then reach the console over ",[36,5718,4025],{}," and apply the recipe again:",[29,5721,5723],{"className":31,"code":5722,"language":33,"meta":34,"style":34},".\u002Fbyodt tls generate \u003Cyour hostname>\n.\u002Fbyodt restart proxy\n",[36,5724,5725,5730],{"__ignoreMap":34},[39,5726,5727],{"class":41,"line":42},[39,5728,5729],{},".\u002Fbyodt tls generate \u003Cyour hostname>\n",[39,5731,5732],{"class":41,"line":48},[39,5733,5087],{},[14,5735,5736,5737,5740],{},"The same applies to a recipe value: ",[36,5738,5739],{},"OIDC_ISSUER must be https (or http on localhost)"," and its siblings mean a recipe carried a plaintext endpoint. Re-copy the recipe; if it genuinely contains one, do not work around it.",[117,5742,5744],{"id":5743},"cloud-sign-in-needs-a-secure-context",[36,5745,5746],{},"Cloud sign-in needs a secure context",[124,5748,5749],{},[14,5750,5751],{},[36,5752,5753],{},"Cloud sign-in needs a secure context (https, or a localhost address). Enable TLS at the front door first (byodt tls generate).",[14,5755,5756,5758,5759,5761],{},[71,5757,135],{}," The browser will not expose the cryptography the sign-in flow requires on a plain-HTTP page at a non-",[36,5760,4060],{}," address.",[14,5763,5764,5766,5767,380],{},[71,5765,149],{}," Same as above: install a certificate, recreate the proxy, and reach the console over ",[36,5768,4025],{},[117,5770,5772],{"id":5771},"this-consoles-sign-in-callback-is-not-registered",[36,5773,5774],{},"This console's sign-in callback is not registered",[14,5776,5777,5779],{},[71,5778,135],{}," The identity provider rejected the sign-in because the console's callback URL is not registered. The provider rejects this before the request reaches your deployment, so nothing in your own logs explains it.",[14,5781,5782,5784,5785,5788,5789,380],{},[71,5783,149],{}," The console shows the exact value to register. Copy it verbatim into your account's ",[71,5786,5787],{},"Callback URLs"," field, save, then sign in again. Both callbacks — the platform's and the console's — must be registered, and they must match exactly, including scheme, host, and port. See ",[264,5790,5792],{"href":5791},"\u002Fbyodt-cloud\u002Fcloud#register-the-two-callbacks","Cloud → Register the two callbacks",[117,5794,5796],{"id":5795},"could-not-verify-sign-in-the-platform-may-be-starting-or-busy-retry",[36,5797,5798],{},"could not verify sign-in — the platform may be starting or busy; retry",[14,5800,5801,5803],{},[71,5802,135],{}," The console checks your sign-in by asking the platform, and the platform did not answer cleanly. It may be starting, restarting, or busy. The console deliberately does not claim your sign-in was rejected, because it cannot tell the two apart.",[14,5805,5806,5808,5809,5811,5812,380],{},[71,5807,149],{}," Wait for the platform to be healthy (",[36,5810,88],{},"), then sign in again. If it persists, ",[36,5813,768],{},[117,5815,5817],{"id":5816},"the-sign-in-check-is-busy-retry",[36,5818,5819],{},"the sign-in check is busy — retry",[14,5821,5822,5824],{},[71,5823,135],{}," Too many sign-in checks are in flight at once. The console caps them.",[14,5826,5827,5829],{},[71,5828,149],{}," Retry in a moment.",[117,5831,5833],{"id":5832},"the-console-signed-me-out-after-i-applied-the-configuration","The console signed me out after I applied the configuration",[14,5835,5836,5838],{},[71,5837,135],{}," Expected. Connecting or disconnecting changes the deployment's posture, so every console session minted under the old posture is dropped. The tab you applied from is the exception: it keeps working for a short grace period so you can read what to do next, then it is signed out too. Any other tab is signed out immediately.",[14,5840,5841,5843,5844,5846],{},[71,5842,149],{}," Nothing. After connecting you sign in with SSO; after disconnecting the console re-establishes its own session automatically. You do not need to be signed in to run ",[36,5845,520],{}," — and running it is what completes the change.",[117,5848,5850],{"id":5849},"you-are-not-an-administrator-of-the-team-this-deployment-belongs-to",[36,5851,5852],{},"You are not an administrator of the team this deployment belongs to",[124,5854,5855],{},[14,5856,5857],{},[36,5858,5859],{},"You are not an administrator of the team this deployment belongs to. Only an administrator may change this deployment or see who may sign in to it. Nothing was changed. An owner or administrator of that team can grant you the administrator role in the portal.",[14,5861,5862,5864,5865,5868,5869,5872,5873,5876],{},[71,5863,135],{}," Every console control that ",[3892,5866,5867],{},"changes"," a connected deployment — mounting and unmounting content, installing and removing artifacts, updating the knowledge graph, changing who may sign in, and disconnecting — is available only to an administrator of the team the deployment belongs to, and so is the one thing the console ",[3892,5870,5871],{},"shows"," only to an administrator: the ",[71,5874,5875],{},"Who may sign in"," card, which lists your team's members and who among them may sign in. The console asked the cloud who you are on this attempt, and the answer was no. Every other read is unaffected: the status, the catalog and the inventory are all still yours to see. On the Cloud tab the card shows this sentence in the console's own words and nothing of the team — no list, no ticks, nothing about who has left.",[14,5878,5879,5881,5882,5885,5886,5888,5889,5892,5893,380],{},[71,5880,149],{}," Ask an owner or administrator of that team to grant you the administrator role in the portal, or to run the operation for you. Retrying changes nothing until the role does. Once it does, your next attempt picks it up — you do not have to sign in again — though the Content tab learns which controls to offer only when it reads the catalog, so click ",[71,5883,5884],{},"Refresh"," there for the buttons to become available. The ",[71,5887,5875],{}," card has no retry in this state — reload the page; the reload clears the tab's cloud sign-in, so the card offers ",[71,5890,5891],{},"Sign in to the cloud"," and fetches the team when you return. See ",[264,5894,5895],{"href":5681},"Cloud → Who can change a connected deployment",[117,5897,5899],{"id":5898},"the-console-could-not-reach-the-content-service-to-check-whether-you-administer-this-deployment",[36,5900,5901],{},"The console could not reach the content service to check whether you administer this deployment",[124,5903,5904],{},[14,5905,5906],{},[36,5907,5908],{},"The console could not reach the content service to check whether you administer this deployment, so nothing was changed. Wait a moment and try again.",[14,5910,5911,5913],{},[71,5912,135],{}," The check is made against the cloud on every attempt, and this attempt got no usable answer — unreachable, refused, or a reply the console does not recognise. It refuses rather than guessing, and it deliberately does not say you are not an administrator, because what failed was the check and not you.",[14,5915,5916,5918,5919,5921],{},[71,5917,149],{}," Check the machine's network access and try again in a moment. While it lasts this also refuses ",[71,5920,5670],{},", which is intended: proceeding when the check cannot be made would be the wrong direction to fail in on the one operation that costs you classes and links.",[117,5923,5925],{"id":5924},"this-tab-no-longer-holds-your-cloud-sign-in",[36,5926,5927],{},"This tab no longer holds your cloud sign-in",[124,5929,5930],{},[14,5931,5932],{},[36,5933,5934],{},"This tab no longer holds your cloud sign-in, so the console could not check whether you administer this deployment. Nothing was changed. Sign in to the cloud again to continue.",[14,5936,5937,5939],{},[71,5938,135],{}," The check is made with the cloud credential this browser tab holds, and that credential is kept in memory only. Reloading the page clears it while leaving your console session intact — so the tab is signed in, shows your name, and holds nothing to ask the cloud with. This is the ordinary state of a reloaded tab, not a fault.",[14,5941,5942,5944,5945,5948,5949,5951,5952,5955,5956,5958],{},[71,5943,149],{}," Usually nothing to read: the console answers this by taking you to sign in again rather than by printing the sentence. Sign in, then repeat the action. The same cause shows in the Content tab as the muted line ",[3892,5946,5947],{},"Your subscription has not been checked…",", and on the ",[71,5950,5875],{}," card as ",[3892,5953,5954],{},"Who may sign in has not been fetched…"," with a ",[71,5957,5891],{}," button — the card offers the sign-in rather than performing it, so a reloaded tab is not sent to the identity provider unasked.",[14,5960,5961,5962,5965],{},"If it happened while you were applying who may sign in, what you had chosen is put back when you return — your ticks, laid over the team fetched afresh, or on a deployment that names no team the list you had pasted — above a line saying ",[3892,5963,5964],{},"You were signed in again before this could be applied, so nothing was changed. What you had chosen is below — check it and apply again."," A tick for someone who has left the team in the meantime is dropped. The sign-in interrupted the change, it did not make it.",[117,5967,5969],{"id":5968},"this-deployments-configuration-does-not-let-the-console-check-who-administers-it",[36,5970,5971],{},"This deployment's configuration does not let the console check who administers it",[124,5973,5974],{},[14,5975,5976],{},[36,5977,5978],{},"This deployment's configuration does not let the console check who administers it, so it cannot run this operation for anyone. Fixing it means regenerating the deployment recipe in the portal and reconnecting — see what disconnecting costs before you do. Disconnecting itself does not need the check and is still available.",[14,5980,5981,5983,5984,380],{},[71,5982,135],{}," Permanent, and not an outage. This deployment's configuration either carries no permission to ask the question or names no usable address to ask it at, so the check cannot succeed here for anybody. Waiting will not help, and it is not about you. The same cause shows in the Content tab as the muted line ",[3892,5985,5986],{},"Nothing is restricted, but subscriptions cannot be checked on this deployment…",[14,5988,5989,5991,5992,5996],{},[71,5990,149],{}," Get a fresh recipe from the portal, then disconnect, apply it, and connect again — read ",[264,5993,5995],{"href":5994},"\u002Fbyodt-cloud\u002Fcloud#disconnecting","what disconnecting costs"," first. Disconnect is the one control this refusal does not block, precisely because it is the step the repair needs.",[117,5998,6000],{"id":5999},"that-list-does-not-name-the-account-you-are-signed-in-as",[36,6001,6002],{},"That list does not name the account you are signed in as",[124,6004,6005],{},[14,6006,6007],{},[36,6008,6009],{},"That list does not name the account you are signed in as (your account identifier), so applying it would lock you out of this deployment at the next platform start. Nothing was changed. Paste the DEPLOYMENT_ALLOWLIST value from a freshly generated deployment recipe again rather than adding yourself back — if your own account was missing from what you pasted, others may be too. An administrator who is on the list can also apply it for you.",[14,6011,6012,6014],{},[71,6013,135],{}," The list you pasted does not name the account this console session belongs to. Applying it would end your own access at the next platform start, and with it your ability to change the list again. The list itself is well formed — what is wrong is that it leaves you out. You only meet this from the paste box, on a deployment that names no team: on the card your own row is always ticked and cannot be unticked, so the card never submits a list without you.",[14,6016,6017,6019,6020,6023,6024,6027,6028,6031],{},[71,6018,149],{}," Clear the box and copy the whole list again — the value of the ",[36,6021,6022],{},"DEPLOYMENT_ALLOWLIST="," line in the recipe's ",[71,6025,6026],{},"Environment"," block on the portal's deployment page, from a freshly generated recipe — and apply that. Do not just add yourself back to what is in the box: the usual cause is a paste that dropped lines, and adding yourself fixes the symptom while applying a list that is still missing colleagues. If the new list genuinely should not include you, ask an administrator who ",[3892,6029,6030],{},"is"," on it to apply it for you.",[14,6033,6034,6035,380],{},"This message names your own account identifier in the brackets, and it is the only place either the console or the portal shows it to you. See ",[264,6036,5697],{"href":5696},[117,6038,6040],{"id":6039},"the-list-you-submitted-names-no-accounts",[36,6041,6042],{},"The list you submitted names no accounts",[124,6044,6045],{},[14,6046,6047],{},[36,6048,6049],{},"The list you submitted names no accounts, so nothing was changed. A box that looks filled can still name none — separators alone are not accounts. An empty list does not mean \"nobody\": the platform reads it as NO RESTRICTION, which would admit anyone your identity provider knows, and on a deployment reachable over the network it refuses to start at all. To narrow access to one person, submit a list naming that one account.",[14,6051,6052,6054,6055,6058],{},[71,6053,135],{}," An empty list is not a way to close a deployment; it is the value that opens it. On the card, you applied with nobody ticked — the card lets you, so that this sentence is what you read rather than a greyed-out button. In the paste box, a box that looks filled can still be empty this way — separators on their own, such as ",[36,6056,6057],{},",,,",", name no accounts.",[14,6060,6061,6063],{},[71,6062,149],{}," Tick, or paste, the accounts that should keep access. To narrow the deployment down to one person, apply a list naming that one account — and if that person is not you, the console will not let you remove yourself: on the card your own row stays ticked beside theirs, and in the paste box expect the refusal above. Keep your own account on the list as well, or ask an administrator who is on the new list to apply it.",[117,6065,6067],{"id":6066},"the-access-list-contains-a-character-that-cannot-appear-in-an-account-identifier",[36,6068,6069],{},"The access list contains a character that cannot appear in an account identifier",[124,6071,6072],{},[14,6073,6074],{},[36,6075,6076],{},"The access list contains a character that cannot appear in an account identifier — usually an invisible one picked up by copying. Nothing was changed. Paste the DEPLOYMENT_ALLOWLIST value from a freshly generated deployment recipe again.",[14,6078,6079,6081],{},[71,6080,135],{}," An invisible character rode in with the paste — a byte-order mark from a text editor, a zero-width space from a web page, a soft hyphen from a wrapped document. None of them shows on screen, and none of them counts as a separator, so it becomes part of an account identifier that will then never match anyone. The console refuses the whole class rather than writing a list that looks right and silently locks somebody out.",[14,6083,6084,6086,6087,6023,6089,6091],{},[71,6085,149],{}," Clear the box, then copy the list again — the value of the ",[36,6088,6022],{},[71,6090,6026],{}," block on the portal's deployment page — and paste it straight into the console. Going via an editor, a document, or a chat message is what usually picks these up.",[117,6093,6095],{"id":6094},"that-list-names-n-accounts-and-a-deployments-access-list-holds-at-most",[36,6096,6097],{},"That list names N accounts, and a deployment's access list holds at most …",[124,6099,6100],{},[14,6101,6102],{},[36,6103,6104],{},"That list names 4812 accounts, and a deployment's access list holds at most 512 — so nothing was changed. Check that what you copied is the access list rather than another part of the page.",[14,6106,6107,6109],{},[71,6108,135],{}," A deployment's access list runs to tens of accounts, so a list far past that is almost always a paste of the wrong thing — the deployment recipe, or a whole page — rather than the list. The message names both numbers: the first is what the console read out of what you pasted, and comparing it to the number of identifiers in the line you meant to copy usually identifies the mistake on its own.",[14,6111,6112,6114,6115,6023,6117,6119,6120,6123],{},[71,6113,149],{}," Clear the box and copy the list again — the value of the ",[36,6116,6022],{},[71,6118,6026],{}," block on the portal's deployment page, and only that value. The block's ",[71,6121,6122],{},"Copy"," button copies the whole recipe, not the value.",[117,6125,6127],{"id":6126},"this-deployments-configuration-is-missing",[36,6128,6129],{},"This deployment's configuration is missing …",[124,6131,6132],{},[14,6133,6134],{},[36,6135,6136],{},"This deployment's configuration is missing OIDC_AUDIENCE, so the console will not rewrite it — a partial configuration would leave the platform unable to start. Nothing was changed. Regenerate the deployment recipe in the portal.",[14,6138,6139,6141],{},[71,6140,135],{}," Not about the list you submitted — that part was fine. Before it rewrites anything, the console re-checks that every setting a connected deployment needs is present and non-empty, and the message names the ones that are not. It refuses rather than writing a configuration the platform could not start from.",[14,6143,6144,6146,6147,6149],{},[71,6145,149],{}," Get a fresh recipe from the portal and reconnect the deployment with it — that means disconnecting first, so read ",[264,6148,5995],{"href":5994}," before you do. Do not repair the configuration by hand; the console validates what it writes and a hand edit gets none of those checks.",[117,6151,6153],{"id":6152},"this-deployments-recipe-predates-team-identifiers",[36,6154,6155],{},"This deployment's recipe predates team identifiers",[124,6157,6158],{},[14,6159,6160],{},[36,6161,6162],{},"This deployment's recipe predates team identifiers, so the console cannot tell which team it belongs to — and without that it will show neither the team nor who may sign in. Nothing was changed. Regenerate the deployment recipe in the portal and reconnect — see what disconnecting costs before you do.",[14,6164,6165,6167,6168,6170],{},[71,6166,135],{}," Permanent, and not an outage. The ",[71,6169,5875],{}," card lists your team by asking the cloud for the members of the team this deployment belongs to, and a deployment connected with an older recipe does not carry its team. The console refuses to guess — a team it cannot name is not shown as an empty one — and it refuses to show the deployment's own list either, for the same reason. Waiting will not help, and it is not about you.",[14,6172,6173,5991,6175,6177,6178,6180,6181,380],{},[71,6174,149],{},[264,6176,5995],{"href":5994}," first. Until then the card offers a paste box beneath this sentence, and on this deployment you replace the list by pasting it — the value of the recipe's ",[36,6179,6022],{}," line, from the portal's deployment page: ",[264,6182,6184],{"href":6183},"\u002Fbyodt-cloud\u002Fcloud#when-the-deployment-names-no-team","Cloud → When the deployment names no team",[117,6186,6188],{"id":6187},"the-console-could-not-fetch-this-teams-roster-from-the-content-service",[36,6189,6190],{},"The console could not fetch this team's roster from the content service",[124,6192,6193],{},[14,6194,6195],{},[36,6196,6197],{},"The console could not fetch this team's roster from the content service. Nothing was changed. Wait a moment and try again.",[14,6199,6200,6202],{},[71,6201,135],{}," The card asked the cloud for your team's members and got no usable answer — the service unreachable, busy, or a reply the console does not recognise. It refuses rather than guessing, because \"could not fetch\" and \"nobody is on the team\" are one empty list apart, and the wrong one would show every colleague as having left.",[14,6204,6205,6207,6208,6211],{},[71,6206,149],{}," Check the machine's network access and click ",[71,6209,6210],{},"Try again"," on the card in a moment. Nothing was changed, and nothing about the deployment's list has moved.",[117,6213,6215],{"id":6214},"the-content-service-declined-to-serve-this-teams-roster-to-this-sign-in",[36,6216,6217],{},"The content service declined to serve this team's roster to this sign-in",[124,6219,6220],{},[14,6221,6222],{},[36,6223,6224],{},"The content service declined to serve this team's roster to this sign-in. The console has already confirmed that you administer the team, so the refusal is about the deployment's sign-in configuration rather than about you: a roster is served only to a sign-in made through the team's own deployment. Nothing was changed. If this deployment's configuration was assembled by hand, regenerate the recipe in the portal.",[14,6226,6227,6229,6230,6233],{},[71,6228,135],{}," The cloud serves a team's members only to a sign-in that came through that team's own deployment. The console had already confirmed, on this attempt, that you administer the team — so this is not the ",[3892,6231,6232],{},"not an administrator"," refusal above, and it is not about your role. It is about the sign-in this deployment performed: its configuration names a sign-in client that is not the one the cloud issued for this team, which happens when a configuration was assembled by hand rather than from the recipe the portal issued.",[14,6235,6236,6238,6239,6241,6242,6244],{},[71,6237,149],{}," Regenerate the deployment recipe in the portal and reconnect with it — read ",[264,6240,5995],{"href":5994}," first. ",[71,6243,6210],{}," on the card will not change the answer until the configuration does.",[117,6246,6248],{"id":6247},"the-content-service-no-longer-accepts-this-tabs-cloud-sign-in",[36,6249,6250],{},"The content service no longer accepts this tab's cloud sign-in",[124,6252,6253],{},[14,6254,6255],{},[36,6256,6257],{},"The content service no longer accepts this tab's cloud sign-in, so the roster could not be fetched. Nothing was changed. Sign in to the cloud again to continue.",[14,6259,6260,6262],{},[71,6261,135],{}," This tab held a cloud credential and the console asked with it, but the cloud no longer accepts it — it has expired since the tab was signed in. It is not the reloaded-tab case above, where the tab holds no credential at all; here it held one that has lapsed.",[14,6264,6265,5667,6267,6269],{},[71,6266,149],{},[71,6268,5891],{}," on the card. The card fetches the team again when you return.",[117,6271,6273],{"id":6272},"i-need-to-see-who-is-on-the-access-list","I need to see who is on the access list",[14,6275,6276,6278,6279,6281,6282],{},[71,6277,135],{}," As an administrator of the deployment's team, on a deployment whose recipe names that team, you see it on the ",[71,6280,5875],{}," card: every team member who may sign in is ticked, and every account on the list who is no longer on the team is listed in red beneath them. That is the whole list, split by whether the account is still on the team. Two cases are left where the console cannot show it: you are not an administrator, and the deployment names no team — there an apply answers with a count and never with the accounts, so after replacing the list there is no way, in the browser, to answer ",[3892,6283,6284],{},"did I drop someone?",[14,6286,6287,6289,6290,6292],{},[71,6288,149],{}," In those two cases, read it on the host. You are already there to run ",[36,6291,762],{},"; from the bundle directory:",[29,6294,6296],{"className":31,"code":6295,"language":33,"meta":34,"style":34},"grep DEPLOYMENT_ALLOWLIST mode\u002Fmode.env\n",[36,6297,6298],{"__ignoreMap":34},[39,6299,6300],{"class":41,"line":42},[39,6301,6295],{},[14,6303,6304],{},"It is one line, comma-separated:",[29,6306,6309],{"className":6307,"code":6308,"language":178},[176],"DEPLOYMENT_ALLOWLIST=\u003Caccount>,\u003Caccount>,\u003Caccount>\n",[36,6310,6308],{"__ignoreMap":34},[14,6312,6313,6314,6317],{},"That is what the platform will admit at its ",[71,6315,6316],{},"next"," start. Until you restart it, the platform is still running the list it read when it last started — so during that window this line and the deployment's live behaviour differ, which is the point of the restart.",[14,6319,6320,6323,6324,6326,6327,380],{},[71,6321,6322],{},"Read it, do not edit it."," The console is the author of that file and validates everything it writes; a hand edit gets none of those checks, and a connect or a disconnect replaces the file whole, so it would not survive one anyway. If the list is wrong, fix it from the console: ",[264,6325,5697],{"href":5696},". See also ",[264,6328,6330],{"href":6329},"\u002Fbyodt-cloud\u002Fconfiguration#the-mode-layer-modemodeenv","Configuration → The mode layer",[117,6332,6334,6335],{"id":6333},"a-colleague-signs-in-and-sees-this-deployment-does-not-admit-your-account","A colleague signs in and sees ",[36,6336,6337],{},"This deployment does not admit your account",[124,6339,6340],{},[14,6341,6342,6344,6345,6348],{},[71,6343,6337],{}," — Your sign-in worked as ",[3892,6346,6347],{},"(the account)",", but this deployment is not set up to let that account in. Who may sign in is chosen by an administrator of the team this deployment belongs to, on the deployment's console. Ask them to add you — the change takes effect when the platform is restarted — then check again.",[14,6350,6351,6353,6354,356,6357,6360,6361,6363,6364,6366,6367,6370],{},[71,6352,135],{}," Not a fault. The person's sign-in with your identity provider succeeded, and the platform then refused the account because it is not on this deployment's access list — the list the platform read when it last started. The platform shows this page, with ",[71,6355,6356],{},"Check again",[71,6358,6359],{},"Sign out"," buttons, instead of the app; it does not send them back to sign in, because signing in again would succeed again and change nothing. Either the account was never ticked on the ",[71,6362,5875],{}," card, or it was ticked and the platform has not been restarted since. An expired sign-in is not a cause: the app renews it silently, or sends the person to the ordinary sign-in if it cannot, and shows this page only when a freshly renewed sign-in is refused as well. (An earlier release could show this page to someone whose sign-in had just expired, and ",[71,6365,6356],{}," then let them in; if that is what a colleague describes, updating the platform ends it.) An older platform showed the same refusal differently: the app shell loaded and every page said ",[3892,6368,6369],{},"Failed to load models. Please try again."," — a retry that could never succeed. If a colleague reports that instead, the cause is the same one.",[14,6372,6373,6375,6376,6378,6379,6382,6383,6385,6386,6389,6390,6392,6393,380],{},[71,6374,149],{}," If they should have access, tick their row on the ",[71,6377,5875],{}," card and click ",[71,6380,6381],{},"Apply"," — or, on a deployment that names no team, paste a list that includes them — then run ",[36,6384,762],{},". Until the restart, the platform goes on refusing them; the card's ",[71,6387,6388],{},"Restart required to apply your changes"," banner is there to say so. After it, they click ",[71,6391,6356],{}," and reach the app on the same sign-in. If they are not on your team, add them in the portal first; the card lists only current members. See ",[264,6394,6396],{"href":6395},"\u002Fbyodt-cloud\u002Fcloud#someone-the-list-does-not-admit","Cloud → Someone the list does not admit",[18,6398],{},[21,6400,6402],{"id":6401},"content-mounts","Content mounts",[117,6404,6406],{"id":6405},"the-content-catalog-is-available-only-in-cloud-mode",[36,6407,6408],{},"the content catalog is available only in cloud mode",[124,6410,6411],{},[14,6412,6413],{},[36,6414,6415],{},"the content catalog is available only in cloud mode — connect this deployment to the cloud first",[14,6417,6418,6420],{},[71,6419,135],{}," Content packages require a connected deployment: the catalog address arrives with the cloud configuration, so a standalone deployment has nowhere to look.",[14,6422,6423,6425,6426,6430,6431,6434,6435,6438,6439,380],{},[71,6424,149],{}," Connect the deployment — see ",[264,6427,6429],{"href":6428},"\u002Fbyodt-cloud\u002Fcloud","Cloud",". Note the ",[71,6432,6433],{},"Content"," tab only appears once the platform is ",[3892,6436,6437],{},"actually running"," in cloud mode, which means after ",[36,6440,520],{},[117,6442,6444],{"id":6443},"the-content-catalog-is-unavailable",[36,6445,6446],{},"the content catalog is unavailable",[14,6448,6449,6451],{},[71,6450,135],{}," The catalog service could not be reached.",[14,6453,6454,6456,6457,6460,6461,380],{},[71,6455,149],{}," Check the machine's network access and retry. Mounted modules keep working: the local inventory still renders so you can manage what is already mounted, and pins are marked ",[36,6458,6459],{},"update unknown"," with the note ",[3892,6462,6463],{},"the content catalog is unavailable, so update availability could not be checked",[117,6465,6467],{"id":6466},"a-module-directory-with-this-name-already-exists-and-was-not-created-by-the-console",[36,6468,6469],{},"a module directory with this name already exists and was not created by the console",[14,6471,6472,6474],{},[71,6473,135],{}," A module directory of that name already exists and does not carry the console's own marker — a module that shipped with the release, or one you added yourself. The console refuses to overwrite it.",[14,6476,6477,6479,6480,6482,6483,380],{},[71,6478,149],{}," Nothing to do unless you genuinely intended to replace it, in which case remove that directory from ",[36,6481,4404],{}," yourself first. The same protection applies to unmounting: ",[36,6484,6485],{},"this module directory was not created by the console and will not be removed",[117,6487,6489],{"id":6488},"a-mount-or-unmount-had-no-effect","A mount or unmount had no effect",[14,6491,6492,6494],{},[71,6493,135],{}," Mounts are written into the modules directory, which the platform reads only at startup. Until the platform is recreated, nothing changes.",[14,6496,6497],{},[71,6498,149],{},[29,6500,6501],{"className":31,"code":4780,"language":33,"meta":34,"style":34},[36,6502,6503],{"__ignoreMap":34},[39,6504,6505],{"class":41,"line":42},[39,6506,4780],{},[14,6508,6509],{},"The console shows a standing reminder in the Content tab after any mount change, with this exact command.",[117,6511,6513],{"id":6512},"warning-the-stub-file-is-world-writable",[36,6514,6515],{},"Warning: the stub file is world-writable",[124,6517,6518],{},[14,6519,6520],{},[36,6521,6522],{},"…the stub file is world-writable, which the platform refuses to load in cloud mode — check how the host mount preserves file permissions",[14,6524,6525,6527],{},[71,6526,135],{}," The console wrote the mount with restrictive permissions, but the file ended up world-writable on disk. Some bind-mount backends do not preserve file modes. The platform refuses to load a world-writable module file when authentication is on, so the mount would silently not take effect.",[14,6529,6530,6532,6533,6535,6536,380],{},[71,6531,149],{}," This is a property of how your container engine shares that directory. On a VM-backed runtime, switching the deployment's storage away from host bind mounts where possible, or running on native Linux, avoids it. Confirm after a ",[36,6534,762],{}," whether the module registered — if it did not, the console reports ",[71,6537,4752],{},[117,6539,6541,6542,6544],{"id":6540},"a-cloud-module-is-still-in-modules-after-disconnecting","A cloud module is still in ",[36,6543,4404],{}," after disconnecting",[14,6546,6547,6549],{},[71,6548,135],{}," A disconnect removes every cloud-provided module itself and names what it removed. Two outcomes leave one behind, and the disconnect message says which:",[737,6551,6552,6558],{},[740,6553,6554,6557],{},[36,6555,6556],{},"The cloud modules were left in place because another modules operation was running — disconnect again to remove them",". Another module operation held the modules directory at that moment, and the sweep is skipped rather than waited on, because a revert something else can block is not a recovery path.",[740,6559,6560,6563],{},[36,6561,6562],{},"These could not be removed and are still in the modules mount: … — disconnect again, or delete them by hand",". The sweep ran, and those directories could not be deleted.",[14,6565,6566,6567,6570,6571,6574],{},"A third message is not this problem: ",[36,6568,6569],{},"Warning: a module is gone but its files could not be deleted and remain at …",". That module was moved out of the platform's way before its files were deleted, so it no longer loads. What remains is a staging copy under ",[36,6572,6573],{},"modules\u002F.byodt-console-tmp\u002F",", and deleting it recovers disk space and nothing else.",[14,6576,6577,6579,6580,6582,6583,6585,6586,6588],{},[71,6578,149],{}," Delete the named directories from ",[36,6581,4404],{}," yourself, then recreate — ",[36,6584,520],{}," if you have not yet applied the disconnect, ",[36,6587,762],{}," if you have.",[14,6590,6591,6592,6594,6595,6598],{},"The message suggests disconnecting again, and that does re-run the sweep, but there is no button for it once the disconnect is written: the ",[71,6593,6429],{}," tab offers the recipe form instead, and mount and unmount refuse with ",[36,6596,6597],{},"content mounts are available only in cloud mode",". Taking that route means pasting a recipe, recreating the stack, disconnecting again and recreating once more — which the deletion above spares you.",[14,6600,6601,6602,380],{},"What a disconnect removes, and what it costs the graph, is in ",[264,6603,6604],{"href":5994},"Cloud → Disconnecting",[117,6606,6608,6609],{"id":6607},"the-dashboard-says-the-knowledge-graphs-version-has-been-withdrawn","The dashboard says ",[71,6610,6611],{},"The knowledge graph's version has been withdrawn",[124,6613,6614],{},[14,6615,6616,6618],{},[71,6617,6611],{}," — The knowledge-graph service lists the version this deployment is pinned to as withdrawn, so analyses may get no knowledge-graph answers until it is replaced. The Content tab says what to do.",[14,6620,6621,6622,6624,6625,6628],{},"The knowledge-graph entry on the ",[71,6623,6433],{}," tab is labelled ",[36,6626,6627],{},"withdrawn"," at the same time.",[14,6630,6631,6633],{},[71,6632,135],{}," The knowledge-graph service has withdrawn the version your deployment is pinned to. Your deployment does not move off a version on its own, so it stays pinned to it until you update it. Until you do, analyses may get no knowledge-graph answers.",[14,6635,6636],{},[71,6637,149],{},[1453,6639,6640,6647,6654,6665],{},[740,6641,6642,6643,6646],{},"Click ",[71,6644,6645],{},"Open the Content tab"," on the banner.",[740,6648,6649,6650,6653],{},"On the knowledge-graph entry, click ",[71,6651,6652],{},"Update to the … version",". You need the administrator role.",[740,6655,6656,6657],{},"Restart the platform:",[29,6658,6659],{"className":31,"code":4780,"language":33,"meta":34,"style":34},[36,6660,6661],{"__ignoreMap":34},[39,6662,6663],{"class":41,"line":42},[39,6664,4780],{},[740,6666,6667],{},"Re-run the analyses that matter. Any you ran while the withdrawn version was pinned may have had no knowledge-graph answers.",[14,6669,6670,6671,6673,6674,380],{},"If the entry says the service has no other version to offer yet, there is no button and nothing to do on your deployment yet. Click ",[71,6672,5884],{}," on the Content tab later; the button appears once the service publishes a new version. See ",[264,6675,6677],{"href":6676},"\u002Fbyodt-cloud\u002Fcloud#if-the-pinned-version-is-withdrawn","Cloud → If the pinned version is withdrawn",[117,6679,6681,6682],{"id":6680},"the-knowledge-graph-entry-says-update-unknown","The knowledge-graph entry says ",[36,6683,6459],{},[14,6685,6686,6688],{},[71,6687,135],{}," The console could not compare your pinned version with what the knowledge-graph service publishes. Your deployment keeps answering from its pinned version; only the check failed. A line at the foot of the Content tab says which of three causes it is:",[3837,6690,6693],{"className":6691,"tabIndex":3841,"role":3842,"ariaLabel":6692},[3840],"Table: The knowledge-graph entry says update unknown",[3845,6694,6695,6706],{},[3848,6696,6697],{},[3851,6698,6699,6702,6704],{},[3854,6700,6701],{},"The line says",[3854,6703,5588],{},[3854,6705,3997],{},[3861,6707,6708,6723,6739],{},[3851,6709,6710,6715,6718],{},[3866,6711,6712],{},[3892,6713,6714],{},"the knowledge-graph service could not be reached, so whether an update exists could not be checked",[3866,6716,6717],{},"The service's version list could not be read just now.",[3866,6719,6720,6721,380],{},"Check the machine's network access, then click ",[71,6722,5884],{},[3851,6724,6725,6730,6733],{},[3866,6726,6727],{},[3892,6728,6729],{},"the knowledge-graph service's version listing offers no usable version, so whether an update exists could not be checked",[3866,6731,6732],{},"The service is reachable but currently publishes no version the console can offer.",[3866,6734,6735,6736,6738],{},"Nothing to do on your deployment. Click ",[71,6737,5884],{}," later.",[3851,6740,6741,6746,6749],{},[3866,6742,6743],{},[3892,6744,6745],{},"this deployment has no usable knowledge-graph service configured, so whether an update exists cannot be checked; disconnecting and reconnecting is the remedy",[3866,6747,6748],{},"The knowledge-graph address in the deployment's configuration is missing or not one the console will call — typically after the file was edited by hand.",[3866,6750,6751,6752,5059],{},"Disconnect and reconnect, which writes the configuration afresh — read ",[264,6753,5995],{"href":5994},[117,6755,6757],{"id":6756},"the-knowledge-graph-services-latest-version-changed-after-this-page-loaded",[36,6758,6759],{},"The knowledge-graph service's latest version changed after this page loaded",[124,6761,6762],{},[14,6763,6764],{},[36,6765,6766],{},"The knowledge-graph service's latest version changed after this page loaded, so nothing was changed. It is now the version released 2026-10-14 (sha256:…); update again to take it.",[14,6768,6769,6771],{},[71,6770,135],{}," The console updates only to the version the page showed you, and only while the service still publishes it as its newest. The service's latest version changed between loading the page and clicking — usually because a newer one was published.",[14,6773,6774,6776],{},[71,6775,149],{}," The console has already reloaded the knowledge-graph entry. Read it, then click the update button again if one is offered — it names the version that is latest now.",[14,6778,6779,6780,6782],{},"Two similar refusals have the same fix — click ",[71,6781,5884],{},", then try again:",[737,6784,6785,6790],{},[740,6786,6787],{},[36,6788,6789],{},"This deployment's cloud configuration changed while the update was being checked, so nothing was changed. Reload and try again.",[740,6791,6792,6795],{},[36,6793,6794],{},"This deployment was disconnected while the update was being checked, so nothing was changed."," — after a disconnect there is no knowledge-graph connection to update.",[117,6797,6799],{"id":6798},"the-knowledge-graph-service-could-not-be-reached-so-nothing-was-changed",[36,6800,6801],{},"The knowledge-graph service could not be reached, so nothing was changed",[124,6803,6804],{},[14,6805,6806],{},[36,6807,6808],{},"The knowledge-graph service could not be reached, so nothing was changed. Try again later.",[14,6810,4956],{},[124,6812,6813],{},[14,6814,6815],{},[36,6816,6817],{},"The knowledge-graph service offers no usable version right now, so nothing was changed.",[14,6819,6820,6822],{},[71,6821,135],{}," The console reads the service's version list again when you click update, and that read failed, or the list offered nothing to update to.",[14,6824,6825,6827],{},[71,6826,149],{}," Check the machine's network access and try again later. Your deployment keeps its current version in the meantime.",[117,6829,6831],{"id":6830},"this-deployment-is-configured-for-a-knowledge-graph-service-but-its-module-is-not-mounted",[36,6832,6833],{},"This deployment is configured for a knowledge-graph service but its module is not mounted",[124,6835,6836],{},[14,6837,6838],{},[36,6839,6840],{},"This deployment is configured for a knowledge-graph service but its module is not mounted, so it is not updated. Disconnect and reconnect to restore it.",[14,6842,6843,6844,6847],{},"The same cause shows at the foot of the Content tab as ",[3892,6845,6846],{},"this deployment is configured for a knowledge-graph service but its module is not mounted — disconnect and reconnect to restore it",", and the knowledge-graph entry is missing.",[14,6849,6850,6852,6853,6855],{},[71,6851,135],{}," The deployment's configuration names a knowledge-graph service, but the knowledge-graph module in ",[36,6854,4404],{}," is missing or incomplete — for example, the directory was removed by hand.",[14,6857,6858,6860,6861,5059],{},[71,6859,149],{}," Disconnect and reconnect, which writes both afresh — read ",[264,6862,5995],{"href":5994},[117,6864,6866],{"id":6865},"this-deployment-has-a-knowledge-graph-module-mounted-but-no-version-pinned",[36,6867,6868],{},"This deployment has a knowledge-graph module mounted but no version pinned",[124,6870,6871],{},[14,6872,6873],{},[36,6874,6875],{},"This deployment has a knowledge-graph module mounted but no version pinned, so it is not updated. Disconnect and reconnect to restore it.",[14,6877,6843,6878,6847],{},[3892,6879,6880],{},"this deployment has a knowledge-graph module mounted but no version pinned — disconnect and reconnect to restore it",[14,6882,6883,6885,6886,6888],{},[71,6884,135],{}," The knowledge-graph module is in ",[36,6887,4404],{},", but the deployment's configuration names no version for it — typically after the configuration file was edited by hand.",[14,6890,6891,6893,6894,5059],{},[71,6892,149],{}," Disconnect and reconnect, which writes the configuration and the module afresh — read ",[264,6895,5995],{"href":5994},[117,6897,6899],{"id":6898},"the-content-tab-shows-the-new-knowledge-graph-version-but-analyses-have-not-changed","The Content tab shows the new knowledge-graph version, but analyses have not changed",[14,6901,6902,6904],{},[71,6903,135],{}," The Content tab reads the deployment's configuration, not the running platform. After an update it shows the new version straight away, but the platform keeps answering from the version it started with until it is recreated.",[14,6906,6907],{},[71,6908,149],{},[29,6910,6911],{"className":31,"code":4780,"language":33,"meta":34,"style":34},[36,6912,6913],{"__ignoreMap":34},[39,6914,6915],{"class":41,"line":42},[39,6916,4780],{},[14,6918,6919],{},"This restart removes no module, so it does not touch your classes or the links to them.",[18,6921],{},[21,6923,6925],{"id":6924},"cloud-content-in-use","Cloud content in use",[14,6927,6928,6929,6933],{},"A mounted cloud module can be in one of four states other than working, and your deployment says which one it is in. The ",[264,6930,6932],{"href":6931},"\u002Fbyodt-cloud\u002Fcloud#check-the-connection","three checks in Cloud"," tell you which part of the connection works.",[14,6935,6936,6937,6940],{},"One rule holds in all four: ",[71,6938,6939],{},"an evaluation refuses rather than returning \"no findings\" when it could not evaluate."," An empty result is never a failure in disguise.",[117,6942,6944],{"id":6943},"a-cloud-module-registers-nothing-and-reports-itself-unavailable","A cloud module registers nothing and reports itself unavailable",[14,6946,6947,6949],{},[71,6948,135],{}," Not configured: the deployment's content base URL is unset, so the module has nowhere to fetch from. Unless an earlier connected run cached its content, it registers nothing and reports itself unavailable. Nothing else breaks.",[14,6951,6952,6954,6955,356,6960,380],{},[71,6953,149],{}," The base URL arrives with the cloud configuration, so a deployment the console connected carries it. Check that the deployment is connected and the stack was recreated after the recipe was applied — see ",[264,6956,6958],{"href":6957},"#the-content-catalog-is-available-only-in-cloud-mode",[36,6959,6408],{},[264,6961,6963],{"href":6962},"\u002Fbyodt-cloud\u002Fcloud#recreate-the-stack","Cloud → Recreate the stack",[117,6965,6967],{"id":6966},"a-class-shows-a-generic-form-instead-of-its-own","A class shows a generic form instead of its own",[14,6969,6970,6972],{},[71,6971,135],{}," Not entitled: there is no subscription to the package that provides the class, or it has ended. Forms and guides fall back to generic content with a link back to your account, and evaluation refuses outright rather than returning nothing. This is not an error.",[14,6974,6975,6977,6978,6981,6982,6984,6985,380],{},[71,6976,149],{}," Subscribe to the package in the portal — again, if the subscription has ended. Your deployment reads the subscription as it needs it, so a package subscribed since reaches it without a reconnect: the portal's ",[71,6979,6980],{},"Billing"," page says your deployment picks it up within about a minute. For what the ",[71,6983,6433],{}," tab shows meanwhile, see ",[264,6986,6988],{"href":6987},"\u002Fbyodt-cloud\u002Fcloud#package-and-module-states","Cloud → Package and module states",[14,6990,6991,6992,380],{},"If the package is subscribed, the content service may be unreachable instead — see ",[264,6993,6995],{"href":6994},"#cloud-content-is-slow-or-does-not-load","Cloud content is slow or does not load",[117,6997,6999],{"id":6998},"a-module-reports-its-version-was-recalled-or-does-not-exist","A module reports its version was recalled, or does not exist",[14,7001,7002,7004],{},[71,7003,135],{}," Recalled or mis-pinned: a version you pinned was withdrawn, or does not exist. Your deployment surfaces the reason and what supersedes it.",[14,7006,7007,7009,7010,380],{},[71,7008,149],{}," This one needs you to act. The deployment does not fall back to content cached for that version, so it stays this way until the module's pin moves. Moving a module to another published version is covered in ",[264,7011,7013],{"href":7012},"\u002Fbyodt-cloud\u002Fcloud#keep-mounts-current","Cloud → Keep mounts current",[14,7015,7016,7017,380],{},"The knowledge-graph connection has its own version and its own entry: see ",[264,7018,6608,7020],{"href":7019},"#the-dashboard-says-the-knowledge-graphs-version-has-been-withdrawn",[71,7021,6611],{},[117,7023,6995],{"id":7024},"cloud-content-is-slow-or-does-not-load",[14,7026,7027,7029],{},[71,7028,135],{}," Unreachable: a network failure, a timeout, or a rate limit between your deployment and the content service.",[14,7031,7032,7034,7035,7037,7038,7040,7041,380],{},[71,7033,149],{}," Check the machine's network access. Cached content keeps serving meanwhile, and retries are bounded. If the content service is down, your deployment still runs — only cloud content degrades. If the console's ",[71,7036,6433],{}," tab also reports ",[36,7039,6446],{},", see ",[264,7042,7044],{"href":7043},"#the-content-catalog-is-unavailable","that entry",[18,7046],{},[21,7048,7050],{"id":7049},"permissions-and-rootless-engines","Permissions and rootless engines",[117,7052,7054,7055,74,7057,78,7060],{"id":7053},"permission-denied-writing-to-modules-schema-or-data","Permission denied writing to ",[36,7056,4404],{},[36,7058,7059],{},"schema\u002F",[36,7061,531],{},[14,7063,7064,7066],{},[71,7065,135],{}," The containers write into these directories as an unprivileged user id that does not match yours — the console runs as a non-root numeric id. If those directories were created or tightened by hand, that user cannot write to them.",[14,7068,7069,7071],{},[71,7070,149],{}," Let the control script repair the layout. It creates the runtime directories with permissions the container user can use, and does so on every start:",[29,7073,7074],{"className":31,"code":217,"language":33,"meta":34,"style":34},[36,7075,7076],{"__ignoreMap":34},[39,7077,7078],{"class":41,"line":42},[39,7079,217],{},[14,7081,7082,7083,7085,7086,7088,7089,7091,7092,1761],{},"Do not tighten these directories by hand — the next start widens them again, and the deployment needs them writable. The certificate directory ",[36,7084,5149],{}," is the deliberate exception: it stays restrictive, is mounted read-only, and only you write to it. So is ",[36,7087,3980],{},", which holds an outbound proxy's CA: it is mounted read-only, and ",[36,7090,480],{}," refuses it when anyone but you can write to it (see ",[264,7093,4560],{"href":4559},[117,7095,7097],{"id":7096},"the-database-becomes-corrupt-on-macos-or-windows","The database becomes corrupt on macOS or Windows",[14,7099,7100,7102],{},[71,7101,135],{}," The default storage setting is a host bind mount inside the bundle. On a VM-backed runtime, one that runs containers in a virtual machine (such as Docker Desktop, or a Podman machine on macOS or Windows), the file-sharing layer between host and VM can corrupt a database that is actively writing. Docker Engine or Podman running directly on Linux is not VM-backed and is not affected.",[14,7104,7105,7107,7108,7111],{},[71,7106,149],{}," Move the database to the named volume, which lives in the engine's own storage. Back up first: this is a switch to a ",[71,7109,7110],{},"fresh"," database, not a migration.",[29,7113,7115],{"className":31,"code":7114,"language":33,"meta":34,"style":34},".\u002Fbyodt backup\n",[36,7116,7117],{"__ignoreMap":34},[39,7118,7119],{"class":41,"line":42},[39,7120,7114],{},[14,7122,7123,7124,172],{},"Then in ",[36,7125,171],{},[29,7127,7130],{"className":7128,"code":7129,"language":178},[176],"DB_DATA=memgraph-data\n",[36,7131,7129],{"__ignoreMap":34},[14,7133,7134,7135,4168],{},"On Neo4j, set ",[36,7136,7137],{},"NEO4J_DATA=neo4j-data",[29,7139,7141],{"className":31,"code":7140,"language":33,"meta":34,"style":34},".\u002Fbyodt restart db\n.\u002Fbyodt restore backups\u002F\u003Cthe file you just made>\n",[36,7142,7143,7148],{"__ignoreMap":34},[39,7144,7145],{"class":41,"line":42},[39,7146,7147],{},".\u002Fbyodt restart db\n",[39,7149,7150],{"class":41,"line":48},[39,7151,7152],{},".\u002Fbyodt restore backups\u002F\u003Cthe file you just made>\n",[14,7154,976,7155,380],{},[264,7156,7158],{"href":7157},"\u002Fbyodt-cloud\u002Fconfiguration#where-the-database-keeps-its-data","Configuration → Where the database keeps its data",[18,7160],{},[21,7162,7164],{"id":7163},"still-stuck","Still stuck",[14,7166,7167],{},"Collect this before asking for help — it is what any diagnosis starts from:",[29,7169,7171],{"className":31,"code":7170,"language":33,"meta":34,"style":34},".\u002Fbyodt version\n.\u002Fbyodt status\n.\u002Fbyodt logs console-init > console-init.log\n.\u002Fbyodt logs platform > platform.log\n",[36,7172,7173,7178,7182,7187],{"__ignoreMap":34},[39,7174,7175],{"class":41,"line":42},[39,7176,7177],{},".\u002Fbyodt version\n",[39,7179,7180],{"class":41,"line":48},[39,7181,4828],{},[39,7183,7184],{"class":41,"line":54},[39,7185,7186],{},".\u002Fbyodt logs console-init > console-init.log\n",[39,7188,7189],{"class":41,"line":1493},[39,7190,7191],{},".\u002Fbyodt logs platform > platform.log\n",[14,7193,7194],{},"Plus a screenshot of the console's dashboard, including any banners.",[124,7196,7197],{},[14,7198,7199,7202,7203,7205,7206,356,7209,7212,7213,7216],{},[71,7200,7201],{},"Check what you share."," Logs and screenshots can carry the names of your models and components. Review them before sending. They do not contain your database password, which lives only in ",[36,7204,240],{}," — and that file should never be shared. The services mask your outbound proxy's login where they report a failed fetch, and in tests no log carried it; still, search the logs for its user name before sending. The output of ",[36,7207,7208],{},".\u002Fbyodt compose config",[36,7210,7211],{},"docker inspect"," (or ",[36,7214,7215],{},"podman inspect",") does contain the password and the login: do not send it.",[21,7218,7220],{"id":7219},"related","Related",[737,7222,7223,7229,7234,7241],{},[740,7224,7225,7228],{},[264,7226,3742],{"href":7227},"\u002Fbyodt-cloud\u002Finstallation"," — prerequisites and the first start.",[740,7230,7231,7233],{},[264,7232,2423],{"href":2422}," — settings, and which command applies a change.",[740,7235,7236,7240],{},[264,7237,7239],{"href":7238},"\u002Fbyodt-cloud\u002Foperations","Operations"," — the command reference, backups, TLS, and upgrades.",[740,7242,7243,7245],{},[264,7244,6429],{"href":6428}," — connecting and disconnecting.",[7247,7248,7249],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .sIAta, html code.shiki .sIAta{--shiki-default:#22863A;--shiki-dark:#8DDB8C}html pre.shiki code .sYgZi, html code.shiki .sYgZi{--shiki-default:#24292E;--shiki-dark:#ADBAC7}html pre.shiki code .s-HuK, html code.shiki .s-HuK{--shiki-default:#032F62;--shiki-dark:#96D0FF}",{"title":34,"searchDepth":54,"depth":54,"links":7251},[7252,7253,7280,7321,7335,7351,7361,7369,7386,7412,7430,7436,7441,7442],{"id":23,"depth":48,"text":24},{"id":114,"depth":48,"text":115,"children":7254},[7255,7256,7257,7258,7259,7260,7262,7263,7264,7265,7266,7268,7269,7270,7271,7272,7273,7274,7276,7277,7278,7279],{"id":119,"depth":54,"text":122},{"id":183,"depth":54,"text":186},{"id":220,"depth":54,"text":223},{"id":271,"depth":54,"text":274},{"id":324,"depth":54,"text":327},{"id":383,"depth":54,"text":7261},"… is no longer used notices, and data\u002Follama",{"id":491,"depth":54,"text":494},{"id":563,"depth":54,"text":566},{"id":631,"depth":54,"text":634},{"id":677,"depth":54,"text":680},{"id":726,"depth":54,"text":7267},"The platform does not start, or keeps restarting, after .\u002Fbyodt restart",{"id":833,"depth":54,"text":834},{"id":876,"depth":54,"text":879},{"id":983,"depth":54,"text":986},{"id":1056,"depth":54,"text":1059},{"id":1116,"depth":54,"text":1119},{"id":1172,"depth":54,"text":1175},{"id":1233,"depth":54,"text":7275},"The platform never starts, and console-init exited non-zero",{"id":1274,"depth":54,"text":1277},{"id":1346,"depth":54,"text":1349},{"id":1391,"depth":54,"text":1394},{"id":1416,"depth":54,"text":267},{"id":1519,"depth":48,"text":1520,"children":7281},[7282,7283,7284,7286,7287,7288,7289,7290,7291,7292,7293,7294,7295,7296,7297,7298,7299,7300,7301,7302,7303,7304,7305,7306,7307,7308,7309,7310,7312,7313,7314,7315,7316,7317,7318,7319],{"id":1537,"depth":54,"text":1540},{"id":1584,"depth":54,"text":1587},{"id":1616,"depth":54,"text":7285},"The deployment in … already runs release … \u002F … already holds release …, and has not been started yet",{"id":1664,"depth":54,"text":1667},{"id":1694,"depth":54,"text":1697},{"id":1715,"depth":54,"text":1718},{"id":1764,"depth":54,"text":1767},{"id":1790,"depth":54,"text":1793},{"id":1849,"depth":54,"text":1852},{"id":1890,"depth":54,"text":1893},{"id":1927,"depth":54,"text":1930},{"id":2033,"depth":54,"text":2036},{"id":2060,"depth":54,"text":2063},{"id":2151,"depth":54,"text":2154},{"id":2208,"depth":54,"text":2211},{"id":2253,"depth":54,"text":2256},{"id":2325,"depth":54,"text":2328},{"id":2361,"depth":54,"text":2364},{"id":2388,"depth":54,"text":2391},{"id":2430,"depth":54,"text":2433},{"id":2471,"depth":54,"text":2474},{"id":2511,"depth":54,"text":2514},{"id":2552,"depth":54,"text":2555},{"id":2603,"depth":54,"text":2606},{"id":2621,"depth":54,"text":2624},{"id":2648,"depth":54,"text":2651},{"id":2685,"depth":54,"text":2688},{"id":2714,"depth":54,"text":7311},"Already on … \u002F … is older than …: a downgrade is a rollback, not an upgrade",{"id":2744,"depth":54,"text":2747},{"id":2782,"depth":54,"text":2785},{"id":2828,"depth":54,"text":2831},{"id":2856,"depth":54,"text":2859},{"id":2902,"depth":54,"text":2905},{"id":2930,"depth":54,"text":2933},{"id":2962,"depth":54,"text":2965},{"id":2997,"depth":54,"text":7320},".\u002Fbyodt upgrade X.Y.Z on 0.12.x or 0.13.0 prints Updated. and stays on the old release",{"id":3047,"depth":48,"text":3048,"children":7322},[7323,7324,7325,7327,7329,7330,7331,7332,7334],{"id":3051,"depth":54,"text":3052},{"id":3096,"depth":54,"text":3097},{"id":3270,"depth":54,"text":7326},"in the models directory is owned by uid or is writable by accounts other than its owner",{"id":3373,"depth":54,"text":7328},"the data ingest failed with a memory limit",{"id":3608,"depth":54,"text":3611},{"id":3660,"depth":54,"text":3663},{"id":3699,"depth":54,"text":3702},{"id":3745,"depth":54,"text":7333},"some modules installed and some failed \u002F every module failed to install",{"id":3773,"depth":54,"text":3776},{"id":3818,"depth":48,"text":3237,"children":7336},[7337,7339,7340,7341,7342,7343,7344,7345,7347,7349,7350],{"id":3958,"depth":54,"text":7338},"byodt refuses the proxy setting",{"id":4199,"depth":54,"text":4202},{"id":4245,"depth":54,"text":4248},{"id":4284,"depth":54,"text":4287},{"id":4365,"depth":54,"text":4368},{"id":4412,"depth":54,"text":4415},{"id":4455,"depth":54,"text":4458},{"id":4486,"depth":54,"text":7346},"self-signed certificate in certificate chain or x509: certificate signed by unknown authority",{"id":4569,"depth":54,"text":7348},"A TLS handshake error with an https:\u002F\u002F proxy URL",{"id":4620,"depth":54,"text":4346},{"id":4681,"depth":54,"text":4409},{"id":4715,"depth":48,"text":4716,"children":7352},[7353,7355,7356,7357,7358,7359,7360],{"id":4719,"depth":54,"text":7354},"Verdict shows Degraded or Fault",{"id":4742,"depth":54,"text":4745},{"id":4792,"depth":54,"text":4795},{"id":4841,"depth":54,"text":4844},{"id":4872,"depth":54,"text":4875},{"id":4912,"depth":54,"text":4915},{"id":4941,"depth":54,"text":4942},{"id":4991,"depth":48,"text":4992,"children":7362},[7363,7364,7365,7366,7367,7368],{"id":4995,"depth":54,"text":4998},{"id":5025,"depth":54,"text":5026},{"id":5062,"depth":54,"text":5063},{"id":5095,"depth":54,"text":5098},{"id":5126,"depth":54,"text":5127},{"id":5156,"depth":54,"text":5159},{"id":5191,"depth":48,"text":5192,"children":7370},[7371,7372,7373,7375,7376,7377,7379,7380,7381,7382,7383,7384,7385],{"id":5195,"depth":54,"text":5198},{"id":5228,"depth":54,"text":5231},{"id":5247,"depth":54,"text":7374},"The database container is not running \u002F More than one database container of this project is running",{"id":5303,"depth":54,"text":5306},{"id":5329,"depth":54,"text":5332},{"id":5345,"depth":54,"text":7378},"… is a Neo4j dump; this deployment runs Memgraph \u002F … is a Memgraph snapshot; this deployment runs Neo4j",{"id":5371,"depth":54,"text":5374},{"id":5387,"depth":54,"text":5390},{"id":5427,"depth":54,"text":5430},{"id":5454,"depth":54,"text":5457},{"id":5483,"depth":54,"text":5486},{"id":5519,"depth":54,"text":5520},{"id":5541,"depth":54,"text":5544},{"id":5564,"depth":48,"text":5565,"children":7387},[7388,7389,7390,7391,7392,7393,7394,7395,7396,7397,7398,7399,7400,7401,7402,7403,7404,7405,7406,7407,7408,7409,7410],{"id":5568,"depth":54,"text":5569},{"id":5647,"depth":54,"text":5650},{"id":5700,"depth":54,"text":5703},{"id":5743,"depth":54,"text":5746},{"id":5771,"depth":54,"text":5774},{"id":5795,"depth":54,"text":5798},{"id":5816,"depth":54,"text":5819},{"id":5832,"depth":54,"text":5833},{"id":5849,"depth":54,"text":5852},{"id":5898,"depth":54,"text":5901},{"id":5924,"depth":54,"text":5927},{"id":5968,"depth":54,"text":5971},{"id":5999,"depth":54,"text":6002},{"id":6039,"depth":54,"text":6042},{"id":6066,"depth":54,"text":6069},{"id":6094,"depth":54,"text":6097},{"id":6126,"depth":54,"text":6129},{"id":6152,"depth":54,"text":6155},{"id":6187,"depth":54,"text":6190},{"id":6214,"depth":54,"text":6217},{"id":6247,"depth":54,"text":6250},{"id":6272,"depth":54,"text":6273},{"id":6333,"depth":54,"text":7411},"A colleague signs in and sees This deployment does not admit your account",{"id":6401,"depth":48,"text":6402,"children":7413},[7414,7415,7416,7417,7418,7419,7421,7423,7425,7426,7427,7428,7429],{"id":6405,"depth":54,"text":6408},{"id":6443,"depth":54,"text":6446},{"id":6466,"depth":54,"text":6469},{"id":6488,"depth":54,"text":6489},{"id":6512,"depth":54,"text":6515},{"id":6540,"depth":54,"text":7420},"A cloud module is still in modules\u002F after disconnecting",{"id":6607,"depth":54,"text":7422},"The dashboard says The knowledge graph's version has been withdrawn",{"id":6680,"depth":54,"text":7424},"The knowledge-graph entry says update unknown",{"id":6756,"depth":54,"text":6759},{"id":6798,"depth":54,"text":6801},{"id":6830,"depth":54,"text":6833},{"id":6865,"depth":54,"text":6868},{"id":6898,"depth":54,"text":6899},{"id":6924,"depth":48,"text":6925,"children":7431},[7432,7433,7434,7435],{"id":6943,"depth":54,"text":6944},{"id":6966,"depth":54,"text":6967},{"id":6998,"depth":54,"text":6999},{"id":7024,"depth":54,"text":6995},{"id":7049,"depth":48,"text":7050,"children":7437},[7438,7440],{"id":7053,"depth":54,"text":7439},"Permission denied writing to modules\u002F, schema\u002F, or data\u002F",{"id":7096,"depth":54,"text":7097},{"id":7163,"depth":48,"text":7164},{"id":7219,"depth":48,"text":7220},"Symptom, cause, and fix for the failures this deployment reports","md",{"category":7446,"position":3522,"tags":7447},"documentation",[480,7448,7449,7450,7451],"deployment","troubleshooting","errors","recovery",true,"\u002Fbyodt-cloud\u002Ftroubleshooting",{"title":5,"description":7443},"02.byodt-cloud\u002F05.troubleshooting","ECqonBbJu2ZXjak6jwLMO4ykspEnWMYqZQDkgAflYyo",[7458,7513,7540,7595,7629,7673,7688,7758],{"title":7459,"description":7460,"path":7461,"stem":7462,"children":7463,"page":-1},"Platform","Modelling, analysis, findings and controls in the Dethernety platform.","\u002Fplatform","01.platform",[7464,7468,7473,7478,7483,7488,7493,7498,7503,7508],{"title":7465,"path":7461,"stem":7466,"description":7467},"Dethernety User Documentation","01.platform\u002Findex","User guide for the Dethernety threat modeling platform",{"title":7469,"path":7470,"stem":7471,"description":7472},"Quick Start","\u002Fplatform\u002Fquick-start","01.platform\u002F01.quick-start","Install Dethernety on your own machine, draw a four-element model and read its first threat finding.",{"title":7474,"path":7475,"stem":7476,"description":7477},"Building Your First Model","\u002Fplatform\u002Fbuilding-your-first-model","01.platform\u002F02.building-your-first-model","Build a threat model of an online store in about 30 minutes, run a Threat Report on it, and raise an issue from a finding.",{"title":7479,"path":7480,"stem":7481,"description":7482},"Security Analysis Workflow","\u002Fplatform\u002Fsecurity-analysis-workflow","01.platform\u002F03.security-analysis-workflow","How to run security analysis and interpret results to improve your threat models.",{"title":7484,"path":7485,"stem":7486,"description":7487},"Managing Findings","\u002Fplatform\u002Fmanaging-findings","01.platform\u002F04.managing-findings","Record decisions on system-generated exposures and countermeasures — affirm them as confirmed live risk, or mute them as not applicable, false positive, waived, or superseded — instead of deleting them.",{"title":7489,"path":7490,"stem":7491,"description":7492},"Working with Security Controls","\u002Fplatform\u002Fworking-with-security-controls","01.platform\u002F05.working-with-security-controls","Learn how to create, manage, and assign reusable security controls in Dethernety to protect your threat models.",{"title":7494,"path":7495,"stem":7496,"description":7497},"Issue Management Guide","\u002Fplatform\u002Fissue-management-guide","01.platform\u002F06.issue-management-guide","Issue tracking, filtering, and management in Dethernety.",{"title":7499,"path":7500,"stem":7501,"description":7502},"Boundary Trust Zones","\u002Fplatform\u002Fboundary-trust-zones","01.platform\u002F07.boundary-trust-zones","Record each security boundary's trust zone, business domains, operational role, and approved channels to document how your system is meant to be segmented.",{"title":7504,"path":7505,"stem":7506,"description":7507},"Understanding Modules","\u002Fplatform\u002Funderstanding-modules","01.platform\u002F08.understanding-modules","How Dethernety's module system extends your threat modeling capabilities.",{"title":7509,"path":7510,"stem":7511,"description":7512},"Component Configuration Guide","\u002Fplatform\u002Fcomponent-configuration-guide","01.platform\u002F09.component-configuration-guide","Detailed guide on configuring different types of components and their security implications.",{"title":7514,"description":7515,"path":7516,"stem":7517,"children":7518,"page":-1},"BYODt cloud","Deploying the platform yourself and connecting it to the BYODt cloud.","\u002Fbyodt-cloud","02.byodt-cloud",[7519,7523,7527,7531,7535,7539],{"title":7520,"path":7516,"stem":7521,"description":7522},"BYODt Deployment","02.byodt-cloud\u002Findex","Run Dethernety on your own machine: install, configure, operate, and recover",{"title":7524,"path":7227,"stem":7525,"description":7526},"Installing the BYODt Deployment","02.byodt-cloud\u002F01.installation","Install Dethernety on your own machine: check the requirements, download and verify the signed bundle, start it, and confirm the deployment is healthy",{"title":7528,"path":2422,"stem":7529,"description":7530},"Configuring the BYODt Deployment","02.byodt-cloud\u002F02.configuration","The .env settings reference, the generated secret file, database storage, and how to apply a change",{"title":7532,"path":7238,"stem":7533,"description":7534},"Operating the BYODt Deployment","02.byodt-cloud\u002F03.operations","The byodt command reference and the day-to-day tasks: start, stop, inspect, back up, restore, TLS, upgrade, remove",{"title":7536,"path":6428,"stem":7537,"description":7538},"Connecting the BYODt Deployment to the Cloud","02.byodt-cloud\u002F04.cloud","Add cloud sign-in and content packages from the operator console, and disconnect again",{"title":5,"path":7453,"stem":7455,"description":7443},{"title":7541,"description":7542,"path":7543,"stem":7544,"children":7545,"page":-1},"Dethereal","The Claude Code plugin: build a threat model in conversation and publish it to the platform.","\u002Fdethereal","03.dethereal",[7546,7550,7555,7560,7565,7570,7575,7580,7585,7590],{"title":7547,"path":7543,"stem":7548,"description":7549},"Dethereal — Claude Code Plugin for Threat Modeling","03.dethereal\u002Findex","Comprehensive documentation for the Dethereal threat modeling plugin",{"title":7551,"path":7552,"stem":7553,"description":7554},"Getting Started with Dethereal","\u002Fdethereal\u002Fgetting-started","03.dethereal\u002F01.getting-started","Install the plugin, authenticate, and create your first threat model",{"title":7556,"path":7557,"stem":7558,"description":7559},"The 11-Step Guided Workflow","\u002Fdethereal\u002Fguided-workflow","03.dethereal\u002F02.guided-workflow","Complete walkthrough of the \u002Fdethereal:threat-model guided process",{"title":7561,"path":7562,"stem":7563,"description":7564},"Command Reference","\u002Fdethereal\u002Fcommand-reference","03.dethereal\u002F03.command-reference","Complete reference for all 14 Dethereal slash commands",{"title":7566,"path":7567,"stem":7568,"description":7569},"Threat Model Concepts","\u002Fdethereal\u002Fmodel-concepts","03.dethereal\u002F04.model-concepts","Components, boundaries, data flows, classes, attributes, and quality scoring",{"title":7571,"path":7572,"stem":7573,"description":7574},"Discovery and Enrichment","\u002Fdethereal\u002Fdiscovery-and-enrichment","03.dethereal\u002F05.discovery-and-enrichment","Infrastructure scanning, security attributes, MITRE ATT&CK, credentials, and compliance",{"title":7576,"path":7577,"stem":7578,"description":7579},"Sync and Version Control","\u002Fdethereal\u002Fsync-and-version-control","03.dethereal\u002F06.sync-and-version-control","Push\u002Fpull workflow, conflict handling, git integration, and multi-model projects",{"title":7581,"path":7582,"stem":7583,"description":7584},"Review and Attack Surface Analysis","\u002Fdethereal\u002Freview-and-analysis","03.dethereal\u002F07.review-and-analysis","Quality review, attack surface summary, and platform analysis integration",{"title":7586,"path":7587,"stem":7588,"description":7589},"Agents, Tools, and Hooks","\u002Fdethereal\u002Fagents-and-architecture","03.dethereal\u002F08.agents-and-architecture","How the 5 AI agents, 22 MCP tools, and 3 lifecycle hooks work together",{"title":7591,"path":7592,"stem":7593,"description":7594},"Dethereal Glossary","\u002Fdethereal\u002Fglossary","03.dethereal\u002F09.glossary","Definitions for Dethereal-specific terminology",{"title":7596,"description":7597,"path":7598,"stem":7599,"children":7600,"page":-1},"Threat Report","The residual-risk report over a threat model: reading it, filtering it and exporting it.","\u002Fthreat-report","04.threat-report",[7601,7604,7609,7614,7619,7624],{"title":7596,"path":7598,"stem":7602,"description":7603},"04.threat-report\u002Findex","Read, filter, drill into, and export a residual-risk report over a threat model",{"title":7605,"path":7606,"stem":7607,"description":7608},"Getting Started with the Threat Report","\u002Fthreat-report\u002Fgetting-started","04.threat-report\u002F01.getting-started","Generate, open, refresh, and export a threat report over a model",{"title":7610,"path":7611,"stem":7612,"description":7613},"Reading the Report","\u002Fthreat-report\u002Freading-the-report","04.threat-report\u002F02.reading-the-report","Navigating the report, the shared visual language, and the Posture and Boundary Crossings views",{"title":7615,"path":7616,"stem":7617,"description":7618},"Understanding Coverage and Gaps","\u002Fthreat-report\u002Funderstanding-coverage","04.threat-report\u002F03.understanding-coverage","Reading the MITRE ATT&CK coverage matrix: tiers, prevent vs detect, off-grid notes, and what coverage does and does not mean",{"title":7620,"path":7621,"stem":7622,"description":7623},"Reachability and Flow Routes","\u002Fthreat-report\u002Freachability","04.threat-report\u002F04.reachability","Exploring flow routes to crown-jewel assets and between any two elements — and what the analysis does and does not model",{"title":7625,"path":7626,"stem":7627,"description":7628},"Working with Findings","\u002Fthreat-report\u002Fworking-with-findings","04.threat-report\u002F05.working-with-findings","The Residual Risk ledger, triaging findings, filtering, and the per-element Component Profile",{"title":7630,"description":7631,"path":7632,"stem":7633,"children":7634,"page":-1},"Risk assessment","The risk assessment module: the register, the reports and the method behind them.","\u002Frisk-assessment","05.risk-assessment",[7635,7639,7644,7649,7654,7659,7663,7668],{"title":7636,"path":7632,"stem":7637,"description":7638},"Dethernety Risk Assessment User Guide","05.risk-assessment\u002Findex","Dethernety Risk Assessment turns a threat model you have built on the Dethernety platform into a grounded, board-ready draft risk report. From one point-in-time assessment of your model you get a prioritized worklist, a likelihood × impact risk matrix, a security-coverage posture, ten kinds of finding, a management risk register your team authors and maintains, and audience-tiered stakeholder reports — Board, Risk Committee, and Technical — plus machine-readable data exports.",{"title":7640,"path":7641,"stem":7642,"description":7643},"FAQ and Troubleshooting","\u002Frisk-assessment\u002Ffaq","05.risk-assessment\u002F01.faq","Short answers to the questions analysts, risk managers, and compliance officers ask most often about the Risk Assessment. Each answer links to the guide that covers it in full.",{"title":7645,"path":7646,"stem":7647,"description":7648},"Findings","\u002Frisk-assessment\u002Ffindings","05.risk-assessment\u002F02.findings","A finding is a specific observation the Risk Assessment makes about your threat model. Every finding is grounded in something concrete you have declared — an element, a data flow, a trust zone, a crown jewel — and it points you at a place worth a closer look. This guide is the reference to open when you see a finding and want to know what it means and what to do about it.",{"title":7650,"path":7651,"stem":7652,"description":7653},"Getting Started","\u002Frisk-assessment\u002Fgetting-started","05.risk-assessment\u002F03.getting-started","Risk Assessment turns a threat model you have built on the Dethernety platform into a grounded, board-ready draft risk report — a prioritized worklist, a likelihood × impact matrix, a security-coverage posture, ten kinds of finding, a risk register your team authors, and audience-tiered stakeholder reports and exports.",{"title":7655,"path":7656,"stem":7657,"description":7658},"Methodology and Trust","\u002Frisk-assessment\u002Fmethodology-and-trust","05.risk-assessment\u002F04.methodology-and-trust","Every number in a Risk Assessment is meant to survive scrutiny. This chapter explains why you can trust the report and — just as importantly — what it deliberately declines to claim, so you can put it in front of your board, a regulator, or an external auditor and defend every line.",{"title":7610,"path":7660,"stem":7661,"description":7662},"\u002Frisk-assessment\u002Freading-the-report","05.risk-assessment\u002F05.reading-the-report","The Risk Assessment turns your threat model into a single, scannable draft risk report: an executive summary at the top and a set of analytical tabs below it. This guide explains how to read what you see — what a matrix cell means, how coverage is stated, what a severity band is (and is not), and how to interpret each tab.",{"title":7664,"path":7665,"stem":7666,"description":7667},"Stakeholder Reports and Exports","\u002Frisk-assessment\u002Fstakeholder-reports","05.risk-assessment\u002F06.stakeholder-reports","One assessment produces reporting for every audience you answer to. From a single generated Risk Assessment you can hand your board a one-page brief, give your risk committee the full reconciliation, keep the complete technical detail for your own team, and export the underlying data into your GRC tool — without ever re-running anything or reconciling one document against another.",{"title":7669,"path":7670,"stem":7671,"description":7672},"The Risk Register","\u002Frisk-assessment\u002Fthe-risk-register","05.risk-assessment\u002F07.the-risk-register","The Risk Register is where your team records and manages the real risks your organisation is carrying — on top of, but separate from, what the analysis computed for you. Each entry is written by a person: a plain-language risk statement, your own assessment of how likely it is and how much it would hurt, the findings and elements from the analysis that back it up, a treatment decision, an owner, a review date, and a reference handle you can quote in a ticket or a board pack.",{"title":7674,"description":7675,"path":7676,"stem":7677,"children":7678,"page":-1},"Threat Patterns","The Threat Patterns module and its modelling checklist.","\u002Fthreat-patterns","06.threat-patterns",[7679,7683],{"title":7680,"path":7676,"stem":7681,"description":7682},"Threat Patterns User Guide","06.threat-patterns\u002Findex","Threat Patterns finds threats in your model that no single element shows on its own. Each one appears only when several elements line up. For example, an agent may read content anyone can write, hold private data, and be able to send data where an outsider reads it. Each element can look acceptable alone, but together they form a path an attacker can use.",{"title":7684,"path":7685,"stem":7686,"description":7687},"Modelling Checklist","\u002Fthreat-patterns\u002Fmodelling-checklist","06.threat-patterns\u002F01.modelling-checklist","Threat Patterns decides a leg only from what your model states. An unanswered attribute or field is undetermined, never read as \"no\". This checklist lists the facts and drawings the analysis asks for most often. For each one it says where to set it and which leg it settles. Attribute names are shown as they appear on the class, in code.",{"title":7689,"description":7690,"path":7691,"stem":7692,"children":7693,"page":-1},"Agentic modelling","A hands-on training: model one agentic system step by step, with Threat Patterns after each step.","\u002Fagentic-modelling","07.agentic-modelling",[7694,7698,7703,7708,7713,7718,7723,7728,7733,7738,7743,7748,7753],{"title":7695,"path":7691,"stem":7696,"description":7697},"Model an Agentic Architecture","07.agentic-modelling\u002Findex","A hands-on training in modelling systems that run AI agents, so that Threat Patterns can analyse them. You build one system, a fictional customer-support copilot, in eleven short lessons. Each lesson adds one thing to the model, and you run Threat Patterns after each one to see what the change did.",{"title":7699,"path":7700,"stem":7701,"description":7702},"Lesson 1: Draw the Agent and What It Talks To","\u002Fagentic-modelling\u002F01-draw-the-agent","07.agentic-modelling\u002F01.01-draw-the-agent","Training overview · Lesson 1 of 11 · Next: Say what data moves",{"title":7704,"path":7705,"stem":7706,"description":7707},"Lesson 2: Say What Data Moves","\u002Fagentic-modelling\u002F02-say-what-data-moves","07.agentic-modelling\u002F02.02-say-what-data-moves","Training overview · Lesson 2 of 11 · Previous: Draw the agent · Next: Mark who is outside",{"title":7709,"path":7710,"stem":7711,"description":7712},"Lesson 3: Mark Who Is Outside","\u002Fagentic-modelling\u002F03-mark-who-is-outside","07.agentic-modelling\u002F03.03-mark-who-is-outside","Training overview · Lesson 3 of 11 · Previous: Say what data moves · Next: Draw a tool that reaches any host",{"title":7714,"path":7715,"stem":7716,"description":7717},"Lesson 4: Draw a Tool That Reaches Any Host","\u002Fagentic-modelling\u002F04-draw-a-tool-that-reaches-any-host","07.agentic-modelling\u002F04.04-draw-a-tool-that-reaches-any-host","Training overview · Lesson 4 of 11 · Previous: Mark who is outside · Next: State what the agent can do",{"title":7719,"path":7720,"stem":7721,"description":7722},"Lesson 5: State What the Agent Can Do","\u002Fagentic-modelling\u002F05-state-what-the-agent-can-do","07.agentic-modelling\u002F05.05-state-what-the-agent-can-do","Training overview · Lesson 5 of 11 · Previous: Draw a tool that reaches any host · Next: Fix a finding with a fact",{"title":7724,"path":7725,"stem":7726,"description":7727},"Lesson 6: Fix a Finding With a Fact","\u002Fagentic-modelling\u002F06-fix-a-finding-with-a-fact","07.agentic-modelling\u002F06.06-fix-a-finding-with-a-fact","Training overview · Lesson 6 of 11 · Previous: State what the agent can do · Next: Record a compensating control",{"title":7729,"path":7730,"stem":7731,"description":7732},"Lesson 7: Record a Compensating Control","\u002Fagentic-modelling\u002F07-record-a-compensating-control","07.agentic-modelling\u002F07.07-record-a-compensating-control","Training overview · Lesson 7 of 11 · Previous: Fix a finding with a fact · Next: Leave what you don't know open",{"title":7734,"path":7735,"stem":7736,"description":7737},"Lesson 8: Leave What You Don't Know Open","\u002Fagentic-modelling\u002F08-leave-unknowns-open","07.agentic-modelling\u002F08.08-leave-unknowns-open","Training overview · Lesson 8 of 11 · Previous: Record a compensating control · Next: Follow a credential",{"title":7739,"path":7740,"stem":7741,"description":7742},"Lesson 9: Follow a Credential","\u002Fagentic-modelling\u002F09-follow-a-credential","07.agentic-modelling\u002F09.09-follow-a-credential","Training overview · Lesson 9 of 11 · Previous: Leave what you don't know open · Next: Watch what gets into knowledge and memory",{"title":7744,"path":7745,"stem":7746,"description":7747},"Lesson 10: Watch What Gets Into Knowledge and Memory","\u002Fagentic-modelling\u002F10-what-gets-in","07.agentic-modelling\u002F10.10-what-gets-in","Training overview · Lesson 10 of 11 · Previous: Follow a credential · Next: Draw tools from others and hand-offs",{"title":7749,"path":7750,"stem":7751,"description":7752},"Lesson 11: Draw Tools From Others and Hand-offs","\u002Fagentic-modelling\u002F11-tools-and-handoffs","07.agentic-modelling\u002F11.11-tools-and-handoffs","Training overview · Lesson 11 of 11 · Previous: Watch what gets into knowledge and memory",{"title":7754,"path":7755,"stem":7756,"description":7757},"The recipe at a glance","\u002Fagentic-modelling\u002Frecipe-at-a-glance","07.agentic-modelling\u002F12.recipe-at-a-glance","The ten steps of the training on one page. Each lesson teaches one or two of them.",{"title":7759,"description":7760,"path":7761,"stem":7762,"children":7763,"page":-1},"BYODt subscription","Subscribing on the BYODt Portal, and moving a deployment you already run to a new team.","\u002Fbyodt-subscription","08.byodt-subscription",[7764,7768,7773],{"title":7765,"path":7761,"stem":7766,"description":7767},"BYODt Subscription","08.byodt-subscription\u002Findex","Buy content for the deployment you run yourself, and decide where that deployment goes when you buy a team edition",{"title":7769,"path":7770,"stem":7771,"description":7772},"Your Subscription","\u002Fbyodt-subscription\u002Fyour-subscription","08.byodt-subscription\u002F01.your-subscription","Create an account, subscribe by card, and find the values your deployment needs on the portal",{"title":7774,"path":7775,"stem":7776,"description":7777},"Moving a Deployment to a New Team","\u002Fbyodt-subscription\u002Fmoving-a-deployment-to-a-new-team","08.byodt-subscription\u002F02.moving-a-deployment-to-a-new-team","What to do with the deployment you already run once you buy a team edition: three ways forward, best first",1793748185672]