schnapps issueshttps://gitlab.nic.cz/turris/schnapps/-/issues2023-10-16T09:58:41+02:00https://gitlab.nic.cz/turris/schnapps/-/issues/55Schnapps doesn't display snapshot sizes2023-10-16T09:58:41+02:00Lukas JelinekSchnapps doesn't display snapshot sizesSchnapps doesn't display anything in the **Size** column. Originally from [our forum](https://forum.turris.cz/t/turris-os-6-4-3-is-released/19376/29).Schnapps doesn't display anything in the **Size** column. Originally from [our forum](https://forum.turris.cz/t/turris-os-6-4-3-is-released/19376/29).Lukas JelinekLukas Jelinekhttps://gitlab.nic.cz/turris/schnapps/-/issues/14Make `schnapps diff` default to diffing the latest two snapshots when argumen...2023-08-16T13:59:58+02:00Vojtech MyslivecMake `schnapps diff` default to diffing the latest two snapshots when arguments are missingMoved from [github #2](https://github.com/CZ-NIC/turris-schnapps/issues/2) by [TomasHubelbauer](https://github.com/TomasHubelbauer)Moved from [github #2](https://github.com/CZ-NIC/turris-schnapps/issues/2) by [TomasHubelbauer](https://github.com/TomasHubelbauer)https://gitlab.nic.cz/turris/schnapps/-/issues/11Consistency checking and fixing2023-08-16T13:59:56+02:00Lukas JelinekConsistency checking and fixingMetadata about snapshots is currently saved in `*.info` files. In some circumstances, these files need not to be consistent with the snapshot `btrfs` subvolumes. For example, there are `*.info` files without the pertaining subvolumes. Th...Metadata about snapshots is currently saved in `*.info` files. In some circumstances, these files need not to be consistent with the snapshot `btrfs` subvolumes. For example, there are `*.info` files without the pertaining subvolumes. These files are listed as "snapshots" but `schnapps` can't do anything with them (each attempt fails with a non-explaining error message). And there is no way (other than low-level manual cleanup) how to fix it.
I think that schnapps should provide solution for this. There are two possible ways:
1. Before each operation, a consistency check/repair is executed.
2. `schnapps cleanup` enhancement (consistency checking and fixing before removing old snapshots)
The first way is more comfortable but may lead to delaying of operations.https://gitlab.nic.cz/turris/schnapps/-/issues/10[feature suggestion] provide PARTUUID as designation for ROOT_DEV2023-08-16T13:59:54+02:00Ghost User[feature suggestion] provide PARTUUID as designation for ROOT_DEVIf the system is booted from another drive other than the eMMC the `ROOT_DEV` has to be changed but is currently limited only to the `/dev/sdX` designation set by the kernel, which in case of multiple hard drives being connected could va...If the system is booted from another drive other than the eMMC the `ROOT_DEV` has to be changed but is currently limited only to the `/dev/sdX` designation set by the kernel, which in case of multiple hard drives being connected could vary.
`u-boot` provides `root=PARTUUID=` which makes it independent of the kernel's `/dev/sdX` designation and thus I trust it would be handy for `schnapps` being able to set the `ROOT_DEV` with `PARTUUID=` as well.https://gitlab.nic.cz/turris/schnapps/-/issues/23Incorrect processing of SSH upload URL2023-08-16T13:59:51+02:00Lukas JelinekIncorrect processing of SSH upload URLIf a path is a part of an SSH upload URL it is incorrectly processed.
### Steps to reproduce
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use for up...If a path is a part of an SSH upload URL it is incorrectly processed.
### Steps to reproduce
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use for upload. Don't jail the user inside his home directory (the problem isn't dependent on this situation but it's necessary to define the test conditions well).
2. Login to your Turris and try to upload some snapshot, e.g. `schnapps 311 ssh://192.168.1.200/srv/turris`
### Expected results
The snapshot is uploaded into `/srv/turris` on the given machine.
### Actual results
The snapshot is not uploaded at all. `schnapps` fails to mount (*read: Connection reset by peer*) and then creates the snapshot tarball in the local directory (`/mnt/.remote-snapshots`) despite of no remote filesystem is mounted on it.Lukas JelinekLukas Jelinekhttps://gitlab.nic.cz/turris/schnapps/-/issues/22Absolute SSH upload path treated as relative2023-08-16T13:59:48+02:00Lukas JelinekAbsolute SSH upload path treated as relativeIf an absolute upload path for SSH is specified it is treated as relative.
### Steps to reproduce:
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use ...If an absolute upload path for SSH is specified it is treated as relative.
### Steps to reproduce:
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use for upload. Don't jail the user inside his home directory.
2. Login to your Turris and try to upload some snapshot, e.g. `schnapps 311 ssh://192.168.1.200 /srv/turris`
### Expected results:
The given snapshot is uploaded to `/srv/turris` on the given machine.
### Actual results:
If `/srv/turris` doesn't exist under the default working directory after logging in (usually the home directory) it fails with *"Export takes target directory as argument!"*. If the directory exists under the default working directory the snapshot is uploaded into it which is unexpected/unwanted behavior.Lukas JelinekLukas Jelinekhttps://gitlab.nic.cz/turris/schnapps/-/issues/20Handle sub-subvolumes correctly2023-08-16T13:59:45+02:00Karel KociHandle sub-subvolumes correctlyTop level subvolume can contain additional subvolumes (such as created by LXC). Schnapps does not handle them correctly. The main problems are as follows:
* [ ] When snapshot is created those subvolumes are left out. That causes rollback...Top level subvolume can contain additional subvolumes (such as created by LXC). Schnapps does not handle them correctly. The main problems are as follows:
* [ ] When snapshot is created those subvolumes are left out. That causes rollback to remove LXC containers or in other words to remove that snapshot all together.
* [ ] When snapshot with subvolumes in it is being removed it can't be because it is not empty (it contains other subvolumes) (issue https://gitlab.labs.nic.cz/turris/schnapps/issues/17)Turris OS 5.2.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/17It is not possible to remove rollback snapshot if it contains other subvolumes2023-08-16T13:59:40+02:00Karel KociIt is not possible to remove rollback snapshot if it contains other subvolumesCurrently we create rollback snapshots by moving existing `@` to rollback one. The problem is that if there are some subvolumes created inside we move those as well. These subvolumes are kept in that snapshot which can be even considered...Currently we create rollback snapshots by moving existing `@` to rollback one. The problem is that if there are some subvolumes created inside we move those as well. These subvolumes are kept in that snapshot which can be even considered correct but such snapshot can't be removed simply by `btrfs subvol delete` because it reports that snapshot is not empty.
We should instead of rollback possibly do just plain snapshot and drop subvolumes or possibly remove snaphosts recursively.
Just to point out how those snapshots were created. LXC creates snapshots so it is enough to run LXC on schnapps managed drive to reproduce this.Turris OS 5.2.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/15[-d root] should override configuration (ROOT_DEV)2023-08-16T13:59:36+02:00Ghost User[-d root] should override configuration (ROOT_DEV)`schnapps -d /dev/<root partition>` works as expected when the node is booted to the default */dev/mmcblk0p1* but it does not when booted to an USB partition (maybe also SSD but could not test since *u-boot* GPT support is not implemente...`schnapps -d /dev/<root partition>` works as expected when the node is booted to the default */dev/mmcblk0p1* but it does not when booted to an USB partition (maybe also SSD but could not test since *u-boot* GPT support is not implemented).
When booted to an USB partition (interior USB 2.0 with MBR) the root path specified with `-d` is entirely neglected and *schnapps* only deals with the current root partition.
Curiously however, manipulating */etc/schnapps/config* with `ROOT_DEV="/dev/<root partition>"` works as expected when booted to an USB partition.
Tested with HBS | HBD | Master and reproduces reliably on each installation.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/27LOCK-folder handling not correct2023-08-16T13:59:33+02:00MarkusLOCK-folder handling not correct**Describe the bug**
Any local user can prevent schnapps from starting.
If schnapps is started without proper authorization a LOCK folder is created anyway.
However, this will not be deleted again.
This causes all following starts ...**Describe the bug**
Any local user can prevent schnapps from starting.
If schnapps is started without proper authorization a LOCK folder is created anyway.
However, this will not be deleted again.
This causes all following starts of schnapps to fail.
A reboot or manual deletion of the folder is necessary
**To Reproduce**
$ sudo -u nobody schnapps
'''
ERROR: not a valid btrfs filesystem: /
ERROR: unable to access : No such file or directory
mount: only root can use "--options" option
Can't mount root partition
'''
'# schnapps list
'''
mkdir: can't create directory '/tmp/schnapps.lock': File exists
Another instance seems to be running!
'''
**Expected behavior**
schnapps cron-job starts despite the single start of another user
**Environment**
OS: Turris-OS 5
Snapshot version: 2.3-1 (also checked actually git version )Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/34Turris 1.x routers - can not rename @factory and there is no statsfs2023-08-16T13:59:28+02:00Josef SchlehoferTurris 1.x routers - can not rename @factory and there is no statsfsWhile trying to use `schnapps import` on Turris 1.x routers, it says:
```
mv: can't rename '/mnt/.snapshots/@factory': No such file or directory
ERROR: Could not statfs: No such file or directory
Your factory image was updated!
```
Howe...While trying to use `schnapps import` on Turris 1.x routers, it says:
```
mv: can't rename '/mnt/.snapshots/@factory': No such file or directory
ERROR: Could not statfs: No such file or directory
Your factory image was updated!
```
However, it works, but the output is confusing. Can you please take a look at it?
This happens on Turris OS 3.x, but I am sure that this happens on newer versions as well.Turris OS 5.2.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/32Fix info file naming upon import2023-08-16T13:59:26+02:00David HopfmuellerFix info file naming upon import**Current behaviour:** Upon import, schnapps prepends a `@` to the info file's name, e.g., `@19.info` (`@19` is the subvolume's name). This makes it 'invisible' to schnapps, e.g., `schnapps list`.
**Expected behaviour:** A file name of ...**Current behaviour:** Upon import, schnapps prepends a `@` to the info file's name, e.g., `@19.info` (`@19` is the subvolume's name). This makes it 'invisible' to schnapps, e.g., `schnapps list`.
**Expected behaviour:** A file name of `19.info`.
This issue was reported in the [forum](https://forum.turris.cz/t/schnapps-import-does-not-work/14474). Patch !15 should rectify it.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/19Add auto rollback functionality with reboot (savepoint and commit)2023-08-16T13:59:22+02:00Karel KociAdd auto rollback functionality with reboot (savepoint and commit)After some discussion with @ljelinek I come up with idea to have automatic rollbacks with restart. The functionality would be that you could call something as `schnapps savepoint` (optionally setup reboot with some timeout) and do config...After some discussion with @ljelinek I come up with idea to have automatic rollbacks with restart. The functionality would be that you could call something as `schnapps savepoint` (optionally setup reboot with some timeout) and do configuration that could potentially cut you from router. When all goes correctly then user could call `schnapps commit` to discard savepoint.
The use case is to simply make remote management even more resilient against breakage without even needing someone to go to location and rollback router using button. Also it is easier to explain router restart (just pull power out and plug it back in) than rollback to other people.
The implementation details would be that schnapps would simply move current root (`@`) to snapshot (same as it is done with rollback) and marked it by new type `savepoint`. In place of `@` new read-write snapshot from original `@` would be created. With reboot router would boot to old version of system while new one would be now old savepoint snapshot. `commit` operation would do flip of new and old root back. That means that with commit savepoint snapshot would become old version of system and current root would become again `@`. It might be beneficial to instead of introducing just `savepoint` snapshot type to introduce two new types instead. `savepoint` for the committed save point and something like `savepoint-rollback` for original root that was not committed and rollback with reboot occurred because of that.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/33Add command to know version of schnapps2023-08-16T13:59:19+02:00Josef SchlehoferAdd command to know version of schnappsI noticed that there is no way how I can check version of schnapps in command-line interface. I can figure it out by opkg, but there should command in schnapps e.g. `schnapps --version` to know which version I have installed. This can be...I noticed that there is no way how I can check version of schnapps in command-line interface. I can figure it out by opkg, but there should command in schnapps e.g. `schnapps --version` to know which version I have installed. This can be useful while testing this binary in CI and current test inside Docker container is that it tries to use:
```
schnapps --version
schnapps -version
schnapps version
```
But it didn't found the version. For example, pkgpdate provides such opinion.
```
root@omnia:~# pkgupdate --version
pkgupdate 69.0.0
```Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/30schnapps rlist command does not work2023-08-16T13:59:16+02:00Jakub Kákonaschnapps rlist command does not workHi,
I have made to correctly working the "schnapps sync" command, which generate bunch of files at remote server.
[kaklik@kapybara:~]$ ls -la /storage/stations/CAR0/Omnia/
total 2068696
drwxr-xr-x 2 kaklik wheel 32 ...Hi,
I have made to correctly working the "schnapps sync" command, which generate bunch of files at remote server.
[kaklik@kapybara:~]$ ls -la /storage/stations/CAR0/Omnia/
total 2068696
drwxr-xr-x 2 kaklik wheel 32 Dec 30 10:51 .
drwxr-xr-x 5 kaklik wheel 5 Dec 29 23:09 ..
-rw-r--r-- 1 kaklik wheel 87 Dec 30 00:19 omnia-medkit-omnia-12.info
-rw-r--r-- 1 kaklik wheel 137311881 Dec 30 00:19 omnia-medkit-omnia-12.tar.gz
-rw-r--r-- 1 kaklik wheel 87 Dec 30 00:24 omnia-medkit-omnia-15.info
-rw-r--r-- 1 kaklik wheel 137286750 Dec 30 00:24 omnia-medkit-omnia-15.tar.gz
-rw-r--r-- 1 kaklik wheel 87 Dec 30 00:29 omnia-medkit-omnia-18.info
-rw-r--r-- 1 kaklik wheel 137238822 Dec 30 00:29 omnia-medkit-omnia-18.tar.gz
-rw-r--r-- 1 kaklik wheel 110 Dec 30 10:08 omnia-medkit-omnia-22.info
-rw-r--r-- 1 kaklik wheel 138993096 Dec 30 10:08 omnia-medkit-omnia-22.tar.gz
-rw-r--r-- 1 kaklik wheel 87 Dec 30 00:33 omnia-medkit-omnia-23.info
-rw-r--r-- 1 kaklik wheel 138998798 Dec 30 00:33 omnia-medkit-omnia-23.tar.gz
-rw-r--r-- 1 kaklik wheel 108 Dec 30 10:13 omnia-medkit-omnia-24.info
-rw-r--r-- 1 kaklik wheel 150857328 Dec 30 10:13 omnia-medkit-omnia-24.tar.gz
-rw-r--r-- 1 kaklik wheel 110 Dec 30 10:18 omnia-medkit-omnia-25.info
-rw-r--r-- 1 kaklik wheel 139019243 Dec 30 10:18 omnia-medkit-omnia-25.tar.gz
-rw-r--r-- 1 kaklik wheel 108 Dec 30 10:23 omnia-medkit-omnia-26.info
-rw-r--r-- 1 kaklik wheel 157646567 Dec 30 10:23 omnia-medkit-omnia-26.tar.gz
-rw-r--r-- 1 kaklik wheel 110 Dec 30 10:27 omnia-medkit-omnia-27.info
-rw-r--r-- 1 kaklik wheel 139034272 Dec 30 10:27 omnia-medkit-omnia-27.tar.gz
-rw-r--r-- 1 kaklik wheel 108 Dec 30 10:32 omnia-medkit-omnia-28.info
-rw-r--r-- 1 kaklik wheel 139035082 Dec 30 10:32 omnia-medkit-omnia-28.tar.gz
-rw-r--r-- 1 kaklik wheel 110 Dec 30 10:37 omnia-medkit-omnia-29.info
-rw-r--r-- 1 kaklik wheel 139031987 Dec 30 10:37 omnia-medkit-omnia-29.tar.gz
-rw-r--r-- 1 kaklik wheel 108 Dec 30 10:42 omnia-medkit-omnia-30.info
-rw-r--r-- 1 kaklik wheel 147727149 Dec 30 10:42 omnia-medkit-omnia-30.tar.gz
-rw-r--r-- 1 kaklik wheel 108 Dec 30 10:46 omnia-medkit-omnia-31.info
-rw-r--r-- 1 kaklik wheel 139029392 Dec 30 10:46 omnia-medkit-omnia-31.tar.gz
-rw-r--r-- 1 kaklik wheel 110 Dec 30 10:51 omnia-medkit-omnia-32.info
-rw-r--r-- 1 kaklik wheel 139031282 Dec 30 10:51 omnia-medkit-omnia-32.tar.gz
-rw-r--r-- 1 kaklik wheel 87 Dec 30 00:38 omnia-medkit-omnia-9.info
-rw-r--r-- 1 kaklik wheel 137029281 Dec 30 00:38 omnia-medkit-omnia-9.tar.gz
Unfortunatelly the "schnapps rlist" command list nothing:
root@omnia:~# schnapps rlist
# | Type | Size | Date | Description
---------------------+-----------+-------------+-----------------------------+------------------------------------
root@omnia:~#Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/48sync doesn't work the way it's described2023-08-16T13:59:13+02:00theerrorsync doesn't work the way it's describedThe description of sync says, it should load all snapshots to remote location and should be readable by rlist. However it's not true.
It's more like "upload" or "export" then sync with remote location, but without .info file.
I had do...The description of sync says, it should load all snapshots to remote location and should be readable by rlist. However it's not true.
It's more like "upload" or "export" then sync with remote location, but without .info file.
I had download version of schnapps from one of [patch version](https://gitlab.nic.cz/turris/schnapps/-/raw/93e5a20f9daaa86b71156ca53c83ae955ea58331/schnapps.sh?inline=false), because of webdav fix.
Turris 1.0, TurrisOS 5.3.3
Usecase:
1. Download patched version
```
wget -q https://gitlab.nic.cz/turris/schnapps/-/raw/93e5a20f9daaa86b71156ca53c83ae955ea58331/schnapps.sh?inline=false -O schnapps.sh
```
2. configure webdav in /etc/conf/schnapps
3. Compare list of locations
```
root@turris:~# ./schnapps.sh list
# | Type | Size | Date | Description
------+-----------+-------------+---------------------------+------------------------------------
30 | post | 8.76MiB | 2021-11-13 18:59:16 +0100 | Automatic post-update snapshot
32 | time | 8.70MiB | 2021-11-21 01:05:03 +0100 | Snapshot created by cron
33 | time | 8.70MiB | 2021-11-28 01:05:03 +0100 | Snapshot created by cron
34 | time | 8.72MiB | 2021-12-05 01:05:04 +0100 | Snapshot created by cron
35 | time | 8.72MiB | 2021-12-12 01:05:03 +0100 | Snapshot created by cron
36 | pre | 8.72MiB | 2021-12-14 16:02:42 +0100 | Automatic pre-update snapshot
37 | post | 8.72MiB | 2021-12-14 16:02:54 +0100 | Automatic post-update snapshot
38 | time | 816.00KiB | 2021-12-19 01:05:02 +0100 | Snapshot created by cron
39 | pre | 288.00KiB | 2021-12-20 12:42:03 +0100 | Automatic pre-update snapshot
40 | post | 128.00KiB | 2021-12-20 12:43:10 +0100 | Automatic post-update snapshot
41 | pre | 128.00KiB | 2021-12-20 16:27:24 +0100 | Automatic pre-update snapshot
42 | rollback | 257.08MiB | 2021-12-20 21:57:27 +0100 | Rollback to snapshot 38
43 | pre | 160.00KiB | 2021-12-20 22:01:27 +0100 | Automatic pre-update snapshot
44 | post | 96.00KiB | 2021-12-20 22:02:32 +0100 | Automatic post-update snapshot
45 | pre | 144.00KiB | 2021-12-21 01:24:27 +0100 | Automatic pre-update snapshot
46 | post | 12.20MiB | 2021-12-21 01:39:15 +0100 | Automatic post-update snapshot (TurrisOS 5.3.3)
47 | single | 220.00KiB | 2021-12-21 18:45:19 +0100 | post upgrade TOC5
root@turris:~# ./schnapps.sh rlist
# | Type | Size | Date | Description
----------------------+-----------+-------------+---------------------------+------------------------------------
```
4. Run sync
```
root@turris:~# ./schnapps.sh sync -t time
./
./bin/
./bin/killall
./bin/vi
./bin/test
...
...
...
...
./.gnupg/random_seed
./var
./boot.scr
Current system was exported into /NetBackup/turris on webdav://xxxx.yyyyy.zz:5006/ as schnapps-medkit-20211222
```
5. Check results
```
root@turris:~# ./schnapps.sh list
# | Type | Size | Date | Description
------+-----------+-------------+---------------------------+------------------------------------
30 | post | 8.76MiB | 2021-11-13 18:59:16 +0100 | Automatic post-update snapshot
32 | time | 8.70MiB | 2021-11-21 01:05:03 +0100 | Snapshot created by cron
33 | time | 8.70MiB | 2021-11-28 01:05:03 +0100 | Snapshot created by cron
34 | time | 8.72MiB | 2021-12-05 01:05:04 +0100 | Snapshot created by cron
35 | time | 8.72MiB | 2021-12-12 01:05:03 +0100 | Snapshot created by cron
36 | pre | 8.72MiB | 2021-12-14 16:02:42 +0100 | Automatic pre-update snapshot
37 | post | 8.72MiB | 2021-12-14 16:02:54 +0100 | Automatic post-update snapshot
38 | time | 816.00KiB | 2021-12-19 01:05:02 +0100 | Snapshot created by cron
39 | pre | 288.00KiB | 2021-12-20 12:42:03 +0100 | Automatic pre-update snapshot
40 | post | 128.00KiB | 2021-12-20 12:43:10 +0100 | Automatic post-update snapshot
41 | pre | 128.00KiB | 2021-12-20 16:27:24 +0100 | Automatic pre-update snapshot
42 | rollback | 257.08MiB | 2021-12-20 21:57:27 +0100 | Rollback to snapshot 38
43 | pre | 160.00KiB | 2021-12-20 22:01:27 +0100 | Automatic pre-update snapshot
44 | post | 96.00KiB | 2021-12-20 22:02:32 +0100 | Automatic post-update snapshot
45 | pre | 144.00KiB | 2021-12-21 01:24:27 +0100 | Automatic pre-update snapshot
46 | post | 12.20MiB | 2021-12-21 01:39:15 +0100 | Automatic post-update snapshot (TurrisOS 5.3.3)
47 | single | 220.00KiB | 2021-12-21 18:45:19 +0100 | post upgrade TOC5
root@turris:~# ./schnapps.sh rlist
# | Type | Size | Date | Description
----------------------+-----------+-------------+---------------------------+------------------------------------
```
Listing of target folder:
```
dav:/NetBackup/turris/> ls
Listing collection `/NetBackup/turris/': succeeded.
Coll: old 0 Dec 22 00:57
*schnapps-medkit-turris-20211221.tar.gz 103378475 Dec 22 00:05
*schnapps-medkit-turris-20211222.tar.gz 103378786 Dec 22 01:08
dav:/NetBackup/turris/>
```
---
---
EXPECTED: Local and remote location are in sync, snapshots + .info
ACTUAL: Only one exported medkit file, nothing else, no .info for later import etc.https://gitlab.nic.cz/turris/schnapps/-/issues/47schnapps rlist -j produces invalid JSON2023-08-16T13:59:11+02:00Luca Beltrameschnapps rlist -j produces invalid JSONExample:
```json
schnapps rlist -j
{ "snapshots": [
{ "number": omnia-medkit-seldon-22, "type": "time", "size": "57.1M", "created": "2021-10-28 15:51:50 +0200", "description": "Pre-export snapshot" }
] }
```
The snapshot was created b...Example:
```json
schnapps rlist -j
{ "snapshots": [
{ "number": omnia-medkit-seldon-22, "type": "time", "size": "57.1M", "created": "2021-10-28 15:51:50 +0200", "description": "Pre-export snapshot" }
] }
```
The snapshot was created by:
```
/usr/bin/schnapps create -t time "Pre-export snapshot"
```
Then uploaded with
```
/usr/bin/schnapps upload $ID_OF_SNAPSHOT
```
In other words, the "number" for a remote snapshot is the full name, rather than simply 22. Thus the JSON produced is invalid.https://gitlab.nic.cz/turris/schnapps/-/issues/49Rename snapshot identifier in json output from "number" to something more fit...2022-01-17T16:21:06+01:00Martin MatějekRename snapshot identifier in json output from "number" to something more fittingAFAIK Commit https://gitlab.nic.cz/turris/schnapps/-/commit/89952d49938aaa4ffdd0797ba347d8cc63a6fd3d is intended to fix turris/schnapps#47.
However in turn it broke [reading list of snapshots in foris-controller](https://gitlab.nic.cz/t...AFAIK Commit https://gitlab.nic.cz/turris/schnapps/-/commit/89952d49938aaa4ffdd0797ba347d8cc63a6fd3d is intended to fix turris/schnapps#47.
However in turn it broke [reading list of snapshots in foris-controller](https://gitlab.nic.cz/turris/foris-controller/foris-controller-schnapps-module/-/issues/10), thus breaking reForis snapshots page too.
>In listing snapshots, the snapshot number does not necessary need to
> be a number anymore, especially with remote snapshots. So let's put ti
> in quotes so it is always a string.
I see the reasoning behind the fix, but I wouldn't call it "number" anymore.
Based on its name, anyone could assume numeric value and try to validate it like number (actually as integer in foris-controller) or process it like number, which would fail on arbitrary string.
So I would suggest renaming it to "snapshot_id" or something more fitting.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/43Can not connect to remotes when the password contains special characters (:@+...2021-08-16T14:25:23+02:00Michal VasilekCan not connect to remotes when the password contains special characters (:@+\) with CLIThis can probably be solved by adding `-p <password>` and `-u <username>` options.This can probably be solved by adding `-p <password>` and `-u <username>` options.https://gitlab.nic.cz/turris/schnapps/-/issues/36Schnapps creates directory if sshfs mount fails2021-07-22T09:13:30+02:00Lukas JelinekSchnapps creates directory if sshfs mount failsOriginally from this forum comment (by `dmth`): https://forum.turris.cz/t/uploading-snapshots-with-schnapps-by-ssh-help-needed/13532/8
If sshfs is unable to mount the remote directory, for instance because of insufficient file permissio...Originally from this forum comment (by `dmth`): https://forum.turris.cz/t/uploading-snapshots-with-schnapps-by-ssh-help-needed/13532/8
If sshfs is unable to mount the remote directory, for instance because of insufficient file permissions, schnapps will create the folder `/mnt/.remote-snapshotson` the local storage, for instance `mmcblk1p1`, and will even report a successful backup. In my opinion, schnapps should die when sshfs fails.
For the record, this is what worked for me:
1. Store username and Host-IP for the remote host in `.ssh/config` of the turris router.
2. Make sure the user has write permissions to the backup-directory.
3. `schnapps upload NUMBEROFSNAPSHOT ssh://remotehostnamefromsshconfig:/absolute/path/to/directory/`Michal HruseckyMichal Hrusecky