at rustc/da384694807172f0ca40eca2e49a11688aba6e93/library/std/src/panicking.rs:595:17
2021-03-12 16:50:51
stdout
1: std::panicking::rust_panic_with_hook
2021-03-12 16:50:51
stdout
0: bitwarden_rs::init_logging::{{closure}}
2021-03-12 16:50:51
stdout
[2021-03-12 16:50:51.852][panic][ERROR] thread 'main' panicked at 'Failed to turn on WAL: DatabaseError(__Unknown, "file is not a database")': src/db/mod.rs:275
I was curious as my Synology had not been rebooted in 41 days so I just tried a reboot and had no issues with bitwarden_rs coming back up after the reboot. Based on the errors in the log I think bitwarden_rs is unable to access your database file which might be a permissions issue for the user which runs bitwarden_rs.
@pfgcoder commented on GitHub (Mar 13, 2021):
I was curious as my Synology had not been rebooted in 41 days so I just tried a reboot and had no issues with bitwarden_rs coming back up after the reboot. Based on the errors in the log I think bitwarden_rs is unable to access your database file which might be a permissions issue for the user which runs bitwarden_rs.
I was curious as my Synology had not been rebooted in 41 days so I just tried a reboot and had no issues with bitwarden_rs coming back up after the reboot. Based on the errors in the log I think bitwarden_rs is unable to access your database file which might be a permissions issue for the user which runs bitwarden_rs.
Thanks for your reply,but after I change the db.sqlite3 file to 777 for everyone,the problem still there.
@ihxperfect commented on GitHub (Mar 13, 2021):
> I was curious as my Synology had not been rebooted in 41 days so I just tried a reboot and had no issues with bitwarden_rs coming back up after the reboot. Based on the errors in the log I think bitwarden_rs is unable to access your database file which might be a permissions issue for the user which runs bitwarden_rs.
Thanks for your reply,but after I change the db.sqlite3 file to 777 for everyone,the problem still there.
@ultraloveninja commented on GitHub (Mar 16, 2021):
I'm starting to have this same issue within a docker container on my unraid server. Getting this error in the logs:
[panic][ERROR] thread 'main' panicked at 'Failed to turn on WAL: DatabaseError(__Unknown, "disk I/O error")': src/db/mod.rs:275
Looks like it might be related. Figured I'd post up and see if this could be an inherit error as well. I can create another issue request if needed.
@ultraloveninja commented on GitHub (Mar 16, 2021):
I'm starting to have this same issue within a docker container on my unraid server. Getting this error in the logs:
```
[panic][ERROR] thread 'main' panicked at 'Failed to turn on WAL: DatabaseError(__Unknown, "disk I/O error")': src/db/mod.rs:275
```
Looks like it might be related. Figured I'd post up and see if this could be an inherit error as well. I can create another issue request if needed.
What kind of volume storage are you using? If it isa shared filesystem, like NFS, CIFS/Samba, then you need to disable WAL. Since this is embedded into the file, I'm actually not sure how to do that.
Could it be that something has changed on how volumes are configured on your system, or maybe some driver update.
The problem is that file locking isn't working is sqlite would want which causes this issue
@BlackDex commented on GitHub (Mar 16, 2021):
What kind of volume storage are you using? If it isa shared filesystem, like NFS, CIFS/Samba, then you need to disable WAL. Since this is embedded into the file, I'm actually not sure how to do that.
Could it be that something has changed on how volumes are configured on your system, or maybe some driver update.
The problem is that file locking isn't working is sqlite would want which causes this issue
Are you able to copy the database somewhere else and try to open it to see if it is still valid?
It also looks like the file can't be found, or it is corrupt.
@BlackDex commented on GitHub (Mar 16, 2021):
Are you able to copy the database somewhere else and try to open it to see if it is still valid?
It also looks like the file can't be found, or it is corrupt.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @ihxperfect on GitHub (Mar 12, 2021).
after my nas reboot,the bitwarden_rs can not run,the logs shows:
I have tried replace the db.sqlite3 file that onedrive backup,but it still not work.
@pfgcoder commented on GitHub (Mar 13, 2021):
I was curious as my Synology had not been rebooted in 41 days so I just tried a reboot and had no issues with bitwarden_rs coming back up after the reboot. Based on the errors in the log I think bitwarden_rs is unable to access your database file which might be a permissions issue for the user which runs bitwarden_rs.
@ihxperfect commented on GitHub (Mar 13, 2021):
Thanks for your reply,but after I change the db.sqlite3 file to 777 for everyone,the problem still there.
@ultraloveninja commented on GitHub (Mar 16, 2021):
I'm starting to have this same issue within a docker container on my unraid server. Getting this error in the logs:
Looks like it might be related. Figured I'd post up and see if this could be an inherit error as well. I can create another issue request if needed.
@BlackDex commented on GitHub (Mar 16, 2021):
What kind of volume storage are you using? If it isa shared filesystem, like NFS, CIFS/Samba, then you need to disable WAL. Since this is embedded into the file, I'm actually not sure how to do that.
Could it be that something has changed on how volumes are configured on your system, or maybe some driver update.
The problem is that file locking isn't working is sqlite would want which causes this issue
@ihxperfect commented on GitHub (Mar 16, 2021):
my volume storage is Btrfs,and I had a extra patch(extra.lama) about ds918+.
@BlackDex commented on GitHub (Mar 16, 2021):
Are you able to copy the database somewhere else and try to open it to see if it is still valid?
It also looks like the file can't be found, or it is corrupt.