Binnen een Virtualbox omgeving (v7.0.6 r155176) draai ik Linux Mint.
In die omgeving draait Veracrypt waarin ik volumes kan mounten.
Na het mounten kan ik de inhoud zien, openen, bewerken, allemaal geen probleem.
Echter ergens tussen de één en twee minuten wordt dat volume automatisch dismounted.
Er zijn opties in Veracrypt die dat voor je doen, die staan allemaal uit.
Als ik mount en wacht, duurt het vrij consequent iets meer dan een minuut.
Als ik actief met het volume blijf werken, duur het iets langer, maar nog steeds binnen twee minuten.
Een aantal herhalingen gedaan, waarbij het syslog steeds dezelfde opbouw heeft:
...dan werkt het een minuut...
Om vervolgens de boel stuk te maken:
Als ik de mount actief gebruik komt die eerste systemd-hostnamed.service al voorbij, zonder gevolgen. Pas bij de media-veracrypt1.mount wordt dat volume echt dismounted.
Maar dan de grote vraag... waarom? Hoe kan ik achterhalen waar die trigger vandaan komt?
In die omgeving draait Veracrypt waarin ik volumes kan mounten.
Na het mounten kan ik de inhoud zien, openen, bewerken, allemaal geen probleem.
Echter ergens tussen de één en twee minuten wordt dat volume automatisch dismounted.
Er zijn opties in Veracrypt die dat voor je doen, die staan allemaal uit.
Als ik mount en wacht, duurt het vrij consequent iets meer dan een minuut.
Als ik actief met het volume blijf werken, duur het iets langer, maar nog steeds binnen twee minuten.
Een aantal herhalingen gedaan, waarbij het syslog steeds dezelfde opbouw heeft:
code:
1
2
3
4
5
6
7
8
9
10
11
| Apr 17 17:44:13 virtualbox dbus-daemon[595]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.216' (uid=1000 pid=5046 comm="/usr/bin/veracrypt " label="unconfined") Apr 17 17:44:13 virtualbox systemd[1]: Starting Hostname Service... Apr 17 17:44:13 virtualbox dbus-daemon[595]: [system] Successfully activated service 'org.freedesktop.hostname1' Apr 17 17:44:13 virtualbox systemd[1]: Started Hostname Service. Apr 17 17:44:17 virtualbox kernel: [18289.921734] loop0: detected capacity change from 0 to 201326080 Apr 17 17:44:18 virtualbox ntfs-3g[10889]: Version 2021.8.22 integrated FUSE 28 Apr 17 17:44:18 virtualbox ntfs-3g[10889]: Mounted /dev/loop0 (Read-Write, label "", NTFS 3.1) Apr 17 17:44:18 virtualbox ntfs-3g[10889]: Cmdline options: rw,uid=1000,gid=1000,umask=077 Apr 17 17:44:18 virtualbox ntfs-3g[10889]: Mount options: allow_other,nonempty,relatime,rw,default_permissions,fsname=/dev/loop0,blkdev,blksize=4096 Apr 17 17:44:18 virtualbox ntfs-3g[10889]: Global ownership and permissions enforced, configuration type 7 Apr 17 17:44:19 virtualbox systemd-resolved[573]: Clock change detected. Flushing caches. |
...dan werkt het een minuut...
Om vervolgens de boel stuk te maken:
code:
1
2
3
4
5
6
| Apr 17 17:44:41 virtualbox systemd[1]: systemd-hostnamed.service: Deactivated successfully. Apr 17 17:44:50 virtualbox systemd-resolved[573]: Clock change detected. Flushing caches. Apr 17 17:45:21 virtualbox systemd[1]: media-veracrypt1.mount: Deactivated successfully. Apr 17 17:45:21 virtualbox ntfs-3g[10889]: Unmounting /dev/loop0 () Apr 17 17:45:21 virtualbox systemd[1]: voldata-.veracrypt_aux_mnt1.mount: Deactivated successfully. Apr 17 17:45:21 virtualbox systemd-resolved[573]: Clock change detected. Flushing caches. |
Als ik de mount actief gebruik komt die eerste systemd-hostnamed.service al voorbij, zonder gevolgen. Pas bij de media-veracrypt1.mount wordt dat volume echt dismounted.
Maar dan de grote vraag... waarom? Hoe kan ik achterhalen waar die trigger vandaan komt?
Een vergissing is menselijk, maar om er echt een puinhoop van te maken heb je een computer nodig.