B_ISC

If I create an share "PRIVATE" using the unraid share interface, what samba settings are set for the share by default that are not specified (ie..export/public/private/) in the interface? I would guess that it's something along the lines below? Or are there other automatic/override settings? Are there ways to create automatically added settings to any share created by the unraid share interface? Perhaps overrides/defaults in the "Samba extra configuration" file? [PRIVATE] path = "/mnt/user/PRIVATE" write list = privateuser valid users = privateuser guest ok = no hide unreadable = yes

A 5TB drive went "unmountable unsupported or no file system" while still being a greenball. I stopped the array, marked the slot as not installed. I started the array, then stopped the array. I installed an online, pre-cleared 12tb. I enabled the array, but didn't notice that the system was still complaining the 12tb was not formatted. Thinking that the new drive will be completely rebuilt anyhow, I wasn't worried. The array started, it rebuilt to the new drive without issue. The new drive showed only 87gb used on the new 12tb. Luckily, nothing was wrong with the 5TB, I was able to load it on another system and view what was on it. I verified that what was on that drive is no longer available on the network (not being emulated). Hence, UNRAID tried to loose me 5TB of data without any error! What went wrong!? I followed the drive replacement steps in the unraid manual.

I understand the user/password requirement, have you seen anything that would automatically log the console in?

You misunderstood, automatic logon for the local server console, not remotely/web interface.

I use a large/random password for root that I don't want to type in the local server console. Is there a way to for the local server console to be automatically logged in? (I'm not worried about local physical security.)

Migrated very cleanly to 6.12.11 and tracking down an intermittent hard crash that happens probably once a week with a 24x7 server. Previous version never crashed. Network syslog collector showing an SMB crash that happens constantly (once or twice an hour)...is this just the version of samba that will be handled in a future update? I haven't had a full server crash since I setup my network syslog collector, and I don't think that SMB is causing my full server crash, but I figured I would clean up the logs. 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.741594, 0] ../../source3/smbd/fd_handle.c:39(fd_handle_destructor) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: PANIC: assert failed at ../../source3/smbd/fd_handle.c(39): (fh->fd == -1) || (fh->fd == AT_FDCWD) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.741689, 0] ../../lib/util/fault.c:173(smb_panic_log) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: =============================================================== 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.741718, 0] ../../lib/util/fault.c:174(smb_panic_log) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: INTERNAL ERROR: assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in pid 26421 (4.17.12) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.741740, 0] ../../lib/util/fault.c:178(smb_panic_log) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.741762, 0] ../../lib/util/fault.c:183(smb_panic_log) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: =============================================================== 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.741780, 0] ../../lib/util/fault.c:184(smb_panic_log) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: PANIC (pid 26421): assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in 4.17.12 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.742602, 0] ../../lib/util/fault.c:292(log_stack_trace) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: BACKTRACE: 27 stack frames: 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #0 /usr/lib64/libgenrand-samba4.so(log_stack_trace+0x2e) [0x149a9f65564e] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #1 /usr/lib64/libgenrand-samba4.so(smb_panic+0x9) [0x149a9f6558a9] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #2 /usr/lib64/libsmbd-base-samba4.so(+0x4d0fb) [0x149a9fa370fb] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #3 /usr/lib64/libtalloc.so.2(+0x44df) [0x149a9f6044df] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #4 /usr/lib64/libsmbd-base-samba4.so(file_free+0xd6) [0x149a9fa44266] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #5 /usr/lib64/libsmbd-base-samba4.so(+0xc0781) [0x149a9faaa781] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #6 /usr/lib64/libsmbd-base-samba4.so(smbd_smb2_request_process_close+0x211) [0x149a9faaaf01] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #7 /usr/lib64/libsmbd-base-samba4.so(smbd_smb2_request_dispatch+0xdfa) [0x149a9fa9ebfa] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #8 /usr/lib64/libsmbd-base-samba4.so(+0xb5bc1) [0x149a9fa9fbc1] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #9 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x149a9f6178c1] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #10 /usr/lib64/libtevent.so.0(+0xee07) [0x149a9f61de07] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #11 /usr/lib64/libtevent.so.0(+0xcef7) [0x149a9f61bef7] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #12 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x149a9f616ba1] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #13 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x149a9f616e7b] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #14 /usr/lib64/libtevent.so.0(+0xce97) [0x149a9f61be97] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #15 /usr/lib64/libsmbd-base-samba4.so(smbd_process+0x817) [0x149a9fa8dbe7] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #16 /usr/sbin/smbd(+0xb090) [0x558a01525090] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #17 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x149a9f6178c1] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #18 /usr/lib64/libtevent.so.0(+0xee07) [0x149a9f61de07] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #19 /usr/lib64/libtevent.so.0(+0xcef7) [0x149a9f61bef7] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #20 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x149a9f616ba1] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #21 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x149a9f616e7b] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #22 /usr/lib64/libtevent.so.0(+0xce97) [0x149a9f61be97] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #23 /usr/sbin/smbd(main+0x1489) [0x558a01522259] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #24 /lib64/libc.so.6(+0x236b7) [0x149a9f41f6b7] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #25 /lib64/libc.so.6(__libc_start_main+0x85) [0x149a9f41f775] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: #26 /usr/sbin/smbd(_start+0x21) [0x558a01522b31] 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: [2024/08/18 02:05:46.743356, 0] ../../source3/lib/dumpcore.c:315(dump_core) 2024-08-18 02:05:46 Daemon.Error UNRAID.internal Aug 18 02:05:46 Unraid smbd[26421]: dumping core in /var/log/samba/cores/smbd

Never Mind...figured out that I had to install the full blown unassigned devices plugin to mount/unmount.

I have a clean install of unraid (6.12.11) migrated my pro key, and super.dat. The only thing that didn't work was that I had two SSDs setup as a BTRFS mirror. Currently they are shown in unassigned devices. Is there an easy way to just re-add the mirror without data loss? Can i mount one of the drives, make sure any data is cleared, then just start with a fresh BTRFS mirror again? How can I mount without any issues?

I've been having a problem saving scripts using the unassigned devices interface. With a newly formatted drive, attempting to create a new script by clicking "Default" then "save", is the same as if I "clear"ed the script, and nothing will save (verified via sftp). If I make changes to a previously working script, and click "apply" changes are lost and the unchanged script is shown. I've tried with both mounted and unmounted drives. I've verified the permissions of both the scripts and the save to location (on flash) ("/boot/config/plugins/unassigned.devices"), both look good (scripts = root/root rw 0600 folder = root/root rwx 0700) (flash drive is listed as vfat fs) If I manually duplicate a working script to the new drive serial.sh via SFTP, the scrip will show up for the drive, and allow me to automatically run it on mount, but it again will not allow changes to the script. I've tried with both chrome and firefox (neither private sessions), no script blockers. Anyone know what's going wrong? Is there something new making the flash read only in unraid? Is the vfat filesystem an issue?

But will a drive be flagged/emulated by unraid (Red X) because of too many uncorrectables? Or does there have to be something else wrong with the drive?

Scratching my head on this one...unraid fluke? Dual parity 12TB, 6.12.6, all XFS drives, monthly checks, 0 errors on last parity check. 1. I precleared a 5TB that I've had as a hot spare for my array, 0 errors, shows in unassigned devices. 2. Removed Smart Failed/But Still Good 4TB from array (10 Uncorrectables) 3. Replaced With Pre-cleared 5TB 4. Started array with Rebuild, 0 Errors on rebuild 5. Red X a different 5TB drive!? ****The drive does have several uncorrectables**** Will a drive red X and emulate if it has too many uncorrectables? And not show any errors in the rebuild?

I've read extensively on the forums and on google, but haven't found someone with my exact, relatively simple interests... I have multiple large external hard drives (22TBx) and I have extensive scripts (using rsync) that do automatic backups when powered on (unassigned devices script) every month or so. My question is, what drive format should I use for the external drives? ***I would love to turn my current backup (based-on-changed-files) to verify integrity of backed up files based on FS checksums that would refresh files if bitrot occurs. I'm not extremely worried about accessing the drives from outside machines (windows/ntfs), and definitely don't have any computational limitations. I'm thinking BTRFS and ZFS would be my best bet, but: Can rsync backups use the FS checksumming built into these file systems to determine differences? (better option than rsync?) Does FS checksumming in BTRFS/ZFS happen automatically in the background without complications (outside of the unassigned devices gui)? Is scriptable command line FS checking easy for BTRFS/ZFS? (currently using xfs_repair for XFS)

I see the point for being careful with automatic parity corrections, but with how stable my system is hardware wise, it's worked for years flawlessly. Just every once in a while i get a burst of sync errors on a 140TB array, the number of errors don't seem like a major issue vs the potential problems automatic parity correction would save me from. I considered installing some type of indexing/checksum software to watch for any type of bit rot or actual corruption...just haven't got around to it. It would be awesome if there was a way to translate the location of incorrect bits to at least a controller/drive/file...would help greatly in my case. I don't see why the main unraid driver wouldn't be able to spit out the details of the parity issue when doing corrections, seems like it would be a great diagnostic tool.

Are corrected parity sync errors truly corrected or will there be some sort of hidden corruption? The errors are not recurring and I often go several months/checks with no errors detected. The hardware has been stable/unchanged for years now. If I can't determine the issue using smart, obvious unraid errors or any log files then why wouldn't a correcting parity check just save me time?

Running the latest unraid pro 6.10.3 with dual parity using mirrored SSD's (240GB, mover nightly) as cache drives... I run a large array and run parity checks automatically every month. Most times I get no parity errors. But sometimes get a few thousand corrected parity errors. I have a ups that does a graceful shutdown (but i guess it's possible that the shutdown process takes longer than the ups power could hold out for waiting for unraid to shutdown the array). I do have power outages, but the UPS that can stand 20 minutes of run time before it tells unraid to issue a shut down. No drives have red balls or have any issues with SMART 5, 187, 188, 197 or 198 (Backblaze recommended) The physical server has not been moved/opened in several months. Two questions: 1.) What files in the diagnostics download (saved immediately after sync errors) would show me what files/drives reported the sync errors? What am I looking for in the files that would be able to tell me the details? 2.) Do corrected sync parity errors (with dual parity) mean that the data was corrected and no corruption has occurred?