Wimpie

Members
  • Posts

    171
  • Joined

  • Last visited

Everything posted by Wimpie

  1. Please read the manual, it's all there. Eg: Paths and folders PAPERLESS_CONSUMPTION_DIR=<path> This where your documents should go to be consumed. Make sure that it exists and that the user running the paperless service can read/write its contents before you start Paperless. Don't change this when using docker, as it only changes the path within the container. Change the local consumption directory in the docker-compose.yml file instead. Defaults to "../consume/", relative to the "src" directory. PAPERLESS_DATA_DIR=<path> This is where paperless stores all its data (search index, SQLite database, classification model, etc). Defaults to "../data/", relative to the "src" directory. PAPERLESS_TRASH_DIR=<path> Instead of removing deleted documents, they are moved to this directory. This must be writeable by the user running paperless. When running inside docker, ensure that this path is within a permanent volume (such as "../media/trash") so it won't get lost on upgrades. Note that the directory must exist prior to using this setting. Defaults to empty (i.e. really delete documents). PAPERLESS_MEDIA_ROOT=<path> This is where your documents and thumbnails are stored. You can set this and PAPERLESS_DATA_DIR to the same folder to have paperless store all its data within the same volume. Defaults to "../media/", relative to the "src" directory. PAPERLESS_STATICDIR=<path> Override the default STATIC_ROOT here. This is where all static files created using "collectstatic" manager command are stored. Unless you're doing something fancy, there is no need to override this. If this is changed, you may need to run collectstatic again. Defaults to "../static/", relative to the "src" directory. PAPERLESS_LOGGING_DIR=<path> This is where paperless will store log files. Defaults to PAPERLESS_DATA_DIR/log/. PAPERLESS_NLTK_DIR=<path> This is where paperless will search for the data required for NLTK processing, if you are using it. If you are using the Docker image, this should not be changed, as the data is included in the image already. Previously, the location defaulted to PAPERLESS_DATA_DIR/nltk. Unless you are using this in a bare metal install or other setup, this folder is no longer needed and can be removed manually. Defaults to /usr/share/nltk_data
  2. Docker containers don't always expose the config file. From the manual: "If you run paperless on docker, paperless.conf is not used. Rather, configure paperless by copying necessary options to docker-compose.env". Unraid uses a slightly modified docker system. The docker-compose.env file is not adjustable by a user. This means that in unraid you configure the application through variables... https://docs.paperless-ngx.com/configuration/ An example:
  3. Did you read the manual? https://docs.paperless-ngx.com/ Is this the first container (docker) you install? look at:
  4. Thanks for the template. It installed ok on my server (got it's own IP). Now looking to configure it.
  5. Real life is very busy, but found now some time... Running the filesystem check on disk 1 in unRAID v6.9.2 resulted in this: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata CRC error detected at 0x47542a, xfs_sb block 0x0/0x200 superblock has bad CRC for ag 0 would zero unused portion of primary superblock (AG #0) - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. So should I run the repair now without the -n flag (let it correct the error)? No problem running this under 6.9.2, or should I do it under 6.11.0? Thanks
  6. It seems I misnamed the diagnostics, 6.9.2 is 6.11.0 and reversed. Anyway, I get this from 6.11.0: Oct 1 17:52:18 TV-Tower emhttpd: Mounting disks... Oct 1 17:52:20 TV-Tower emhttpd: shcmd (102): mkdir -p /mnt/disk1 Oct 1 17:52:20 TV-Tower emhttpd: shcmd (103): mount -t xfs -o noatime,nouuid /dev/md1 /mnt/disk1 Oct 1 17:52:21 TV-Tower kernel: SGI XFS with ACLs, security attributes, no debug enabled Oct 1 17:52:21 TV-Tower kernel: XFS (md1): Metadata CRC error detected at xfs_sb_read_verify+0x11e/0x1aa [xfs], xfs_sb block 0x0 Oct 1 17:52:21 TV-Tower kernel: XFS (md1): Unmount and run xfs_repair Oct 1 17:52:21 TV-Tower kernel: XFS (md1): First 128 bytes of corrupted metadata buffer: Oct 1 17:52:21 TV-Tower kernel: 00000000: 58 46 53 42 00 00 10 00 00 00 00 00 74 70 25 49 XFSB........tp%I Oct 1 17:52:21 TV-Tower kernel: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Oct 1 17:52:21 TV-Tower kernel: 00000020: 24 04 07 d5 8a d8 4e 24 b9 9b ad 55 55 e3 a8 49 $.....N$...UU..I Oct 1 17:52:21 TV-Tower kernel: 00000030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80 .... ........... Oct 1 17:52:21 TV-Tower kernel: 00000040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 ................ Oct 1 17:52:21 TV-Tower kernel: 00000050: 00 00 00 01 0a ea 85 1b 00 00 00 0b 00 00 00 00 ................ Oct 1 17:52:21 TV-Tower kernel: 00000060: 00 05 75 42 b4 b4 02 00 01 00 00 10 00 00 00 00 ..uB............ Oct 1 17:52:21 TV-Tower kernel: 00000070: 00 00 00 00 00 00 00 00 0c 09 08 04 1c 00 00 05 ................ Oct 1 17:52:21 TV-Tower kernel: XFS (md1): SB validate failed with error -74. Oct 1 17:52:21 TV-Tower root: mount: /mnt/disk1: mount(2) system call failed: Structure needs cleaning. Oct 1 17:52:21 TV-Tower root: dmesg(1) may have more information after failed mount system call. Oct 1 17:52:21 TV-Tower emhttpd: shcmd (103): exit status: 32 Oct 1 17:52:21 TV-Tower emhttpd: /mnt/disk1 mount error: Wrong or no file system Oct 1 17:52:21 TV-Tower emhttpd: shcmd (104): umount /mnt/disk1 Oct 1 17:52:21 TV-Tower root: umount: /mnt/disk1: not mounted. Oct 1 17:52:21 TV-Tower emhttpd: shcmd (104): exit status: 32 Oct 1 17:52:21 TV-Tower emhttpd: shcmd (105): rmdir /mnt/disk1 Oct 1 17:52:21 TV-Tower emhttpd: shcmd (106): mkdir -p /mnt/disk2 While under 6.9.2 I get: Oct 1 17:41:07 TV-Tower emhttpd: Mounting disks... Oct 1 17:41:07 TV-Tower emhttpd: shcmd (166): /sbin/btrfs device scan Oct 1 17:41:09 TV-Tower root: Scanning for Btrfs filesystems Oct 1 17:41:09 TV-Tower emhttpd: shcmd (167): mkdir -p /mnt/disk1 Oct 1 17:41:09 TV-Tower emhttpd: shcmd (168): mount -t xfs -o noatime /dev/md1 /mnt/disk1 Oct 1 17:41:09 TV-Tower kernel: SGI XFS with ACLs, security attributes, no debug enabled Oct 1 17:41:09 TV-Tower kernel: XFS (md1): Deprecated V4 format (crc=0) will not be supported after September 2030. Oct 1 17:41:09 TV-Tower kernel: XFS (md1): Mounting V4 Filesystem Oct 1 17:41:09 TV-Tower kernel: XFS (md1): Ending clean mount Oct 1 17:41:09 TV-Tower kernel: xfs filesystem being mounted at /mnt/disk1 supports timestamps until 2038 (0x7fffffff) Oct 1 17:41:09 TV-Tower emhttpd: shcmd (169): xfs_growfs /mnt/disk1 Oct 1 17:41:09 TV-Tower root: meta-data=/dev/md1 isize=256 agcount=11, agsize=183141659 blks Oct 1 17:41:09 TV-Tower root: = sectsz=512 attr=2, projid32bit=0 Oct 1 17:41:09 TV-Tower root: = crc=0 finobt=0, sparse=0, rmapbt=0 Oct 1 17:41:09 TV-Tower root: = reflink=0 Oct 1 17:41:09 TV-Tower root: data = bsize=4096 blocks=1953506633, imaxpct=5 Oct 1 17:41:09 TV-Tower root: = sunit=0 swidth=0 blks Oct 1 17:41:09 TV-Tower root: naming =version 2 bsize=4096 ascii-ci=0, ftype=0 Oct 1 17:41:09 TV-Tower root: log =internal log bsize=4096 blocks=357698, version=2 Oct 1 17:41:09 TV-Tower root: = sectsz=512 sunit=0 blks, lazy-count=1 Oct 1 17:41:09 TV-Tower root: realtime =none extsz=4096 blocks=0, rtextents=0 Oct 1 17:41:09 TV-Tower emhttpd: shcmd (170): mkdir -p /mnt/disk2 Nothing is changed, except the upgrade. Why do I get this with 6.11.0? Oct 1 17:52:21 TV-Tower kernel: XFS (md1): Metadata CRC error detected at xfs_sb_read_verify+0x11e/0x1aa [xfs], xfs_sb block 0x0
  7. Did you unselect the drive, and then select it again in the same slot (when the array is stopped)? Hope you understand what I mean, if it is disk 3, put the disk 3 slot in "no" drive, and then select the drive again in the disk 3 slot.
  8. I'm not an expert, but before all trying that, why not just reboot the server. You won't do something that can't be undone, and I have a guess it will solve the problem. "new config" is irreverseble, so don't do it without some advice from an expert here. Don't know about the rebuild, but also propably better wait for advice before you do that.
  9. Hi, Decided to upgrade a 6.9.2 server to 6.11.0. Ran "Update Assistant" before and removed Nerdpack. "Update Assistant" said 'good to go'. After the update (running 6.11.0) disk 1 was disabled (Unmountable: Wrong or no file system). This seemed to be the only problem (did not search further). I downgraded to 6.9.2, and disk 1 worked again (disk was mounted). Took a diagnostics. Upgraded to 6.11.0 again, and disk 1 was again disabled. Took again a diagnostics. How do I best solve this? Is there a XFS filesystem error that 6.9.2 can handle and 6.11.0 not. Would a rebuild get rid of that XFS filesystem error (or whatever the problem is)? I don't have a spare drive, could buy one, but prefer not to if not needed. PS: Posted this also in the "General Support" forum, including the 2 diagnostic files. I post here just to let others know if they have a similar problem.
  10. Hi, Decided to upgrade a 6.9.2 server to 6.11.0. Ran "Update Assistant" before and removed Nerdpack. "Update Assistant" said 'good to go'. After the update (running 6.11.0) disk 1 was disabled (Unmountable: Wrong or no file system). This seemed to be the only problem (did not search further). No files were accessable on disk 1, they are not simulated. I downgraded to 6.9.2, and disk 1 worked again (disk was mounted). Took a diagnostics. I can access files on disk 1, at least no problems with 1 at random chosen file. Upgraded to 6.11.0 again, and disk 1 was again disabled. Took again a diagnostics. I am now back on 6.9.2. How do I best solve this? Is there a XFS filesystem error that 6.9.2 can handle and 6.11.0 not? Would a rebuild get rid of that XFS filesystem error (or whatever the problem is)? I don't have a spare drive, could buy one, but prefer not to if not needed. tv-tower-diagnostics-6.9.2.zip tv-tower-diagnostics-6.11.0.zip
  11. JorgeB, Thanks. That did it. Didn't know it was so simple...
  12. Hi, I have a X9SRL-F MB, which has 2 1Gb sockets. I added a dual 10Gb NIC and want to use this as my only network connection, ie put a network cable in one of the 2 10Gb sockets. The 1Gb sockets get no cable. Things I already did: - VM's: virbr0 stopped working, but br2 seems to work. I can acces my VM fine, and it has internet connectivity. - Docker: I managed to get it on br2: " IPv4 custom network on interface br2: Subnet: 192.168.157.0/24 Gateway: 192.168.157.1 DHCP pool: not set". The dockers seems to work (updates not). - Also some fiddling to get my router assign the fixed IP for the server (MAC for 10 Gb is of course different from the MAC address of the 1Gb socket) What does not work: I can't seem to give eth2 a DNS server, this appears to be only possible to eth0 How do I do this? Maybe another solution would be to rename the interfaces. See this I checked and the file "70-persistent-net.rules" also exists on unraid, it contains: # PCI device 0x8086:0x10d3 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:d0:f4:6e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth0" # PCI device 0x8086:0x10d3 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:d0:f4:6f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth1" # PCI device 0x8086:0x151c (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:ac:11:b0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth2" # PCI device 0x8086:0x151c (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:ac:11:b1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth3" By changing this file to : # PCI device 0x8086:0x10d3 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:d0:f4:6e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth2" # PCI device 0x8086:0x10d3 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:d0:f4:6f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth1" # PCI device 0x8086:0x151c (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:ac:11:b0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth0" # PCI device 0x8086:0x151c (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:ac:11:b1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KE RNEL=="eth*", NAME="eth3" I think this would also solve my problem. However, how do I change this "70-persistent-net.rules" file so that these changes are preserved across reboots and upgrades (just copy new file over old file would suffice, but how/when in the booting process do I do that)? Can anyone please help so I can update my plugins an dockers again. Another way to fix this is also good for me. Thanks Wim tv-tower-2-diagnostics-20220607-1718.zip
  13. Had the same problem, solved it by uninstalling strace from nerdpack and then getting an older package from: https://slackware.pkgs.org/14.2/slackware-x86_64/strace-4.11-x86_64-1.txz.html Copy it somewhere on your server, get a shell and use : upgradepkg --install-new strace-4.11-x86_64-1.txz Worked for me...
  14. Binhex, thanks to update the docker! I appreciate all the effort you put in this!
  15. A new version is available, see https://www.urbackup.org/server_changelog.html (we are now on 2.4.13, 2.4.15 is available). "Fix corruption on transfer resume with full sparse file transfer" looks like something you want fixed... Can the docker please be upgraded? Thanks!
  16. I am having trouble accessing files in the appdata UrBackUp directory (eg saving an edited urbackupsrv config file). I noticed that the root dir has other file rights than my other dockers. Is this a bug or a feature?
  17. Great docker, thank you! I wanted to enable the temporary file buffers (section 8.5.1 in the manual, this can speedup the backup when you have a slow array), but when I did, all the temp data was (temporarily) saved in the appdata dir. This meant that if CA Backup started to do a backup while UrBackUp was working, that it also saved all those temp files. I tried to set a TMPDIR variable with docker, but that didn't work. It appeared that the TMPDIR var was set in the UrBackUp config file to "/config/urbackup/tmp/", and that the config file overrides the variable. In the end I solved this by just redirecting the docker path to a external (to the docker) directory. The "/mnt/user/Temp_UrBackUPFiles/" dir is on the cache drive with a "prefer" cache setting.
  18. Hi, I booted an old server (has not run for almost a year) and I get a HD disabled (sdq). I looked in the syslog, but I can't find any reason why it's disabled (can't find any error). Like I said, it's an old server (version 6.5.3). Should I update to latest, or would this be a bad idea (first solve the why is the HD disabled?)? Sadly I don't have another spare HD, otherwise I would just let unraid rebuild the disabled HD (it's a server with old HD's from other servers, the smallest spare HD I have on stock is a 8Tb HD, but this is a 4 Tb HD and a HD must be the same or smaller size as the parity HD (also 4Tb)). I probably should check the filesystem, but how? Can someone help me with the best course of action?? Thanks! tv-tower-diagnostics-20190707-2200.zip
  19. bonienl, Thanks I tried it a l hour ago and it didn't work, hence my post. Tried it again a few minutes ago and it now works, so I probably did a typo somewhere the first time. Again thanks for all the effort you put into this...
  20. I did a full had passthrough (real SSD, no vdisk) in an older unraid version as: Is this method not supported anymore? Comments from bonienl seem to suggest so: https://forums.unraid.net/topic/74260-unraid-os-version-660-available/?page=8&tab=comments#comment-685199 Do we always have to go through unassigned devices (/mnt/disks/...)? Comments please...
  21. Now I'm very confused?!? This is a working VM: It's a VM that has it's HD completly for itself (passthrough? or how is it called). It works, and is referenced by id (to survive reboots, sda becomes otherwise maybe sdb). Got it from maybe this thread: There are many more posts that say use /dev/disk/by-id/... You are saying this is not more supported? Edit: maybe I should have written /dev/disk/by-id/...? Edit2: if /dev/disk/by-id/... is valid, then the minor problem is that I would like it browseable/selectable..
  22. So, basicly copy/paste. Another very minor point: Text is cut of and unreadable (separate sub-folder and image will be created b????????)
  23. A minor problem: I used to be able to add a drive to my vm using (see this existing/working VM) With 6.6.0, I can't do that anymore? I don't remember how I entered this ADATA SSD in this existing VM (did I just copy paste??), but it would be nice if /dev/disk/... would be browseable/selectable.