> [!NOTE]- PROMPT > What command can I run over this entire directory to remove the "lock" emblems you see? It's a permissions thing. This is an imported .config directory for Darktable from an older system. My username is `wm` I'm on Linux Mint The lock (padlock) emblems you're seeing on those files in **Nemo** (Linux Mint's default file manager) indicate that your current user (`wm`) does **not** own the files or lacks write permissions on them. This is very common when importing a `.config` directory (or any folder) from another system or an older install—the files are typically still owned by the old user or root. Since this is your imported **Darktable** config (with SQLite databases like `library.db`, `data.db`, and their `-pre`/`-snp` backups), the safe and recommended command to run **inside that directory** is: ```bash sudo chown -R wm:wm . ``` ### How to run it 1. Open a terminal. 2. `cd` into the exact directory shown in your screenshot (the one containing `styles`, `darktablerc`, all the `data.db*` and `library.db*` files, `user.css`, etc.). Example (adjust the path if it's not directly under `~/.config/darktable`): ```bash cd ~/.config/darktable ``` or wherever you placed the imported folder. 3. Run the command: ```bash sudo chown -R wm:wm . ``` - `chown -R` = recursive (affects the directory and everything inside it) - `wm:wm` = sets both owner and group to your username `wm` - `.` = current directory After running this, refresh the view in Nemo (F5 or close/reopen the window). The padlock emblems should disappear, and the files will be fully owned and writable by you. ### Alternative (if you prefer broader permissions) If you also want to ensure the files are readable/writable by you (in case the old permissions were very restrictive), you can follow it with: ```bash chmod -R u+rwX . ``` (`X` is smart—it only adds execute on directories, not plain files.) ### Why this happens with Darktable configs When you copy/import a `.config/darktable` folder from another machine, the files retain their original ownership/permissions. Darktable's SQLite databases (`library.db`, `data.db`, etc.) are especially sensitive to this, but the lock emblem is purely a visual cue from Nemo showing "you can't modify this." **Note**: Do **not** delete any `*.lock` files unless Darktable itself complains about a locked database (those are runtime lock files created by Darktable when it's running). The padlocks in your screenshot are permission emblems, not the actual `.lock` runtime files. After fixing ownership, Darktable should behave normally with the imported config. If you run into any database corruption issues later, you can always let Darktable recreate fresh ones or use its built-in recovery options. Let me know if the emblems persist after this!