[Bug]: Unable to take snapshots on Linux host - Could not copy NVRAM file

[resherwni]

Version

7.1.10

Host OS Type

Linux

Host Architecture

x86

Guest OS Type

Windows

Guest Architecture

x86

Component

Snapshots

What happened?

Linux Mint Host running a Windows 11 VM with a hard disk on an NFS share. VM runs fine but when the VM is powered off or on, if I attempt to take a snashop using the VirtualBox Manager GUI I receive the following error:

VM Name: Shiny-Traveller-VM
Snapshot Name: Snapshot 1

Could not copy NVRAM file '/home/rod/VirtualBox VMs/Shiny-Traveller-VM/Shiny-Traveller-VM.nvram' to '/home/rod/VirtualBox VMs/Shiny-Traveller-VM/Snapshots/2025-06-27T00-42-08-777875000Z.nvram' (VERR_INVALID_PARAMETER).
Result Code: VBOX_E_IPRT_ERROR (0x80bb0005)
Result Detail: -2 (0xfffffffe)
Component: SessionMachine
Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}

VirtualBox Version 7.1.10 r169112 (Qt6.4.2), Linux Mint 221. Cinnamon (Cinnamon Version 6.4.8, Linux Kernel 747595)

Shiny-Traveller-VM-2025-06-25-18-43-20.log

How can we reproduce this?

1. Open VirtualBox Manager
2. Select VM and ensure it's Powered Off
3. Select menu item Snapshot / Take.
4. Enter snapshot name and click Ok
5. Error appears in notifications panel.
   

You can also get exactly the same error when you attempt to clone a VM.

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.

[alflr]

Does taking snapshots work if the VM is not on an NFS share? What about CIFS (SMB)?

[resherwni]

Only the VM disk is on an NFS share as it's the only storage I have available large enought to store the drive. The Vm config etc is stored in my home folder. The NVRAM file that gives the error is also on my folder on the linux host as shown in the rror message /home/rod/VirtualBox VMs/Shiny-Traveller-VM/Snapshots/2025-06-27T00-42-08-777875000Z.nvram.

[resherwni]

I also get exactly the same error when attempting to clone a VM

[alflr]

Can you check the access rights of the .nvram file and maybe attaching it to this defect?

[paulsonx]

The VBox.log file shows that VirtualBox can't determine the type of
filesystem in use for /home/rod:

00:00:01.130750 File system of '/home/rod/Downloads/VBoxGuestAdditions_7.1.10.iso' (DVD) is unknown
00:00:01.134293 File system of '/home/rod/VirtualBox VMs/Shiny-Traveller-VM/Snapshots' (snapshots) is unknown
00:00:01.134320 File system of '/media/rod/backups/Shiny-Traveller-VM.vdi' is nfs

So what type of filesystem do you have for your home directory?

[resherwni]

Can you check the access rights of the .nvram file and maybe attaching it to this defect?

Here they are. I've changed nothing by hand. These are all whatever is set by default.

rod@LM-Shiny-Traveller:~/VirtualBox VMs$ ls -lR
.:
total 4
drwxrwxr-x 4 rod rod 4096 Jun 30 18:25 Shiny-Traveller-VM

./Shiny-Traveller-VM:
total 584
drwx------ 2 rod rod 4096 Jun 30 18:17 Logs
-rw------- 1 rod rod 547328 Jun 30 18:25 Shiny-Traveller-VM.nvram
-rw------- 1 rod rod 7139 Jun 30 18:25 Shiny-Traveller-VM.vbox
-rw------- 1 rod rod 7139 Jun 30 12:41 Shiny-Traveller-VM.vbox-prev
drwx------ 2 rod rod 4096 Jun 27 10:47 Snapshots

./Shiny-Traveller-VM/Logs:
total 948
-rw------- 1 rod rod 252613 Jun 30 18:25 VBox.log
-rw------- 1 rod rod 221536 Jun 30 12:39 VBox.log.1
-rw------- 1 rod rod 236523 Jun 30 12:34 VBox.log.2
-rw------- 1 rod rod 221095 Jun 30 12:24 VBox.log.3

./Shiny-Traveller-VM/Snapshots:
total 3752
-rw------- 1 rod rod 540672 Jun 25 18:40 2025-06-25T08-40-36-316559000Z.nvram
-rw------- 1 rod rod 540672 Jun 27 09:59 2025-06-26T23-59-50-969348000Z.nvram
-rw------- 1 rod rod 540672 Jun 27 10:27 2025-06-27T00-27-50-724759000Z.nvram
-rw------- 1 rod rod 540672 Jun 27 10:28 2025-06-27T00-28-05-274475000Z.nvram
-rw------- 1 rod rod 540672 Jun 27 10:29 2025-06-27T00-29-06-207871000Z.nvram
-rw------- 1 rod rod 540672 Jun 27 10:42 2025-06-27T00-42-08-777875000Z.nvram
-rw------- 1 rod rod 540672 Jun 27 10:47 2025-06-27T00-47-57-643383000Z.nvram

[resherwni]

The VBox.log file shows that VirtualBox can't determine the type of filesystem in use for /home/rod:

00:00:01.130750 File system of '/home/rod/Downloads/VBoxGuestAdditions_7.1.10.iso' (DVD) is unknown
00:00:01.134293 File system of '/home/rod/VirtualBox VMs/Shiny-Traveller-VM/Snapshots' (snapshots) is unknown
00:00:01.134320 File system of '/media/rod/backups/Shiny-Traveller-VM.vdi' is nfs

So what type of filesystem do you have for your home directory?

It's a default Linux Mint installation.

rod@LM-Shiny-Traveller:~$ df -T /
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p6 ext4 191394684 63241232 118358280 35% /

[resherwni]

Curiously, I did find today that I'm able to suspend the VM which write's a file to the same directory as the snapshot nvram files without any problems.

[paulsonx]

@resherwni Can you provide the output of:

$ grep home /proc/mounts

from your system?

[resherwni]

@resherwni Can you provide the output of:

$ grep home /proc/mounts

from your system?

/home/rod/.Private /home/rod ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=6674aa546f89d59d,ecryptfs_sig=ce5fe92de8559cf2,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

[paulsonx]

Thanks for providing the /proc/mounts output as it confirms you are
using eCrpytfs. The NFS layout was a red herring in this case. The
root cause of the problem is that your home directory is encrypted using
eCryptfs and during snapshot creation on Linux hosts the copy_file_range(2)
system call is utilized to copy the NVRAM file. The eCryptfs filesystem
does not support the copy_file_range(2) syscall so we needed to extend
the fallback handling to cover the eCryptfs failure of EINVAL. Other
open source projects have had to deal with this eCryptfs copy_file_range(2)
issue as well. This issue has now been addressed in trunk (i.e. the
'main' branch here on GitHub) and the fix will also be part of the next
maintenance release of VirtualBox 7.1.