-
Posts
10161 -
Joined
-
Last visited
-
Days Won
19
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Everything posted by dlandon
-
"ZFS file systems have built-in mechanisms such as periodic scrubs, snapshots, and metadata updates that can prevent disks from entering standby mode. These operations are designed to maintain data integrity and can cause disk activity even when the system is idle, keeping the disks from entering low-power states." That being said, UD has to check unassigned disks when it polls for various status and may be triggering a zfs disk operation. It acts differently from a pool disk because UD disks come and go and pool disks are static and only change when the array is started or stopped. If the UD disk is not mounted, you can detach it and that will put it into a standby mode. If it is always mounted, I would suggest moving the disk to a pool disk. I notice some disk read operations when a zfs disk is unmounted, and I may put a little time into understanding what UD is doing that might cause that.
-
Install UD and detach the drive. It will then show in the Historical devices.
-
It looks to me like the remote shares are auto mounting because 30 seconds after UD says it's waiting 30 seconds, the remote shares start mounting. But two did not mount. Then I see where you loged in and mounted two manually: Yes. There may not be long enough time waiting for the remote server to be available. There is a UD setting that sets how long UD will wait to mount remote shares. Currently you have it set for 30 seconds: Mar 8 07:32:10 Monolith-6 unassigned.devices: Waiting 30 secs before mounting Remote Shares... The setting is 'Remote share mount wait time' in Settings->Unassigned Devices. UD will also attempt to update the online status before trying to mount remote shares, so it should automatically get the current status before mounting.
-
Issues transferring larger files from Windows PC to UnRAID <SOLVED>
dlandon replied to Roscoe62's topic in General Support
Based on all you've been through, I think it might be time to look at hardware issues: Do a memory test. As @JorgeB suggested boot Unraid on an old laptop or another computer and test the file transfer. Replace motherboard and processor? -
High CPU Usage / Spikes - find /mnt/cache/docker -noleaf
dlandon replied to psy's topic in General Support
Set up cache_dirs to only include the folders you really need to be scanned. Don't use the default settings. It will end up scanning everything causing the issue you see. -
Unraid appears to be losing data transferred by Krusader
dlandon replied to Bmalone's topic in General Support
Post your diagnostics so I can see how your system is set up. -
The method for determining if a remote server share is available has changed from a ping to checking if the port is open for SMB on the remote server. Check that SMB is enabled on your remote server. Also, be sure port 445 is open on the remote server and it is not being blocked by tail scale or a firewall.
-
Problem: Suddenly can't access SMB Shares on any PC
dlandon replied to Anon's topic in General Support
If it were me, I'd boot in safe mode and verify SMB was working, then add back plugins and dockers until it stops. -
Problem: Suddenly can't access SMB Shares on any PC
dlandon replied to Anon's topic in General Support
Yes. That won't change the configuration, but will update the system and might be worth a try. I would do this of the two choices. -
Problem: Suddenly can't access SMB Shares on any PC
dlandon replied to Anon's topic in General Support
That looks like it might be a port issue. SMB uses porrt 445. Is there a chance it's being blocked somewhere or in use by a docker or VM somehow? It's very close to port 443 used by https://. -
Problem: Suddenly can't access SMB Shares on any PC
dlandon replied to Anon's topic in General Support
I'm actually in Texas, US of A. I really don't see anything in the diagnostics that necessarily indicates an SMB issue. I'm leaning towards a network/routing issue. I see a few things that should be checked/confirmed: Gateway is 192.168.50.1 but DNS server is 192.168.50.5. Is this correct? It appears the router is supplying the Unraid IP because Unraid is setup to use DHCP? You have said you can ping and log into Unraid so I'm confused why SMB wouldn't work, especially when using the IP address. There is a domain defined - 'loesle'. I suspect this may have been from using AD at some point and is left over. You might try re-configuring SMB Settings. Change a setting and the apply it to regenerate the config file. Do the same for your network settings. As a side note, your access to Unraid is limited to http://. Redo the 'Management Access" settings and enable https://. -
SMB browsing extremely slow, have tried caching and RSS tuning...
dlandon replied to Kyle Boddy's topic in General Support
There are several things that can affect SMB performance. Some of these things are: Network issues. SMB configuration. Unraid array configuration. I've seen a lot of mis-configured and poor network configurations. This can have an impact on what appears to be SMB issues. The biggest issue with networking I see is users trying to set up Jumbo frames and don't get it right. The way you have your shares set up can affect performance. The "Allocation Method" for distributing files in the array can have an impact. I believe the "High-water" method tends to be faster. As for SMB configuration, Unraid configures SMB to be most compatible. Making the SMB Extras adjustments suggested above can help in a particular situation, but would not be the "most compatible". The "store dos attributes = no" setting turns off the following settings if they are on: map archive = Yes map hidden = No map readonly = no map system = No These are the default Unraid settings, so the only one that is changed is the "map archive". This is the DOS file system archive bit. As for the "ea support = no", this disables extended file attributes. Extended file attributes are used on xfs and btrfs file systems in Linux and turning this off may impact their operation in Unraid depending on what applications are using the Unraid files and if they need extended attributes. So while I appreciate that maximum SMB speed is desireable, applying these "tweaks" to Unraid is not in the best in the interest of compatibility. You are free to do these tweaks in SMB Extras for your particular needs with the understanding of the potential downside. The calls for action "why don't the Unraid devs fix this", is a tough one for Limetech: Samba is open source software that Limetech has no control over. The Samba team has to pretty much reverse engineer SMB because Microsoft is not that forthcomming about SMB functionaliy. Limetech configures SMB the best it can based on keeping the most compatibility. If we can come up with SMB configurations that can help with responsiveness and maintain compatibility, we can definitely implement that. There is one SMB setting I've implemented in UD that might help. If someone can spin up a UD disk and share it with SMB and let me konw if the browsing is improved I can work on implementing that in core Unraid. The setting is: vfs objects = dirsort An SATA disk would be best because USB disks tend to be slower. Be sure to have MacOS compatibility turned off because it blocks this setting. You can't set this manually in SMB Extras because it overwrites other "vfs objects" settings in SMB since SMB Extras are global settings. The downside to the setting is that there is more processing time to sort the directories. I suspect this is similar to the Windows indexing. EDIT: Another setting to try is "Case-sensitive Names" in Share Settings. Read the setting Help by clicking on the setting description and see if a different setting will help.