Fatal_Flaw

Members
  • Posts

    56
  • Joined

Everything posted by Fatal_Flaw

  1. Nextcloud container just updated, and now it crashes on start. Logs below. I have multiple local directories connected through the external storage app. Those local directories are mounted in the container in /mnt/ as read only (see below for example). Prior to this update, they all worked without issue. I also don't know why it's trying to delete one of the directories. Config Type: Path Name: ISOS Container Path: /mnt/ISOS Host Path: /mnt/user/ISOs/ Access Mode: Read Only rsync: [generator] delete_file: rmdir(local files/ISOS) failed: Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7] Initializing nextcloud 27.1.2.1 ... Upgrading nextcloud from 27.1.1.0 ... cannot delete non-empty directory: local files EDIT: Figured it out. When I was first testing things out, I had created the folder "local files" in the /html/ directory, in which to mount local folders for use with the external storage app. thinking that was a bad idea, I moved them to /mnt/ but forgot to delete that "local files" folder. Apparently, during the upgrade process, nextcloud deletes the contents of the /html/ folder. Because it didn't have permission to delete the folder I had created, the upgrade process was failing. I deleted that folder and it completed successfully.
  2. Files and folders created on a windows computer that has the unraid user share mounted via smb don't have the owner of "nobody". Their owner is the username that was used to mount the share. I know I can fix the permissions with the docker safe new perms tool, but presumably any new files and folders created would have the same problem. I can't figure out why new files/folders are getting the wrong owner.
  3. Anyone else seeing "Unable to sign in." error when trying to sign in to the client? ui.log is showing warn RestAdapter: Error making service request to https://127.0.0.1:4244/v0/LoginRequest : Bad Request Clearing cache, deleting image and recreating it doesn't change it. Still get "Unable to sign in." EDIT: NM, problem went away on it's own.
  4. A search turns up lots of posts about issues deleting files, but I can't find this specific issue. If I delete a file through a user share, the file disappears, but refreshing the window shows it's still there and opening that file produces an error that it can't be found. If I delete the file through a disk share, it is deleted as expected. File system is XFS. Any suggestions on what could be causing this or how to fix it?
  5. I have a situation I've found several mentions of, but haven't been able to untangle a solution. Have SWAG container running on Unraid and working great. It's using a custom docker network, router forwards public IP to unraid ip port 1443 (which is used by swag container). The issue is when accessing sites through swag internally. Because swag uses unraid's IP but with port 1443, if I use local dns to point the unraid IP, I just get the unraid interface rather than whichever address swag would have sent me. I can of course use local dns to get the desired site by manually specifying the port (i.e. calibre.example.com:1443) I've read about NAT reflection, but it seems like there must be a way to get this working without routing all internal traffic through the router. How can I get my domain pointing to swag internally?
  6. Thanks, will do. I definitely have a rats nest of power splitters, so that's a good bet.
  7. Here's what happened. Disk 4 has read/write errors and gets disabled. Ran long SMART test on disk 4 with no errors. Rebuild disk 4 on same physical disk. Completes successfully. ~14 hours after rebuild completed successfully, disk 4 has read/write errors again and gets disabled. ~3 hours after disk 4's errors, disk 5 has read errors but is not disabled. At this point, I'm guessing I should replace the cables on disk 4 and disk 5, but am wondering if there's anything else I should try/do. Diags attached. filebox-diagnostics-20210715-1153.zip
  8. Thanks, that clarified it for me. It didn't occur to me that xfs_repair would be run against the emulated disk rather than the physical disk. Nah, I know what formatting is. My point was that the disk was disabled with the unmountable error due to file system corruption, but the emulated disk was accessible and the data seemed to be intact. So presumably re-assigning that disabled disk as a new one in the config and rebuilding it from parity would write a useable filesystem to the disk. SOLUTION: What I ended up doing Because the drive wasn't being written to when the controller dropped it, I decided it was likely that the data on the physical drive was ok except for the file system corruption. I also already had everything on that drive backed up to CrashPlan as a last resort. I reset the config and told it to trust the parity. Started the array in maintenance mode. I ran xfs_config on the previously disabled disk. It took less than 30 seconds to run and even the verbose output didn't really indicate any issues were found. Restarted the array fully. Drive mounted and everything on the drive is intact (I keep hashes of all the files for verification) Running parity check just in case something got out of sync. I also just ordered a LSI SAS 9207-8i to replace the absolutely awful Marvel based SYBA controller I'm currently using. This is not the first time it's dropped a disk randomly. Thanks for the help everyone!
  9. Thanks for the reply, but I'm confused. I thought rebuilding the drive overwrote everything on it bit for bit regardless of the existing data or file system on it? Why would it matter if I do it before or after xfs_repair? And if I'm going to rebuild the drive, why would I run xfs_repair at all instead of just reformatting it? These sata add-on cars have been a huge pain for years now. They do drop disks a lot when there's heavy read/write activity on them. Last time I looked at the list of "recommended" controllers, there weren't good options given my setup and requirements. That was quite a while ago now though, so I'll have to look again and see what's changed.
  10. I'm getting the error "Unmountable: No file system" for one of my drives. Syslog says Nov 3 18:32:34 Filebox emhttpd: shcmd (86): mkdir -p /mnt/disk9 Nov 3 18:32:34 Filebox emhttpd: shcmd (87): mount -t xfs -o noatime,nodiratime /dev/md9 /mnt/disk9 Nov 3 18:32:34 Filebox kernel: XFS (md9): Mounting V5 Filesystem Nov 3 18:32:34 Filebox kernel: XFS (md9): Corruption warning: Metadata has LSN (1:63423) ahead of current LSN (1:63186). Please unmount and run xfs_repair (>= v4.3) to resolve. Nov 3 18:32:34 Filebox kernel: XFS (md9): log mount/recovery failed: error -22 Nov 3 18:32:34 Filebox kernel: XFS (md9): log mount failed Nov 3 18:32:34 Filebox root: mount: /mnt/disk9: wrong fs type, bad option, bad superblock on /dev/md9, missing codepage or helper program, or other error. Nov 3 18:32:34 Filebox emhttpd: shcmd (87): exit status: 32 Nov 3 18:32:34 Filebox emhttpd: /mnt/disk9 mount error: No file system Nov 3 18:32:34 Filebox emhttpd: shcmd (88): umount /mnt/disk9 Nov 3 18:32:34 Filebox root: umount: /mnt/disk9: not mounted. Nov 3 18:32:34 Filebox emhttpd: shcmd (88): exit status: 32 Nov 3 18:32:34 Filebox emhttpd: shcmd (89): rmdir /mnt/disk9 Line 4 in paste above says to run xfs_repair. Should I, or is there something else I should be trying first? Diagnostics file attached. Thanks filebox-diagnostics-20181103-1844.zip
  11. I've tried it on two different machines, different OSes, with different files. Neither is hitting it's head on the RAM or processor, and I've tried disabling compression. The data being backed up is nearly incompressible anyway. Both were nearly maxing out my upload connection before the migration, now they're both under 2Mbps. The only two constants between the two machines are CrashPlan and my ISP. The only thing I can think of that I haven't tried is using a vpn to eliminate ISP throttling as an issue. **Just tried through a VPN. It didn't improve upload speed at all. I don't know that CrashPlan is throttling. It's possible the server my clients connect to is saturated, or there's something else I'm just missing. I'm just running out of explanations outside of something on CrashPlan's end.
  12. I will, but frankly I've had better luck with the community then I've had with Code42 so I decided to start here. Anyways, thanks for the great container and the help. If they give me anything of use I'll post it here in case it's helpful to anyone else.
  13. I just tested the windows client on a different machine and it's uploading at a similarly slow speed, so it's unlikely it's a client issue. I've also tested uploading to google drive and it's uploading at full speed so it's not an issue with my internet connection. I can only assuming they're throttling. Which really sucks.
  14. I have double checked my config file and it does still have dedupe disabled. It is uploading at the speed I would expect it to if dedupe were enabled. But with the config file being correct, I don't know where to go from here. <compression>OFF</compression> <dataDeDupAutoMaxFileSize>1</dataDeDupAutoMaxFileSize> <dataDeDupAutoMaxFileSizeForWan>1</dataDeDupAutoMaxFileSizeForWan> <dataDeDuplication>MINIMAL</dataDeDuplication> I went and looked at some old logs I 10/01/17 12:16AM [XXXXXX Backup] Stopped backup to CrashPlan Central in 21.2 hours: 116 files (44.40GB) backed up, 44GB encrypted and sent @ 6.8Mbps and compared to the new logs I 11/21/17 07:43AM [XXXXXX Backup] Stopped backup to CrashPlan Central in 4.7 hours: 25 files (4.70GB) backed up, 4.60GB encrypted and sent @ 1.6Mbps (Effective rate: 1.9Mbps) So i don't know if they're throttling now, or if something is screwed up with my client despite what the config file is saying. I'm tempted just delete the container, reinstall, and instead of attempting to transfer all the settings from the gfjardim's container. just adopt the backup. I'm concerned that with dedup being disabled, I'll end up having to reupload everything.
  15. I've gotten much lower speeds since migrating to small business from home. I doubt it's the container because I've been getting terrible speeds since the migration on both gfjardim's container and this one. It rarely goes about 2Mbps. Before the small business migration I'd get 4.5-5.5Mbps. I don't know if they're throttling me since the migration or if small business is inherently slower, but it's a real problem.
  16. Altering the allocated cores has not fixed the problem. It recurred today. Does anyone have other suggestions?
  17. unRAID had cores 0-3 and the vm had 4-7. I've now changed it to unRAID 0-5 and vm 6-7.
  18. I'll try it, though that seems unlikely to me. I've run unRAID on far less than 4 threads from a Core i7-4790 without issue.
  19. I've been struggling with this issue for a while and have finally figured out (at least broadly) what is causing the problem. About once every 24 hrs, unRAID interfaces (both web and ssh) become unresponsive and the SMB share can't be accessed, but my Win8.1 VM keeps running and I can access it through RDP w/o issue. There's been no errors in the syslog. I haven't been able to find a hardware problem. I started suspecting the VM. So I left the VM off for a few days and the problems disappeared. I then tried to narrow it down further by starting the VM but limiting the programs that ran. Best as I can tell, the problem only happens when the VM access the unRAID SMB share. If I disable any programs that would access the SMB share, and only run ones that access the "local" drive (running on the cache drive), the problems go away. After running the VM with no SMB share access for 8 days, the server has been rock solid. So what is it about the VM accessing the unRAID SMB share that causes the problem? When the VM access the share, the server doesn't immediately freeze up. It generally lasts less than 24 hours though, and never much more than that. I'm really out of ideas and the next step is to just give up using KVM on unRAID and just setup a separate box running Hyper-V. I'd hate to do that though because I do like running a single box and the beefier hardware I used for the unRAID pretty much goes to waste if it's not running any VMs.
  20. I've still been unable to solve this issue. I'm having to hard reboot it every 24-48 hours. I've moved the one virtual hard disk file from my VM off of the data array and onto the cache drive. That didn't change anything. I ran extended SMART tests on all of my drives and they all came back without errors. Does anyone have any ideas what else I could try? At this point I don't know what else to check.
  21. Hey BRiT (or anyone else), any thoughts on the diagnostics or anything I should try or look at? Thanks
  22. I've attached the diagnostics. filebox-diagnostics-20150912-1327.zip
  23. Over the past couple of weeks, my unraid machine has become unresponsive every 2 to 3 days. It starts by being unable to access the unraid shares. Then shortly after that, the unraid web interface and SSH sessions becomes unresponsive. The odd thing is that the VM running on the cache discs still functions when this happens. When the web interface and SSH are unresponsive, the only way to restart is a hard shutdown. If I get to the web interface before it becomes unresponsive, I can shut down the VM properly. However, trying to stop the array causes it to hang when it says "Sync filesystems". I then have to do a hard shutdown. In the couple of times when I caught it after the shares became inaccessible but before the web interface does, I was able to download a syslog. I've attached them to this post. When I don't get there in time and the web interface is unresponsive, I am unable to get a syslog file because it's cleared on reboot. If anyone knows how to preserve the syslog when this happens, please let me know. filebox-syslog-20150908-1918.zip filebox-syslog-20150910-1944.zip
  24. NOTE: I had to move some drives/cables around so what was previously sdb is now sdn, and what was previously sdk is now sdm. sdn is the existing SSD with the data on it. sdm is the new SSD that I'm trying to add to the cache pool. Decided to just delete the partition and let unraid do what it needed to to add it to the pool. So I stopped the array. Deleted the partition on the new SSD (sdm). The main page of the GUI listed the new SSD (sdm) as a new drive in the Cache 2 slot. I started the array Cache 2 is green. Check the syslog and find it's still not balancing. You can see below in the pasted portion of the syslog, "error during balancing '/mnt/cache' - Invalid argument" and "BTRFS error (device sdn1): unable to start balance with target data profile 16". Jul 9 17:21:10 Filebox emhttp: shcmd (164): mkdir -p /mnt/cache Jul 9 17:21:10 Filebox emhttp: shcmd (165): set -o pipefail ; mount -t btrfs -o noatime,nodiratime -U b2d98d37-4bb3-4e49-9b4e-95e14e7322a8 /mnt/cache |& logger Jul 9 17:21:10 Filebox kernel: BTRFS info (device sdn1): disk space caching is enabled Jul 9 17:21:10 Filebox kernel: BTRFS: has skinny extents Jul 9 17:21:10 Filebox kernel: BTRFS: detected SSD devices, enabling SSD mode Jul 9 17:21:10 Filebox emhttp: writing MBR on disk (sdm) with partition 1 offset 64, erased: 0 Jul 9 17:21:11 Filebox emhttp: re-reading (sdm) partition table Jul 9 17:21:11 Filebox kernel: ata17.00: Enabling discard_zeroes_data Jul 9 17:21:11 Filebox emhttp: shcmd (166): udevadm settle Jul 9 17:21:11 Filebox kernel: sdm: sdm1 Jul 9 17:21:11 Filebox emhttp: shcmd (167): set -o pipefail ; /sbin/btrfs device add -f -K /dev/sdm1 /mnt/cache |& logger Jul 9 17:21:12 Filebox logger: /dev/sdm1 is mounted Jul 9 17:21:12 Filebox emhttp: shcmd: shcmd (167): exit status: 1 Jul 9 17:21:12 Filebox emhttp: shcmd (168): set -o pipefail ; /sbin/btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/cache |& logger & Jul 9 17:21:12 Filebox emhttp: shcmd (169): btrfs filesystem resize max /mnt/cache |& logger Jul 9 17:21:12 Filebox logger: ERROR: error during balancing '/mnt/cache' - Invalid argument Jul 9 17:21:12 Filebox logger: There may be more info in syslog - try dmesg | tail Jul 9 17:21:12 Filebox kernel: BTRFS error (device sdn1): unable to start balance with target data profile 16 Jul 9 17:21:12 Filebox logger: Resize '/mnt/cache' of 'max' Jul 9 17:21:12 Filebox emhttp: shcmd (170): sync Jul 9 17:21:12 Filebox kernel: BTRFS: new size for /dev/sdn1 is 512110157824 Is it possible that the problem is that the original cache drive is 512GB and I'm trying to add a 500GB drive? Does anyone have any other suggestions? I appreciate the help! Full syslog attached. filebox-syslog-20150709-1721.zip
  25. Thanks jonathanm! I'll give that a try later today after work.