je82
-
Posts
468 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by je82
-
-
Hi,
I am concerned about the security, since we cannot encrypt the usb how safe is the passwords we store for users we've created in the unraid gui?
I check
cat /boot/config/passwd and it seems to contain cleartext usernames which is fine i guess, but the passwords must be stored somewhere too, are these safe or can they be decrypted by a potential attacker that gains access to the usb drive?
-
There's been some discussion regarding what command to use, either powerdown or poweroff. I feel like poweroff is more efficient at actually successfully shutting down the system, even though it might result in a parity check once you power back on, powerdown seems to stall very often and wait for something.
Is there any clever person out there that has made a combination of powerdown and power so it issues powerdown but if it stalls for 5+ minutes, then issue poweroff and just cut it there?
Being at remote location and working with unraid having it stall randomly during shutdown is brutal, so i wish there was a solid way to 100% shut it down everytime even if something like mover is still running.
-
One of the biggest downsides to unraid for me is the fact that if there were to be any parity sync errors its very difficult to know what files may have been affected by the error. I don't know if there is a simple solution to this, i guess you could use the hash plugin to create a unique hash for every file and then have it compare the hash on all files and if it has changed then there's the problem.... but this requires a massive amount of cpu power and time if you have many files/big array.
I'm not by any means smart, my hopes is that the brilliant people behind unraid can build a feature that can detect what files have gone bad from corruption in a better more efficient way?
-
Im trying to figure out if i am experiencing a privoxy issue or if its a email client issue.
So i am running a business, and previously i've always used a browser based webmail, which worked fine but i wanted an actual imap client to work with and i found one (the bat) that is nice for my needs. The only issue is when you send email from an email client the actual ip address of your source connection sending the email is embedded by design, i don't want this obviously. its 2023 and exposing your public ip to strangers is a bad idea in general especially for me when i have a static ip, so the solution was to put up a privoxy proxy and use a vpn to send the emails through.
The problem:
I have setup a privoxy using this containers and everything seems to work fine, i can test the socks5 proxy with a browser and see that if i use it for my traffic the vpn ip comes up. It never lags or slows down when using a browser, but when i use it with my imap mail client the handshakes to the server can take up to 2 minutes of time, and it times out often, and just works really really bad. I have no idea why this would be, whenever i use the bat without proxy it works fine.
My question:
Do any of you know any setting that could cause email imap to be really slow with privoxy default settings? I've asked chat gpt but no great ideas there, i tested changing the keep alive to 0 etc but none of it seems to change anything, running the email via the proxy is incredible slow and nearly unusable.
All ideas welcome.
-
37 minutes ago, dlandon said:
No. There are some extra files on the UD disk. This could be recyce bin files if the Recyce Bin plugin is installed and you deleted some files with Windows.
Click on the mount point and browse the files on the UD disk and see if there are unexpected folders.
You should also update Unraid to the latest stable.
Ive checked the root of /mnt/disks/Appdata_backup both by using the direct link in the gui and via cli and there are no additional files or folders anywhere from this particular mount point, indeed very strange.
I cannot run bleeding edge i use my unraid for work and stability is key to my use case, i prefer to be behind a few versions for this reason
I guess ill figure it out eventually, i have a lot of additional space for now anyway, but it ponders my mind how it can be
EDIT: Found the problem, apparently the docker container is only 13gb on the disk using it, but on the copy its 30gb, not sure why this is but that is whats causing the difference, i'll figure it out. Cheers!
-
Hi,
I am using Unassigned Devices to mount a secondary nvme drive and clone the data from the main nvme drive to this one but i have a question regarding the displayed used data as it does not seem to match.
1. I have first nvme mounted to the array in pool /mnt/nvme_appdata
2. I have used Unassigned Devices to mount the secondary nvme at /mnt/disks/Appdata_backup
3. I use rsync to clone the data from /mnt/nvme_appdata to /mnt/disks/Appdata_backup | rsync -avu --no-i-r --delete --stats --exclude=.Recyc* /mnt/nvme_appdata/Appdata/ /mnt/disks/Appdata_backup/Appdata/Appdata/
The problem is, the displayed used space it doesn't match! according to unraid there is an additional +20gb of data on the Unassigned Devices nvme device? As you can see the main device that is being backed up only has 164gb , yet the device backing up to has 184gb? Both devices is formated with the same type of filesystem. Rsync command runs and it completes without fail, i can see in the log from rsync that it is deleting files that are not on the main /mnt/nvme_appdata.
Is this some kind of weird display bug with Unassigned Devices plugin?
Actually using df -h it reports the same:
/dev/mapper/nvme0n1p1 745G 153G 593G 21% /mnt/nvme_appdata
/dev/mapper/Appdata_backup 745G 172G 574G 24% /mnt/disks/Appdata_backup
So probably not a unassigned devices issue, very strange, never seen anything like it, there are over 7 million objects being synced though, could there be metadata differences that causes a whooping +20gb of data? it seems crazy to me.
-
I have the strangest bug with this plugin i just noticed, i am not sure when it started but for whatever reason the plugin feels like one of my drives is "not present" yet it is detected in unraid and also detected in the disk location plugin itself so i can allocate it to a slot... Any ideas how to fix it? Unraid 6.10.3
EDIT: Force scan just fixed it
-
Everytime i try to vnc to a VM using the shortcut thats inside unraid you click the vm and get a drop down menu you click "VNC Remote" i have to restart my browser for it to work, the error message in the log is always:
QuoteDec 16 17:52:15 NAS nginx: 2023/12/16 17:52:15 [error] 5006#5006: *11029 recv() failed (104: Connection reset by peer) while reading upstream, client: 192.x.x.x, server: , request: "GET //wsproxy/5700/ HTTP/1.1", upstream: "http://127.0.0.1:5700/", host: "nas.mylocalnetwork.local"
Using firefox, is this a firefox issue or something else? Its not a massive deal because i only have to access once via vnc to enter encryption key for vm to start, but still annoying to have to exit the entire browser, and start a fresh session.
It never fails if i restart the session, works every time. On Unraid Version: 6.10.3
-
think a simple google search answered my question:
ill be using the parity check tuning by @itimpi until i upgrade my unraid to a more modern version
-
Hi,
I am having a hard time understanding the Parity Check scheduler settings in unraid 6.10.3, see screenshot below for my current configuration:
What i expect from this configuration is:
Every first wednesday of April, August, December, a parity check is starting to run at 07:00 in the morning. After it has ran for 7 hours, it will then pause, and then resume at 07:00 on thursday, same for friday etc, until completed.
This is not what happens. Unraid starts parity check on the correct time/day/month, but it never stops after 7 hours has accumulated, it runs until it has completed in one big swoop.
Is this a bug in unraid 6.10.3 or is there any misunderstanding on my part on the settings?
-
just reporting back, bios update and re-seating of the pci cards didn't change a thing, but it appears the fix jorgeb recommended solved it
-
8 minutes ago, JorgeB said:
Will do if what i did didn't fix it, saw someone else said to update bios if on a x399 motherboard, so i did, also reseated the pci cards, booted the system and the error messages are gone but unsure if they were always present on booting the system or if they are random.
Anyhow will try your solution next if they appear again, thanks
-
Hi,
Ive seen this in the log today from one of my NAS servers, can anyone help me understand what the problem is and maybe how to fix it?
QuoteNov 9 09:06:03 WORKNAS2 kernel: pcieport 0000:00:01.1: AER: Corrected error received: 0000:00:00.0
Nov 9 09:06:03 WORKNAS2 kernel: pcieport 0000:00:01.1: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
Nov 9 09:06:03 WORKNAS2 kernel: pcieport 0000:00:01.1: device [1022:1453] error status/mask=00000040/00006000
Nov 9 09:06:03 WORKNAS2 kernel: pcieport 0000:00:01.1: [ 6] BadTLPThanks.
-
On 10/27/2021 at 8:26 PM, kizer said:
This is what I always do and I've not had any issues for a while.
1. Stop dockers
2. Stop array
3. Shut down machine
Yeah i did the mistake of shutting down the array while dockers were still being auto started, i though unraid had some kind of programmed fix where it always shutdowns all the dockers when shutting down the array but it appears the logic is broken there if the docker auto runs are still in progress, ended up not being able to unmount the share where the appdata for the dockers resided.
-
bleh, shutting down the array while docker auto start is still running is a bad idea? i though it would handle it but now stuck in "Nov 5 14:41:18 NAS emhttpd: shcmd (603): umount /mnt/cache_appdata" loop, and via cli cannot force unmount it either, why is it always impossible to force unmount stuff in unraid?
lsof /mnt/cache_appdata returns nothing,
umount -f /mnt/cache_appdata
umount: /mnt/cache_appdata: target is busy.never been able to unmount something when unraid thinks its in use, even the force commands are denied. maybe its unrelated to shutting down the array while docker auto starts are still running?
-
Memtest passed 2 passes up to test 5, isn't 100% confirmed to not be a memory
Found this in the bios change log,, bios is 2 years old: "1.4b (01/09/2023)
1. Updated 5.22_WhitleyCrb_0ACMS_ICX_74 (Intel BKC WW46 IPU2023.1).
2. Updated SEL for processor error.
3. Fixed the memory error that is not reported in SMBIOS event log.
4. Enabled all boot options first for test case 220, 271, 356 and 457.
5. Resolved abnormal SOL resolution"Updating to the latest just in case.
Do any of you know any way to test memory while running the server? I cant really take it offline 2 days for a complete 4 pass of memtest. Or if you think the culprit could be something else im all ears, thanks
-
Good to mention i did had a XFS Corruption issue pop up out of nowhere a few weeks ago,
QuoteOct 20 09:37:11 NAS kernel: XFS (dm-3): Corruption detected. Unmount and run xfs_repair
This time i ran all the xfs checks i could on the device affected, and it returned zero errors.
Now here we are again, the docker container went into a locked state
QuoteNov 5 11:11:38 NAS kernel: BTRFS critical (device loop2): corrupt leaf: root=2 block=4600659968 slot=57, bad key order, prev (9313379941377294336 136 65535) current (4681564160 169 0)
Device md8 is still in use. and md: 1 devices still in use.
the array could not be dismounted, i had to shut down via powerbutton.
My idea is, either RAM, bad cable/backplane or could it be something else? the server has been stable for a year or so and now suddenly within a short span of time getting issues.
-
If someone knows how to identify which drive is MD8 it would be helpful, tried a bunch of ways but i cant really figure out which drive it co-relates to, my guess MD8 = disk8?
-
Quote
root@NAS:/mnt# sudo /usr/sbin/cryptsetup luksClose md8
Device md8 is still in use.sudo dmsetup remove /dev/mapper/md8
device-mapper: remove ioctl on md8 failed: Device or resource busyCant remove it no matter what i do, i guess graceful is not going to happen this time, im gonna shut down the server and run memtest, something is definitely wrong with the hardware, your suggestions are welcome
-
trying to shutdown the system gracefully now, capturing these logs:
QuoteNov 5 12:12:01 NAS kernel: CPU: 13 PID: 2589 Comm: umount Tainted: P W O 5.15.46-Unraid #1
Nov 5 12:12:01 NAS kernel: Hardware name: Supermicro Super Server/X12SPI-TF, BIOS 1.4 07/11/2022
Nov 5 12:12:01 NAS kernel: RIP: 0010:d_walk+0x8a/0x206
Nov 5 12:12:01 NAS kernel: Code: 45 31 ff 44 89 e0 49 89 ed 83 e0 01 89 44 24 14 49 8b 95 a0 00 00 00 4c 89 eb 48 8d 83 a0 00 00 00 48 39 c2 0f 84 8d 00 00 00 <f6> 82 73 ff ff ff 20 4c 8d aa 70 ff ff ff 4c 8b 32 75 72 4c 8d 42
Nov 5 12:12:01 NAS kernel: RSP: 0018:ffffc9000b3b3db0 EFLAGS: 00010207
Nov 5 12:12:01 NAS kernel: RAX: ffff8881c481ba10 RBX: ffff8881c481b970 RCX: 0000000000000007
Nov 5 12:12:01 NAS kernel: RDX: 0000000000000000 RSI: ffffc9000b3b3e28 RDI: ffff8893d0470418
Nov 5 12:12:01 NAS kernel: RBP: ffff88814cab8780 R08: ffff8881c481b9c8 R09: ffffc9000b3b3e68
Nov 5 12:12:01 NAS kernel: R10: ffffffff822d19f0 R11: 000000000000003c R12: 0000000002c6f9b6
Nov 5 12:12:01 NAS kernel: R13: ffff8881c481b970 R14: ffff8893d0470458 R15: 0000000000000000
Nov 5 12:12:01 NAS kernel: FS: 0000147c4d9e4740(0000) GS:ffff889fffd40000(0000) knlGS:0000000000000000
Nov 5 12:12:01 NAS kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 5 12:12:01 NAS kernel: CR2: ffffffffffffff73 CR3: 00000017f1648006 CR4: 0000000000770ee0
Nov 5 12:12:01 NAS kernel: PKRU: 55555554
Nov 5 12:12:01 NAS kernel: Call Trace:
Nov 5 12:12:01 NAS kernel: <TASK>
Nov 5 12:12:01 NAS kernel: ? select_collect2+0x7c/0x7c
Nov 5 12:12:01 NAS kernel: shrink_dcache_parent+0x4c/0x11e
Nov 5 12:12:01 NAS kernel: do_one_tree+0xe/0x31
Nov 5 12:12:01 NAS kernel: shrink_dcache_for_umount+0x36/0x6a
Nov 5 12:12:01 NAS kernel: generic_shutdown_super+0x1a/0x104
Nov 5 12:12:01 NAS kernel: kill_block_super+0x21/0x40
Nov 5 12:12:01 NAS kernel: deactivate_locked_super+0x33/0x6d
Nov 5 12:12:01 NAS kernel: cleanup_mnt+0x67/0xda
Nov 5 12:12:01 NAS kernel: task_work_run+0x6f/0x83
Nov 5 12:12:01 NAS kernel: exit_to_user_mode_prepare+0x9a/0x131
Nov 5 12:12:01 NAS kernel: syscall_exit_to_user_mode+0x18/0x23
Nov 5 12:12:01 NAS kernel: do_syscall_64+0x9f/0xa5
Nov 5 12:12:01 NAS kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae
Nov 5 12:12:01 NAS kernel: RIP: 0033:0x147c4db154e7
Nov 5 12:12:01 NAS kernel: Code: 89 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 51 89 0c 00 f7 d8 64 89 02 b8
Nov 5 12:12:01 NAS kernel: RSP: 002b:00007ffc46f5abc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
Nov 5 12:12:01 NAS kernel: RAX: 0000000000000000 RBX: 0000147c4dca1f64 RCX: 0000147c4db154e7
Nov 5 12:12:01 NAS kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000040a5b0
Nov 5 12:12:01 NAS kernel: RBP: 000000000040a380 R08: 0000000000000000 R09: 00000000ffffffff
Nov 5 12:12:01 NAS kernel: R10: 0000147c4da18ec8 R11: 0000000000000246 R12: 0000000000000000
Nov 5 12:12:01 NAS kernel: R13: 000000000040a5b0 R14: 000000000040a490 R15: 0000000000000000
Nov 5 12:12:01 NAS kernel: </TASK>
Nov 5 12:12:01 NAS kernel: Modules linked in: nvidia_modeset(PO) nvidia_uvm(PO) xt_mark xt_CHECKSUM ipt_REJECT nf_reject_ipv4 xt_nat xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs dm_crypt dm_mod dax cmac cifs asn1_decoder cifs_arc4 cifs_md4 oid_registry md_mod nvidia(PO) ipmi_devintf wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha ip6table_filter ip6_tables iptable_filter ip_tables x_tables ast drm_vram_helper i2c_algo_bit drm_ttm_helper ttm drm_kms_helper i10nm_edac x86_pkg_temp_thermal intel_powerclamp coretemp ipmi_ssif crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel drm mpt3sas aesni_intel crypto_simd cryptd rapl backlight intel_cstate i2c_i801 nvme agpgart i2c_smbus syscopyarea input_leds sysfillrect raid_class ahci sysimgblt ixgbe
Nov 5 12:12:01 NAS kernel: nvme_core scsi_transport_sas i2c_core fb_sys_fops led_class intel_uncore libahci mdio intel_pch_thermal acpi_ipmi ipmi_si acpi_power_meter acpi_pad button [last unloaded: tun]
Nov 5 12:12:01 NAS kernel: CR2: ffffffffffffff73
Nov 5 12:12:01 NAS kernel: ---[ end trace 478da811436c28f1 ]---
Nov 5 12:12:01 NAS kernel: RIP: 0010:d_walk+0x8a/0x206
Nov 5 12:12:01 NAS kernel: Code: 45 31 ff 44 89 e0 49 89 ed 83 e0 01 89 44 24 14 49 8b 95 a0 00 00 00 4c 89 eb 48 8d 83 a0 00 00 00 48 39 c2 0f 84 8d 00 00 00 <f6> 82 73 ff ff ff 20 4c 8d aa 70 ff ff ff 4c 8b 32 75 72 4c 8d 42
Nov 5 12:12:01 NAS kernel: RSP: 0018:ffffc9000b3b3db0 EFLAGS: 00010207
Nov 5 12:12:01 NAS kernel: RAX: ffff8881c481ba10 RBX: ffff8881c481b970 RCX: 0000000000000007
Nov 5 12:12:01 NAS kernel: RDX: 0000000000000000 RSI: ffffc9000b3b3e28 RDI: ffff8893d0470418
Nov 5 12:12:01 NAS kernel: RBP: ffff88814cab8780 R08: ffff8881c481b9c8 R09: ffffc9000b3b3e68
Nov 5 12:12:01 NAS kernel: R10: ffffffff822d19f0 R11: 000000000000003c R12: 0000000002c6f9b6
Nov 5 12:12:01 NAS kernel: R13: ffff8881c481b970 R14: ffff8893d0470458 R15: 0000000000000000
Nov 5 12:12:01 NAS kernel: FS: 0000147c4d9e4740(0000) GS:ffff889fffd40000(0000) knlGS:0000000000000000
Nov 5 12:12:01 NAS kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 5 12:12:01 NAS kernel: CR2: ffffffffffffff73 CR3: 00000017f1648006 CR4: 0000000000770ee0
Nov 5 12:12:01 NAS kernel: PKRU: 55555554
Nov 5 12:12:01 NAS emhttpd: shcmd (2689340): exit status: 137
Nov 5 12:12:01 NAS emhttpd: shcmd (2689341): rmdir /mnt/disk8
Nov 5 12:12:01 NAS emhttpd: shcmd (2689342): umount /mnt/disk9
Nov 5 12:12:01 NAS kernel: XFS (dm-8): Unmounting Filesystem
Nov 5 12:12:01 NAS emhttpd: shcmd (2689343): rmdir /mnt/disk9
Nov 5 12:12:01 NAS emhttpd: shcmd (2689344): umount /mnt/cache_appdata
Nov 5 12:12:02 NAS kernel: XFS (dm-9): Unmounting Filesystem
Nov 5 12:12:03 NAS emhttpd: shcmd (2689345): rmdir /mnt/cache_appdata
Nov 5 12:12:03 NAS emhttpd: shcmd (2689346): umount /mnt/cache_incoming
Nov 5 12:12:03 NAS kernel: XFS (dm-10): Unmounting Filesystem
Nov 5 12:12:03 NAS emhttpd: shcmd (2689347): rmdir /mnt/cache_incoming
Nov 5 12:12:03 NAS emhttpd: shcmd (2689348): /usr/sbin/cryptsetup luksClose md1
Nov 5 12:12:03 NAS emhttpd: shcmd (2689349): /usr/sbin/cryptsetup luksClose md2
Nov 5 12:12:03 NAS emhttpd: shcmd (2689350): /usr/sbin/cryptsetup luksClose md3
Nov 5 12:12:03 NAS emhttpd: shcmd (2689351): /usr/sbin/cryptsetup luksClose md4
Nov 5 12:12:03 NAS emhttpd: shcmd (2689352): /usr/sbin/cryptsetup luksClose md5
Nov 5 12:12:03 NAS emhttpd: shcmd (2689353): /usr/sbin/cryptsetup luksClose md6
Nov 5 12:12:03 NAS emhttpd: shcmd (2689354): /usr/sbin/cryptsetup luksClose md7
Nov 5 12:12:03 NAS emhttpd: shcmd (2689355): /usr/sbin/cryptsetup luksClose md8
Nov 5 12:12:03 NAS root: Device md8 is still in use.
Nov 5 12:12:03 NAS emhttpd: shcmd (2689355): exit status: 5
Nov 5 12:12:03 NAS emhttpd: shcmd (2689356): /usr/sbin/cryptsetup luksClose md9
Nov 5 12:12:03 NAS emhttpd: shcmd (2689357): /usr/sbin/cryptsetup luksClose sdb1
Nov 5 12:12:03 NAS emhttpd: shcmd (2689358): /usr/sbin/cryptsetup luksClose sdc1
Nov 5 12:12:03 NAS kernel: mdcmd (65): stop
Nov 5 12:12:03 NAS kernel: md: 1 devices still in use.
Nov 5 12:12:03 NAS emhttpd: error: mdcmd, 3289: Device or resource busy (16): write
Nov 5 12:12:03 NAS emhttpd: shcmd (2689359): rm -f /boot/config/forcesync
Nov 5 12:12:03 NAS emhttpd: shcmd (2689360): sync -
It seems my previous unraid installation that has been stable for years is starting to show misc errors, now all the dockers dropped, what is your suggested approach here? The system is an expensive one running ECC ram and passed memtest 10 passes when built.
Maybe its the ssd that is failing? I tried to look at the scrub stats of the docker container and it found no issues? "
"UUID: 7430bd32-eee4-4538-9616-eb39918be503 Scrub started: Sun Nov 5 12:03:46 2023 Status: aborted Duration: 0:00:00 Total to scrub: 13.33GiB Rate: 0.00B/s Error summary: no errors found"
Attached diags in case you experts can find what could be causing it, appreciate any help.
(Removed diags for privacy reasons)
-
i ran the filecheck again with just -v flag
QuotePhase 1 - find and verify superblock... - block cache size set to 6071808 entries Phase 2 - using internal log - zero log... zero_log: head block 2864861 tail block 2864861 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and 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 = 0 - agno = 3 - agno = 10 - agno = 1 - agno = 2 - agno = 6 - agno = 5 - agno = 7 - agno = 9 - agno = 8 - agno = 4 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Fri Oct 20 21:39:52 2023 Phase Start End Duration Phase 1: 10/20 21:35:12 10/20 21:35:12 Phase 2: 10/20 21:35:12 10/20 21:35:15 3 seconds Phase 3: 10/20 21:35:15 10/20 21:38:07 2 minutes, 52 seconds Phase 4: 10/20 21:38:07 10/20 21:38:07 Phase 5: 10/20 21:38:07 10/20 21:38:14 7 seconds Phase 6: 10/20 21:38:14 10/20 21:39:51 1 minute, 37 seconds Phase 7: 10/20 21:39:51 10/20 21:39:51 Total run time: 4 minutes, 39 seconds done
i cannot see that it fixes anything, should i just relax and monitor ? can it perhaps be a ram issue? but then why did it spew errors only directed at DM-3 ? Also as far as i can tell i had no real read/write operations going on when it started, the server was pretty much in a relaxed state.
Your feedback is appreciated
-
5 minutes ago, itimpi said:
You need to run without -n or nothing will be fixed.
uhm okay, but shouldnt the scan see the problems? and alert me that there are problems that needs fixing? or did i miss something here, it looked like the scan returned no errors?
-
Here are the results:
QuotePhase 1 - find and verify superblock... - block cache size set to 6071808 entries Phase 2 - using internal log - zero log... zero_log: head block 2864850 tail block 2864850 - scan filesystem freespace and inode maps... - 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 = 0 - agno = 1 - agno = 5 - agno = 8 - agno = 3 - agno = 6 - agno = 7 - agno = 2 - agno = 9 - agno = 10 - agno = 4 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Fri Oct 20 20:18:17 2023 Phase Start End Duration Phase 1: 10/20 20:13:45 10/20 20:13:45 Phase 2: 10/20 20:13:45 10/20 20:13:49 4 seconds Phase 3: 10/20 20:13:49 10/20 20:16:40 2 minutes, 51 seconds Phase 4: 10/20 20:16:40 10/20 20:16:41 1 second Phase 5: Skipped Phase 6: 10/20 20:16:41 10/20 20:18:17 1 minute, 36 seconds Phase 7: 10/20 20:18:17 10/20 20:18:17 Total run time: 4 minutes, 32 seconds
any expert advice? should i replace the drive or should i let it go for now and monitor the situation?
Security of the user/passwords stored on USB?
in Security
Posted
I think what im asking here how safe are the passwords stored in smbpasswd file, can they be decrypted?