Akshunhiro

lol, takes less than 30 seconds to reset the iDRAC. Sounds like you'll have to reset it anyway so why waste money buying a monitor? Also, perhaps setup Vaultwarden on the server once you regain access?

I suspect it was due to the default "Enable user share assignment: Yes" which would then appear as "data" in SMB. I didn't notice it listed in User Shares though. This problem started after changing "Enable user share assignment: No" for the pool. I had already exported it via smb-extra.conf since I already had a config prior to native ZFS support. "data" is the dataset of the pool but the share name (in smb-extra.conf) is "chimera". When "enable user share assignment" was set to yes, I could see both Chimera and Data which pointed to the same location. zfs list: NAME USED AVAIL REFER MOUNTPOINT chimera 35.5T 26.4T 205K /mnt/chimera chimera/data 35.5T 26.4T 31.4T /mnt/chimera/data smb-extra.conf: [chimera] path = /mnt/chimera/data comment = ZFS browseable = yes #read only = no #writeable = yes writeable = no read list = write list = XXX valid users = XXX case sensitive = auto preserve case = yes short preserve case = yes vfs objects = shadow_copy2 shadow: snapdir = .zfs/snapshot shadow: sort = desc shadow: format = auto-%B%y shadow: localtime = yes Yes, user shares are enabled. No, not anymore.

Hmmm, that share wasn't listed before though and has been deleted twice now. I've deleted data.cfg and data_old.cfg from /boot/config/shares so will see how it goes!

Hi all, just came across this issue where my single array SSD is being filled by Mover (I suspect). Not sure why Mover is kicking-in as the Share doesn't exist to begin with. I recently setup a new native ZFS pool and just use a single NVMe SSD for appdata but the last 2 nights saw the drive being filled at midnight. I just installed the Mover Tuning plugin to disable the schedule but was curious what could be causing this or what changes I need to make to my setup to prevent issues in the future. The share that's created is "data" which is also a dataset on my ZFS pool. I'm exporting the ZFS share via smb-extra.conf as that's what I was using prior to native ZFS support but it was only recently (last 2 days) I disabled the user share assignment for the ZFS pool (was exporting with the name "data"). When the share was added, I had no option to change primary storage (the ZFS pool appears but is grayed out). Diagnostics attached but removed a heap of logs for the "failed to copy" because of filenames. Jul 16 00:07:32 Ganymede shfs: copy_file: /mnt/chimera/data/XXXXX /mnt/disk1/data/XXXXX (28) No space left on device Jul 16 00:07:41 Ganymede shfs: copy_file: /mnt/chimera/data/XXXXX /mnt/disk1/data/XXXXX (28) No space left on device Jul 16 00:07:42 Ganymede shfs: copy_file: /mnt/chimera/data/XXXXX /mnt/disk1/data/XXXXX (28) No space left on device Jul 16 00:07:44 Ganymede shfs: copy_file: /mnt/chimera/data/XXXXX /mnt/disk1/data/XXXXX (28) No space left on device

Hi all, just need a sanity check please. I've had a ZFS pool in unRAID for a while but it was created in TrueNAS. I'm now in a position to create and move to a new native pool but wanted to check the correct command to migrate data across while hopefully retaining snapshots. I was going to take one last snapshot and use zfs send | zfs receive e.g. zfs send -Rcv chimera/data@migrate | zfs recv -s newchimera/data The last time I attempted this (in unRAID before native ZFS support), the dataset wasn't automatically created (it was showing but had a 0 size, all data was in the root?). I have a script to take a recursive snapshot so wondering if I should just use that instead of specifying the "data" dataset? Here's what I'm working with; zfs list NAME USED AVAIL REFER MOUNTPOINT chimera 34.2T 9.24T 224K /mnt/chimera chimera/data 34.2T 9.24T 31.1T /mnt/chimera/data zfs list -t filesystem -o space NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD chimera 9.24T 34.2T 0B 224K 0B 34.2T chimera/data 9.24T 34.2T 3.12T 31.1T 0B 0B zfs get copies NAME PROPERTY VALUE SOURCE chimera copies 1 default chimera@auto-July23 copies - - chimera@auto-August23 copies - - chimera@auto-September23 copies - - chimera@auto-October23 copies - - chimera@auto-November23 copies - - chimera@auto-December23 copies - - chimera@auto-January24 copies - - chimera@auto-February24 copies - - chimera@auto-March24 copies - - chimera@auto-April24 copies - - chimera@auto-May24 copies - - chimera/data copies 1 local chimera/data@auto-July23 copies - - chimera/data@auto-August23 copies - - chimera/data@auto-September23 copies - - chimera/data@auto-October23 copies - - chimera/data@auto-November23 copies - - chimera/data@auto-December23 copies - - chimera/data@auto-January24 copies - - chimera/data@auto-February24 copies - - chimera/data@auto-March24 copies - - chimera/data@auto-April24 copies - - chimera/data@auto-May24 copies - - Trying to avoid bungling this given how long it'll take to move everything over. TIA!

I just updated but now get this error: I'm on 6.11.4 EDIT: Fixed by updating to 6.12.6 - Had been putting it off due to TrueNAS ZFS pool but it's working fine

???

Hello, could I please get some help with date formats to setup Shadow Copies? I'm still on 6.11.4 with a pool created in TrueNAS and wanted to get Shadow Copies working in Windows but first need to work out the correct date format for both my User Script script; #!/bin/bash DATE=$(date +%B%y) zfs snapshot -r chimera@auto-$DATE (this used to be "zfs snapshot -r chimera@auto-`date +%B%y`" but just updated it to the above while testing matching the format). and my "shadow: format = auto-" in /boot/config/smb-extra.conf (only contains ZFS pool share) If I leave "shadow: format = auto-" and "shadow: localtime = yes" then all the previous versions have the same date. Any other combo and I don't see any. Here's the output of zfs list -t snapshot showing the current format; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT chimera@auto-April23 0B - 224K - chimera@auto-May23 0B - 224K - chimera@auto-June23 0B - 224K - chimera@auto-July23 0B - 224K - chimera@auto-August23 0B - 224K - chimera@auto-September23 0B - 224K - chimera@auto-October23 0B - 224K - chimera/data@auto-April23 31.0G - 20.0T - chimera/data@auto-May23 594M - 21.1T - chimera/data@auto-June23 45.5G - 21.9T - chimera/data@auto-July23 103G - 22.3T - chimera/data@auto-August23 118G - 22.9T - chimera/data@auto-September23 89.8G - 23.5T - chimera/data@auto-October23 34.7G - 24.8T - This pool is only hosting media so I didn't think it'd be worthwhile setting up zfs-auto-snapshot.sh Fixed it with: "shadow: format = auto-%B%y"

Hi everyone, Just noticed I've lost a few entries after restoring my container from backup. Unfortunately my array drive died (SSD so no parity) but I wasn't too worried as I had backups. I was keen to see how Vaultwarden would go as I'd read that the apps and browser extensions would keep a copy and sync back when it can. There are only 3 entries but not sure why these didn't update to the container. I have 2 other devices so disconnected them from the net before opening the app and I can see them there (216 entries vs 213). Will the logs show what's happening if I let one of them sync?

Alright, nevermind...

Just saw the plugin update, wondering whether I need to change anything on my system. I'm on 6.11.4 and have a ZFS pool created in TrueNAS passed-through.

Hi all, just wanted to register my interest in adding support for Dell servers. I've got an R520 and had been using a crude script to get me by. This plugin is installed but I have no idea how to setup a JSON for fan control. Reading is working fine though. For whatever reason, my script has randomly stopped working twice now. Logs say it's ran, and it outputs/prints the temps but that's it. No errors seen in iDRAC, no change if I reboot the iDRAC or even uninstall ipmitool, the plugin or a combination of all. I ended up installing PowerEdge-shutup but struggling to fine-tune is as it seems pretty aggressive. PowerEdge-shutup with log output.sh Original with log output

Ooh, I found it. Was reading up more on where snapshots are stored and was able to navigate to /mnt/chimera/.zfs/snapshot/manual/data and everything's there. It's read-only though so a standard move is taking just as long as a copy from the array. Anything else I can try? I suspect a zfs send and zfs recv will suffer from the same bottleneck. EDIT: Nevermind. It's not an elegant solution since I copied to the root and not a child dataset. Not sure how I managed that but I'll just copy everything again.

Hi all, wondering what I may have done wrong here. I've setup a pool and moved data from the array to the pool but noticed most of the folders are empty. I ran rsync -avh /source /destination and it took about 36 hours to move 15TB Once the transfer had completed, I took a snapshot before renaming the source folder from data to data_old with "mv /mnt/user/data /mnt/user/data_old" I then edited the mountpoint for the pool with "zfs set mountpoint=/mnt/chimera chimera" and symlinked /mnt/user/data with /mnt/chimera/data I saw the free space for the share in unRAID GUI reflected the available space but, after checking the share via SMB, most folders are empty. Confirmed this was the case in CLI as well. I don't think I can rollback either as the "refer" is in the pool, not the data dataset. When copying another folder, it seemed to write everything back and not just restore or refer from snapshot. Don't really want to transfer everything all over again, is there anything I can do? zfs list NAME USED AVAIL REFER MOUNTPOINT chimera 15.2T 28.2T 14.9T /mnt/chimera chimera/data 312G 28.2T 312G /mnt/chimera/data zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT chimera@manual 0B - 14.9T - chimera/data@manual 719K - 164G -