-
-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--extra-files copied to target machine with original user's ownership #326
Comments
I've run the command using the last revision before today's merge, and the issue goes away confirming that the recent merge is the source of the issue: nix run github:nix-community/nixos-anywhere/242444d228636b1f0e89d3681f04a75254c29f66 -- --extra-files "$temp" --flake .#"$config" root@"$ip" -i "$HOME/.ssh/id_ed25519" |
This makes sense. Sorry for that. The original idea is to let the user setup permissions etc. But well, this situation should be better taken care of. |
This issue ruined my entire weekend, which is ironic for a tool supposed to set up an instance in less than 5 minutes! Indeed, it crashes the entire installation, especially the SSHD server! For security reasons, SSH is strict about the owner of the You can see on the new installation, the boot problem Several options are possible:
|
Also, recommending the use of the command I think it would be better to advise using |
@badele Please try |
Hi @Prince213 thanks for your quick contribution, it seems to be working now. |
@badele Glad it helped! |
I'm having an issue with this command:
nixos-anywhere seems to be copying the extra files as the original user, thus breaking my installation. /etc and /etc/ssh are owned by 1000:users, when they should be root:root
![etc](https://private-user-images.githubusercontent.com/49611363/333906328-1469e3bc-935f-437c-bef1-7a743428e669.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk0NjkyMTAsIm5iZiI6MTczOTQ2ODkxMCwicGF0aCI6Ii80OTYxMTM2My8zMzM5MDYzMjgtMTQ2OWUzYmMtOTM1Zi00MzdjLWJlZjEtN2E3NDM0MjhlNjY5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjEzVDE3NDgzMFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTcxYTY2MTg1YThkYmI4NDJjZDc5OTQ3MjQ0NjJlYmE4Y2JjMWRkNGJiODUzNTljYWZhYjcyMWZkOWM2MmYzZjMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.Q_lkdsGaXaM7PwneGSFb0XoDlEc9E1tB6ytumXVVaUs)
I noticed this after the recent rsync related merge today: #325, so not sure if it's related to that, or if I'm doing something dumb.
The text was updated successfully, but these errors were encountered: