schnapps issueshttps://gitlab.nic.cz/turris/schnapps/-/issues2019-11-18T16:53:36+01:00https://gitlab.nic.cz/turris/schnapps/-/issues/13[feature suggestion] Automatic sync on creating/modifying snapshots2019-11-18T16:53:36+01:00David Beitey[feature suggestion] Automatic sync on creating/modifying snapshotsWhen reading the documentation for sync (https://docs.turris.cz/geek/schnapps/schnapps/#remote-manipulation-with-snapshots), I got the impression from setting up a remote URL as part of the 'global' configuration that schnapps might auto...When reading the documentation for sync (https://docs.turris.cz/geek/schnapps/schnapps/#remote-manipulation-with-snapshots), I got the impression from setting up a remote URL as part of the 'global' configuration that schnapps might automatically keep things in sync when creating/modifying/deleting snapshots.
This isn't currently the case so it'd be great if there was an option to enable this -- or else made the default if a remote URL is configured. I feel this is a sensible default as it would help ensure remote snapshots are always up-to-date (particularly helpful in the case of backups).
I've set up `cron` to run `schnapps sync` periodically, but given the [schedule for schnapps](https://gitlab.labs.nic.cz/turris/schnapps/blob/master/schnapps.cron) it's fiddly trying to ensure calls to `sync` run at the right times.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/21Add support for relationship between snapshots on different filesystems2021-02-22T10:25:14+01:00Karel KociAdd support for relationship between snapshots on different filesystemsWith storage plugin and rollbacks it is problematic that all files on external storage are kept as they were. This can cause rollback to break anything that has files in `/srv`.
It would be nice to be able to tie together snapshots on d...With storage plugin and rollbacks it is problematic that all files on external storage are kept as they were. This can cause rollback to break anything that has files in `/srv`.
It would be nice to be able to tie together snapshots on different filesystems so they will be always rolled back together.
Additionally tie together different filesystems so creating snapshot on one will create a snapshot on the second one as well.https://gitlab.nic.cz/turris/schnapps/-/issues/26Decide what to do about subvolumes2020-09-16T15:05:49+02:00Michal HruseckyDecide what to do about subvolumesDecide what to do about subvolumes that are bellow the original subvolume.
Options:
* notify user that he is doing something he shouldn't
* snapshot them recursivelly
I'm leaning more towards the first option. Second option kinda defi...Decide what to do about subvolumes that are bellow the original subvolume.
Options:
* notify user that he is doing something he shouldn't
* snapshot them recursivelly
I'm leaning more towards the first option. Second option kinda defies the purpose of the subvolume. Lets meditate about it.https://gitlab.nic.cz/turris/schnapps/-/issues/28Add some sort of target rollback selection instead of default latest snapshot2021-02-22T10:51:47+01:00Karel KociAdd some sort of target rollback selection instead of default latest snapshotI am commonly experiencing issue that router gets stuck in some situation after update. In such case rollback using button is no use because it rollbacks it back to post-update state with existing error.
I think that solution is simple ...I am commonly experiencing issue that router gets stuck in some situation after update. In such case rollback using button is no use because it rollbacks it back to post-update state with existing error.
I think that solution is simple and that is to not automatically rollback to just any snapshot. I see two possible ways but there might be even more:
* Have some selection for automatic rollback. That is something like pointer to snapshot that should be used for that. We can move it for example after successful boot (thus ensuring that router at least boots after rollback).
* Allow snapshot to select if it should be target of automatic rollback (of course using number should still work). The use case is to mark post-update snapshot that is automatically created as not target of automatic rollback selection.
It would be also awesome if new solution would work with rollback mechanism of previous schnapps commands as that would make it immediately available to all users.https://gitlab.nic.cz/turris/schnapps/-/issues/37btrfs instruction not supported on TurrisOS 5.2.12023-08-16T14:00:43+02:00Mikebtrfs instruction not supported on TurrisOS 5.2.1`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on ...`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on '/srv'
[1] 22243 illegal hardware instruction btrfs sub show -uh /srv
➜ ~ btrfs sub show -u /srv
btrfs subvolume show: exactly 1 argument expected, 0 given
`https://gitlab.nic.cz/turris/schnapps/-/issues/38Valid WebDAV server, gives Invalid URL message2021-12-22T11:20:56+01:00MikeValid WebDAV server, gives Invalid URL messageconfig/schnapps
`
config remote 'phone'
option url 'webdav://phone.n3labs:443/'
option path '/turris/backups'
option user 'mobile'
option password 'givemesrc'
option sync_types 'single,time'
`
...config/schnapps
`
config remote 'phone'
option url 'webdav://phone.n3labs:443/'
option path '/turris/backups'
option user 'mobile'
option password 'givemesrc'
option sync_types 'single,time'
`
https://apps.apple.com/us/app/working-copy-git-client/id896694807
![51D32B8C-B723-4AE6-B94D-4C5CBE19E61F](/uploads/6439a240e0540961a9c0d337b9557ee6/51D32B8C-B723-4AE6-B94D-4C5CBE19E61F.png)
Gives message:
/etc/config/schnapps" 23L, 668C written
➜ ~ schnapps rlist
Invalid URL
➜ ~ schnapps sync
Invalid URL
➜ ~Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/39Allow import of medkits2021-06-21T11:10:10+02:00Karel KociAllow import of medkitsRight now the only way to import medkit is to import it as a factory. This is in most cases the correct way user wants to import medkit but sometimes it makes sense to want to import it just like the regular snapshot without having an in...Right now the only way to import medkit is to import it as a factory. This is in most cases the correct way user wants to import medkit but sometimes it makes sense to want to import it just like the regular snapshot without having an info file. I mostly use it when someone sends me the image to test some issue. I do not want to replace the factory image and I do want to remove it afterwards.
My suggestion is to allow import of generic medkit with switch `-m`:
```
schnapps import -m omnia-medkit-100.tar.gz
```
It would automatically fill in info for example as if following info file would be provided:
```
TYPE="single"
DESCRIPTION="Medkit: ${file%.tar.gz}"
CREATED="$(date)"
```Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/41Lock file is left in /tmp in rescue SSH shell2021-08-13T09:34:29+02:00petrcechLock file is left in /tmp in rescue SSH shellSchnapps do not remove LOCK directory in `/tmp` when started in rescue mode 5.
The reason is missing `rmdir` command in busybox.
----------------------------------------------------
Zdravím,
při startu MOXe a režimu 5 - ssh na 192.168...Schnapps do not remove LOCK directory in `/tmp` when started in rescue mode 5.
The reason is missing `rmdir` command in busybox.
----------------------------------------------------
Zdravím,
při startu MOXe a režimu 5 - ssh na 192.168.1.1 nemaže schnapps LOCK-adresář v /tmp.
Příčinou je chybějící rmdir příkaz v busyboxu. "Testováno" po pokusu aktualizovat pár balíčku v Turris 6.0 a následném zamrznutí.
rm -rf je podporováno
PetrMichal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/42schnapps cli should exit when given invalid arguments2022-03-15T17:05:08+01:00Michal Vasilekschnapps cli should exit when given invalid argumentsRunning `schnapps cleanup 10` or a different command with invalid arguments should fail with an exit code 1 and an error message. Otherwise, users might think that their command was correct and succeeeded, but only the valid part of it w...Running `schnapps cleanup 10` or a different command with invalid arguments should fail with an exit code 1 and an error message. Otherwise, users might think that their command was correct and succeeeded, but only the valid part of it will be executed.
For example users might expect `schnapps cleanup 10` to leave 10 most recent snapshots, the 10 argument will be silently ignored.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/44SMB1 mounts are not supported2021-10-20T09:34:48+02:00Michal VasilekSMB1 mounts are not supportedTrying to mount a Synology NAS, I get this error:
```
mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Can't access remote filesystem
root@omnia:~# dmesg
...
[ 56...Trying to mount a Synology NAS, I get this error:
```
mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Can't access remote filesystem
root@omnia:~# dmesg
...
[ 5686.349245] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
```
Adding `-o vers=1.0` to the mount.cifs command fixes this issue for me. I think the defaults are correct now, maybe adding an option (with a warning) to use the 1.0 version or documenting this would make life easier for some people. If this is the default behavior of some (?) older (?) Synology NASes, this issue would be common.
Either way, I think this message in dmesg is logged even when the server supports SMB3, so it should probably be silenced with `-o vers=default`.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/46using other root option throws ntfs errors2021-10-20T09:34:16+02:00th1j5using other root option throws ntfs errorsI tried to use schnapps instead of the lower-level btrfs tools to snapshot my (RAID) btrfs filesystem, by using the `-d root` option.
Then I get weird ntfs-3g errors...
```sh
root@turris:/mnt# btrfs sub list /mnt/DATA_NAS/
ID 256 gen 15...I tried to use schnapps instead of the lower-level btrfs tools to snapshot my (RAID) btrfs filesystem, by using the `-d root` option.
Then I get weird ntfs-3g errors...
```sh
root@turris:/mnt# btrfs sub list /mnt/DATA_NAS/
ID 256 gen 1570 top level 5 path @
ID 260 gen 29 top level 5 path @DATA_other
ID 261 gen 1572 top level 5 path @DATA_NAS
```
```
root@turris:/mnt# schnapps -d "/mnt/DATA_NAS" list
ERROR: unable to access /dev/sdb
/dev/sda: No such file or directory
ntfs-3g: Failed to access volume '/dev/sdb
/dev/sda': No such file or directory
ntfs-3g 2017.3.23 integrated FUSE 27 - Third Generation NTFS Driver
Configuration type 1, XATTRS are on, POSIX ACLS are off
Copyright (C) 2005-2007 Yura Pakhuchiy
Copyright (C) 2006-2009 Szabolcs Szakacsits
Copyright (C) 2007-2017 Jean-Pierre Andre
Copyright (C) 2009 Erik Larsson
Usage: ntfs-3g [-o option[,...]] <device|image_file> <mount_point>
Options: ro (read-only mount), windows_names, uid=, gid=,
umask=, fmask=, dmask=, streams_interface=.
Please see the details in the manual (type: man ntfs-3g).
Example: ntfs-3g /dev/sda1 /mnt/windows
News, support and information: http://tuxera.com
Can't mount root partition
```
It would be nice to use schnapps as a high-level tool, so if I can provide any other information, let me know.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/50Readonly snapshots2023-08-16T14:00:39+02:00Jip-HopReadonly snapshotsIt looks like schnapps creates writable snapshots. Why is that? Would all schnapps features still work if read-only snapshots would be made instead?
Schnapps features look great, especially the `rollback` command! I'd like to use it for...It looks like schnapps creates writable snapshots. Why is that? Would all schnapps features still work if read-only snapshots would be made instead?
Schnapps features look great, especially the `rollback` command! I'd like to use it for my Debian home server with btrfs root filesystem (data is stored on ZFS disks). Possibly combined with [grub-btrfs](https://github.com/Antynea/grub-btrfs) to boot into snapshots. But booting into a writable snapshot made by schnapps would modify its contents, which could mess up the last known working state of the system. I think that's why e.g. `snapper` doesn't create writable snapshots by default.
Would it be possible to make read-only snapshots the default? Or if that's incompatible with some features, add a parameter to create readonly snapshots instead?Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/51Local sync2023-08-16T14:00:38+02:00Adam UhlířLocal syncSchnapps seems very powerful but I am missing one feature that would make it in my eyes complete.
I would like to sync Schnapps's snapshots onto another **local** harddrive.
My use case is that I have BTRFS RAID1 with HDD that works ...Schnapps seems very powerful but I am missing one feature that would make it in my eyes complete.
I would like to sync Schnapps's snapshots onto another **local** harddrive.
My use case is that I have BTRFS RAID1 with HDD that works as "cold" storage and then another USB flash drive where I have all the LXC containers, logs etc. as I am trying to minimize spinning the HDDs as they are close to my bed and they make ugly noise 😅 I understand that sooner or later the USB flash drive will die so I want to back it up to the HDD from time to time and Schnapps would be perfect for this task except that it can't sync locally.
I am planning to try to work around this by SSHing to localhost, but I would say that this feature should be supported natively.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/52schnapps -d /srv with zstd compression leads to periodical load average of 30+2023-08-16T14:00:34+02:00Orest Worhaczschnapps -d /srv with zstd compression leads to periodical load average of 30+Hi,
I am using msata drive formatted with Storage Plugin and I have chosen in Luci to mount it with:
```
/dev/sda2 on /srv type btrfs (rw,noatime,nodiratime,compress=zstd,ssd,space_c
ache,subvolid=743,subvol=/@)
```
While it was working...Hi,
I am using msata drive formatted with Storage Plugin and I have chosen in Luci to mount it with:
```
/dev/sda2 on /srv type btrfs (rw,noatime,nodiratime,compress=zstd,ssd,space_c
ache,subvolid=743,subvol=/@)
```
While it was working it was working but I think that using schnapps on such a system leads to load average range 30+ in some cases and the system becomes totally unresponsive. Cannot even login via ssh.
I was wondering that its acctually doing something so I let it be that much loaded and at some point it went down to load average 5+ and I could login and see htop and netdata and the cpu was at 50% and according to netdata it was used by 'system'. But later on it went back to unresponsive state and dropped ssh connection.
I had this problem before as it lead me to invalid snapshots half-made as the router just hang in the middle of creating a snapshot. So I taken out the drive connected it via adapter to my laptop. Deleted all btrfs subvolumes except @ and recompressed all files with btrfs defrag and connected it back and it was all again around 1-4% cpu usage.
Before I also tested that taking out the drive from Omnia also fixed this extreme load. With the drive unresponsive, without just fine.
So I request to test schnapps with btrfs compressed drives as all problems begin when I try to do some schnapps operation like creating or deleting the snapshot.
Thanks!Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/53Race condition when trying to delete two snapshots at once2023-08-16T14:00:32+02:00Michal VasilekRace condition when trying to delete two snapshots at onceAfter deleting a lot of snapshots at once in Reforis, some of the snapshots I deleted no longer exist and don't have a size, but are still shown in `schnapps list`. I can reproduce this with plain schnapps by running two `delete` command...After deleting a lot of snapshots at once in Reforis, some of the snapshots I deleted no longer exist and don't have a size, but are still shown in `schnapps list`. I can reproduce this with plain schnapps by running two `delete` commands at once, so I think the protection against multiple concurrent runs is not correct.
```
root@turris:~# schnapps list
# | Type | Size | Date | Description
------+-----------+-------------+---------------------------+------------------------------------
1 | single | 16.00KiB | 2022-08-19 22:11:15 +0200 | User created snapshot
3 | single | 16.00KiB | 2022-08-19 22:13:04 +0200 | User created snapshot
4 | single | | 2022-08-19 22:13:05 +0200 | User created snapshot
5 | single | 16.00KiB | 2022-08-19 22:13:16 +0200 | User created snapshot
6 | single | | 2022-08-19 22:13:16 +0200 | User created snapshot
7 | single | 16.00KiB | 2022-08-19 22:13:17 +0200 | User created snapshot
10 | single | | 2022-08-19 22:13:19 +0200 | User created snapshot
11 | single | | 2022-08-19 22:13:20 +0200 | User created snapshot
12 | single | 16.00KiB | 2022-08-19 22:13:20 +0200 | User created snapshot
13 | single | 16.00KiB | 2022-08-19 22:13:21 +0200 | User created snapshot
14 | single | | 2022-08-19 22:13:22 +0200 | User created snapshot
19 | single | | 2022-08-19 22:13:26 +0200 | User created snapshot
20 | single | | 2022-08-19 22:13:27 +0200 | User created snapshot
43 | pre | | 2022-07-19 11:19:55 +0200 | Automatic pre-update snapshot (TurrisOS 6.0)
48 | post | | 2022-08-11 18:56:15 +0200 | Automatic post-update snapshot (TurrisOS 6.0)
root@turris:~# schnapps delete 48
WARNING: Snapshot number 48 does not exists!
```
`schnapps delete` should either delete the snapshots properly or not delete them at all.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/54Remote user not respected with sshfs2023-08-16T14:00:30+02:00Michal HruseckyRemote user not respected with sshfsSetting user in config doesn't change the username tried when mounting via sshfs.Setting user in config doesn't change the username tried when mounting via sshfs.Michal HruseckyMichal Hrusecky