computers:freenas

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
computers:freenas [2020/01/13 15:10] – [Replacing bad drives] localadmincomputers:freenas [2024/07/09 04:00] (current) – jon
Line 18: Line 18:
  
 ==== Replacing bad drives ==== ==== Replacing bad drives ====
 +Use smartctl -a /dev/(name of disk drive) to list the SMART attributes for the drive in question. Use smartctl -t short /dev/(name of disk drive) to do a basic test.
  
 https://forums.freenas.org/index.php?resources/replacing-a-failed-failing-disk.75 https://forums.freenas.org/index.php?resources/replacing-a-failed-failing-disk.75
 +https://www.thomas-krenn.com/en/wiki/Analyzing_a_Faulty_Hard_Disk_using_Smartctl
 +
 +After new drive is installed, before resilvering the drive, break in the drive with the following:
 +
 +<code>smartctl -t short
 +smartctl -t conveyance
 +smartctl -t long
 +badblocks -b 4096 -ws
 +smartctl -t long</code>
 +
 +<note important>smartctl -t conveyance will not work on the FreeNAS CLI. This will work in Windows however once you install smartctl via Chocolatey and Powershell</note>
 +
 +This will put the drive through its paces and if it survives, it should be in great shape for use. If it fails, RMA the drive if it is under warranty.
 +
 +https://www.ixsystems.com/community/resources/hard-drive-burn-in-testing.92/
 +
 +https://www.reddit.com/r/freenas/comments/928p15/migrate_pool_to_new_disks/
 +
 +==== Migrating Drive Pool to new Pool ====
 +
 +https://www.youtube.com/watch?v=UflFKgD4RiM
 +I've had to do this twice over the years when current hard drive space was getting high.
 +
 +=== Pre-Staging Steps ===
 +
 +Run the hard drive burn-in steps above on your new drives. Once done, create a new drive pool. Why? When you create a drive pool, either you set up your pool to be redundant (mirrored), or set it for max capacity (striped). If you need to expand, your only option is to mirror, if you already have a mirrored array. If you are striped, you can mirror or stripe more. In my case, I set up for redundancy. This means when I need to expand, I have to create a new striped pool, then mirror new drives in.
 +
 +=== Starting Migration ===
 +
 +https://www.truenas.com/community/threads/howto-migrate-data-from-one-pool-to-a-bigger-pool.40519/
 +
 +I've modified the steps below to reflect my experience on FreeNAS 11.2 U8
 +
 +== Steps ==
 +This assumes that you have both pools setup and connected to the same system, but the replication steps can be done between two systems and the disks moved after replication (this would apply in the instance where the primary machine doesn't have enough ports to handle the additional drives for the second pool).
 +
 +Assumption is that "oldpool" is the primary dataset name. "newpool" is the name for the new pool prior to data migration.
 +
 +The steps in a nutshell are replicate from oldpool to newpool, remove (or rename) oldpool, and then rename newpool to oldpool.
 +
 +  - The system dataset needs to be moved off of oldpool. Use the GUI to select a new location other than oldpool or newpool.
 +  - Create a system config backup using the GUI. This will be needed later, because when you detach oldpool, you will lose your share, snapshot and replication settings.
 +  - Use the GUI to create a snapshot of the dataset you want to move. If you want to move everything, select the root dataset. For flexibility in the future, I'd suggest checking the "recursive" option. Also, minimize data use of oldpool. You will want to pick a time where nothing is changing, then ensure you have a snapshot, and then wait for replication to finish. The amount of time this will take depends on how much storage and the speed of your machine. It took ~36 hours to move 20TB locally for me. [ alternatively, you can use the CLI to create the snapshot and then replicate manually. "zfs snapshot -r oldpool@hostname" and then "zfs send -R oldpool@hostname | zfs receive newpool"]
 +  - Once replication is complete and you are satisfied that all data is on newpool it's time to detach both oldpool and newpool. Use the GUI to "detach volume" for oldpool and then repeat for newpool. When the confirmation window pops up DO NOT CHOOSE THE OPTION TO DESTROY.
 +  - Using the CLI (or SSH) run the following to import and rename "zpool import oldpool olderpool" and then "zpool import newpool oldpool". (for reference: zpool import [old-pool-name] [new-pool-name-name])
 +  - Once the pools are renamed, export them at the CLI "zpool export olderpool" and "zpool export oldpool"
 +  - Using the GUI, go to the storage tab and select the import volume tab and import oldpool. This step is what enables freenas to understand and control the pool.
 +  - Once the pool is imported, you can either manually recreate your shares, or you can restore from the configuration backup we made in step 2.
 +  - I would verify that everything is working to your liking before doing anything with olderpool. For safety, I'd leave it un-imported until you decide you need it or want to get rid of it. If you want to get rid of the data on the disks, I would import olderpool and then once it is in freenas, select the detach volume option for old-tank and this time select the destroy data option to blank out the drives. This is the point of no return, so know what you are doing before confirming. 
 +
 ===== Other tips outside the guides ===== ===== Other tips outside the guides =====
  
 ==== SMB Shares and Microsoft Accounts ==== ==== SMB Shares and Microsoft Accounts ====
  
 +Be sure NTLMv1 is turned off on your Windows client
 +
 +https://www.ixsystems.com/community/threads/unable-to-authenticate-to-smb-share-from-one-particular-server.76755/
 +https://www.reddit.com/r/freenas/comments/8cl2id/could_not_authenticate_to_smb_share_with_correct/
 +
 +How connections work:
 +https://www.ixsystems.com/community/threads/smb-windows-share-drive-mapping-issues.65372/
 +
 +https://www.ixsystems.com/community/threads/cannot-connect-to-mapped-drive.44483/#post-297914
 +
 +Permissions:
 +https://www.ixsystems.com/community/threads/methods-for-fine-tuning-samba-permissions.50739/
 +https://askubuntu.com/questions/334422/mounted-cifs-share-but-no-write-permissions
 +https://www.youtube.com/watch?v=RxggaE935PM
 +https://forums.freenas.org/index.php?resources/freenas-and-samba-smb-permissions-video.8/
  
 ==== Fixing Permissions Issues ==== ==== Fixing Permissions Issues ====
  
 Revolves around using setfacl Revolves around using setfacl
 +
 +https://www.ixsystems.com/community/threads/cifs-share-not-allowing-applications-write-permission.18854/
 +https://www.freebsd.org/cgi/man.cgi?query=setfacl&sektion=1
 +
 +==== Tailscale and using an rsync task ====
 +
 +This works with the official community release, or the TrueCharts container. Assuming you're using TrueNAS SCALE.
 +
 +Install the Tailscale container inside Apps. For configuration, uncheck userspace (which allows full access to TrueNAS for the container, ie. it runs as root, allowing tasks like rsync to run), check Host Network (allows you to reference the tailscale IPs), and set an advertised route of the IP of the NAS (192.168.0.50/32. for example). You'll also need to set net.ipv4.ip_forward - 1, net.ipv4.conf.all.src_valid_mark - 1 in truenas sysctl under System - Advanced. Of course, provide your auth key from tailscale.
 +
 +Sources:
 +  * https://web.archive.org/web/20230926115849/https://truecharts.org/charts/stable/tailscale/How-To-Guide/
 +  * https://www.truenas.com/community/threads/tailscale-in-truenas-scale-using-truecharts.107185/
  
  • computers/freenas.1578928254.txt.gz
  • Last modified: 2020/01/13 15:10
  • by localadmin