---
# System prepended metadata

title: '"The file is not writable" in n8n (since v2.0+)'
tags: [software, Lv.5, n8n]

---



tl;dr: check [N8N_RESTRICT_FILE_ACCESS_TO](https://docs.n8n.io/2-0-breaking-changes/#set-default-value-for-n8n_restrict_file_access_to) if you run into such error accidentally and check if your instance just updated.


因緣際會下發現原本跑得好端端每半個小時跑一次的 workflow 在 12/17 早上 10 點多以後開始出錯，確認原因後發現突發了意料之外的檔案寫入問題。由於 workflow 的核心功能是收集整理資料，寫檔只是留記錄存查的次要需求，所以無暇除錯下先把 `Read/Write Files from Disk` node 的 Settings 的 On Error 錯誤處理改成 Continue，讓 workflow 不會因出錯而中斷(預設值 Stop Workflow)，待有閒暇才繼續除錯。


## Problem in node 'Read/Write Files from Disk'
起先因為資料變換的時間通常也是在 1000(UTC+8) 前後，一開始還以為是資料源出錯。所幸 n8n 的 Executions (執行記錄)讓回顧輕而易舉，進而快速排除了第一個猜測。
Executions 一開就看到錯誤提示，再看到有問題打紅叉的 node 是檔案寫入。從各方維運經驗上判斷，檔案無法寫入這種問題 99% 來自權限設置有問題，然而這個 workflow 就好好地活著幾個月了，實在沒理由突然出問題。進一步看一下詳細的錯誤 log：
`NodeApiError: The file is not writable`
除了 trace 的逐層 callstack 檔名以外，能讀得懂的資料大概也就這幾個字，要再多資訊也沒了。


## Docker
由於這組 n8n 是透過 Docker 架設，中間 mount 行為是不是發生了哪些非預期的狀況也不清楚，決定先進容器實際去對系統實際寫入看看，有沒有更多資訊
```
docker exec -it n8n sh
```
p.s. n8n 官方 image 沒有 bash  
結果進去各處(/home/node/, /data/, /tmp/) touch 檔案都是正常的，完蛋。

那早上十點到底發生了什麼？直覺想到的是某種升級，翻查 watchtower log 後發現欸果然是升了個版。那是升版導致的嗎？確認了下 [Docker hub](https://hub.docker.com/r/n8nio/n8n/tags) 的 latest，是 `2.0.2`。(其實主 UI 上就有了)

那原本正常的版本是？透過 `docker images` 找到最近但不是 latest 的 image id 是 `dd1328871d00`，也透過 watchtower log 佐證沒錯。開起來看看：
```
docker run -it --rm --entrypoint sh dd1328871d00 
```
p.s. n8n 官方 image 有設定 entrypoint，要改用 shell 需要 override 掉。  
```
n8n --version
=> 1.123.5
```
BOOM 不知不覺進了個大版。但怎麼會 latest 沒進 `2.0.1` 直接進 `2.0.2`...


## N8N_RESTRICT_FILE_ACCESS_TO
根據[2.0 升級警告文件](https://docs.n8n.io/2-0-breaking-changes/#set-default-value-for-n8n_restrict_file_access_to)，確實有提到這是會壞掉的這麼回事。所以這次事件的根本原因是我用了 latest tag，而我家 watchtower 盡忠職守讓我不知不覺就登陸 2.x 導致。  
而根據[討論](https://community.n8n.io/t/problem-in-node-read-write-files-from-disk-the-file-data-file-log-is-not-writable/230917/2)顯示這個設定還有點 buggy，不能設多個也不能包含子目錄。[設定成空](https://community.n8n.io/t/n8n-restrict-file-access-to-in-2-0/227750/6)是一個萬用解(但也破壞了這個安全設計)  
不過，官方[對這個參數的文件](https://docs.n8n.io/hosting/configuration/environment-variables/security/)是顯示沒有預設值，應該用`;`區隔多個項目。前面提到的警告文件中提到的預設是 `~/.n8n-files` 何者為真暫時沒去研究 ~~，總之我是開了要開的了~~。


## 
題外話是，測試過程中，主動觸發的 workflow 在出錯 node 和 Executions 都會打綠勾，但實際上寫檔仍然未成功，整個 workflow 還是屬於出錯的。會出錯的 workflow 放到正式觸發就會在結果 Executions 被標示為 Error 和紅色，這造成了一點誤會和除錯上的耽擱，實在很令人困惑。


其他其實還有不少變動，像是某幾個本地操作 node 預設關閉相關的 `NODES_EXCLUDE`、停止支援 mysql/mariadb 支援了、啟用流程從之前單純的儲存和開關啟用改為版本控制和選擇性發佈/撤回等等。
其實先前以經有看到 2.0 升級的 hint 了，但也沒想到就這樣來了，值得警惕深思。如果還沒升級的，建議去前面提到的警告文件看看，官方也提供了 [migration tool](https://docs.n8n.io/migration-tool-v2/) (但做什麼我就暫時沒細究，用不上了啊哈哈哈)。