February 18Feb 18 Hi,wondering if this has been done before. I searched the forums, but it was a bit generic. (some threads had different solutions.. some just more questions)The IssueThe config (smbpass, docker templates/scripts) are stored unencrypted on the usb flash drive and can be read/edited.I understand that the drive needs to unencrypted to boot up and cannot be encrypted.What I want to doAfter the array is up (I login to the interface and enter the password), and before it starts smb, docker, vm, apps..A script read a keyfile of the array (which is now unecrypted) and mounts a luks/crypt overlay folder at /boot/config. this encrypted container can stay on the flash or array. It shouldn't matter as it's encrypted.and then continue with smb, docker, etc...Does this hook exists, where I can execute such a script?I understand that some /boot/config files are needed for boot (eg shadow, network, etc); but there's a lot there that aren't needed for booting up.What i'm trying to avoid;someone with physical access is able to remove the drive, copy the content and plug it back.system may reboot, or continue. either way, I will notice and bring it up.but now the attacker has access to smb hashes and other config data which may contain keys, etc..system is vulnerable over the network (samba, tailscale or some other service; because the keys got exposed).user might change the SMB config files and allow guest access to shares. Now the shares are accessible over the network.user can edit shadow file.I understand that some app can be configured to not store keys in config, but there's a lot of apps/docker where sensitive data is stored in the config and cannot be changed.Environment: My use case is a small NAS with unraid that I'm using as backup (tailscale/kopia) and it is being stored offsite (work). so other people will have physical access to it; but it could just as well be a roommate. Edited February 18Feb 18 by UnraiderOfUnlostData
February 20Feb 20 On 2/18/2026 at 2:11 PM, UnraiderOfUnlostData said:someone with physical access is able to remove the drive, copy the content and plug it back.This is probably your biggest problem. You can put the drive inside the case to make it less accessible. Plus, a decent case will have provisions for putting locks on it to make entry more difficult. Security camera would be another option. You should make sure that the flash/boot drive is not being exported. That way it can not be accessed via file sharing. Here are the permissions on the flash/boot from Linux:Have secure password (15 semi-random characters minimum) for root/GUI/console access. As you can see, only root has access to it from Linux. You should disable Telnet and enable SSH only if you need remote access via that route. (As I recall, you can use Tailscale to access the GUI which would probably be preferable to SSH.) All security is relative. Any scheme can be compromised. You just have to make it a difficult as possible.
February 22Feb 22 Frank1940 is correct. If the server is in an unsecured location, there is not much you can do to eliminate risk. Locks only work to deter honest people.Be it on a flash drive or a SSD/HD, there will still be a need to have a bootable partition free of encryption, at least until the system is able to handle encrypted data. If devices are in an area which isn't secure, it allows someone time to do as they wish, copy what they want, and develop a way to circumvent any security measures you may have implemented.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.