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/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/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/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/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/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/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 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/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/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/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/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/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/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/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/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/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/40Support Samba2021-07-22T09:11:15+02:00Michal HruseckySupport Sambahttps://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 Hrusecky