Maxrad

Yep, I had a similar reaction. I was feeling incredulous that an "innocuous" space would result in such a loss! Then I just accepted it, renamed a few dozen directory/folder names and file names, and got on with life. "Life. Don't talk to me about life" Marvin The Paranoid Android On macOS I routinely use A Better Finder Rename 12 at several different points in my "managing media for Plex Media Server" workflow. A Better Finder Rename 12 can scan and correct this type of problem before large copies from macOS Finder to Unraid over SMB.

I encountered this problem and traced it to situations (copy files via SMB) where the file name or folder name ends with one or more blank spaces. It seemed odd that SMB should mangle the file name or folder name when it ends in a blank space. I wasn't inclined to investigate the problem further or raise it with SMB project. Of course, this might not be the trigger for mangled folder/file names in your situation.

Move from 6.12.5 to 6.12.6 completed without incident. Incidentally, enabling Multi-Gen LRU as per notes provided (Unraid OS version 6.12.0-rc3 available) seems to have had no adverse impact.

Ah, yes. Good point. Thanks for the reminder.

I have hardware transcoding working well in Plex Media Server on two Unraid systems: Build One: AMD Ryzen 1700X CPU and NVIDIA 1050 Ti hardware for video hardware transcoding. Unraid's NVIDIA Driver plug-in was straightforward to install and configure (make sure it is configured with ID matching the NVIDIA card's unique ID). Build Two: Intel Core i7-7700 CPU, leveraging the Core i7's GPU (Intel Graphics HD 630) for video hardware transcoding (Intel Quick Sync Video). Both systems use the "official" docker container provided by Plex (sourced via Unraid Apps). Be sure to configure docker container to reference the Plex Pass version container (see next paragraph). Both Unraid builds have "GPU Statistics" plug-in installed. "Intel GPU TOP" plugin installed on Intel build (helpful to reveal/make-available the GPU to video applications). I discovered (by error) it is essential to not overlook including the "plexpass" bit of the repository name ("plexinc/pms-docker:plexpass") AND ensure the directory used for transcoding has read/write permissions. Video hardware transcoding on both systems has delivered excellent results, been been easy to monitor/check and maintain across several Unraid updates/upgrades and Plex Media Server updates/upgrades. I hope this helps your installation and troubleshooting.

I like your build very much. It is very, very close to the ideal build I've been researching and planning for several months now. CPU I really like the Intel Xeon E-2xxxG series CPU for the following reasons: IGPU Intel UHD Graphics P630. Great for Plex hardware transcoding. ECC memory. Recommended for ZFS storage pools should I explore this in future. MAINBOARD I would be happy with either: AsRock Rack E3C246D4U Supermicro X11SCA-F (features M.2 slot(s) Supermicro X11SCL-F These mainboards support Intel Xeon E-2xxxG series CPU and feature IPMI. For me, M.2 is a nice feature but not essential. I expect the Supermicro X11SCL-F to be better priced and easier to obtain than the other mainboards. I think you have an excellent build factoring features (ECC, IPMI, iGPU), availability and price! I envy your build! Serve the Home articles that might be of interest: Supermicro X11SCA-F Review for Intel Xeon E-2100 CPUs September 11, 2018 Supermicro X11SCA X11SCA-W and X11SCA-F for Xeon E-2100 Workstations July 12, 2018 Supermicro X11SCA-F Coffee Lake X = CPU type supported = Intel Xeon Processors X11 = Generation & CPU = 11th gen. Xeon (E-2100/2200 Coffee Lake) S = No. Of CPUs Supported = Single processor C = CPU socket/Chipset (Platform) = Coffee Lake (LGA-1511 X11SC_ series Mehlow) A = Architecture Application/Feature = Legacy PCI support (as In X10SSA-F) F = Feature = IPMI

Yep, as you describe. Change Plex password. Sign-in to Plex web > Account Settings > Edit Password. Check you are signed-in to Plex web using new/changed password. Using same browser signed-in to Plex (but different tab) visit https://plex.tv/claim to get a new token. It will look something like this: claim--UJg6S91Tu13evjNL88s In Unraid edit the Plex Docker container and paste the token to the Conainer Variable: PLEX_CLAIM Save the Plex Docker container config with “Apply” button. Plex Docker container starts up as it would normally. Allow about 15-90 seconds for Plex Media Server to complete the usual start-up sequence (check libraries, basic file permissions, file/folder access checks, sign-in to Plex). All libraries hosted/shared/appearing as normal. TIP: If running multiple Plex Media Servers repeat steps 3 to 5 for each. Allow at least 5 minutes between obtaining a new/fresh PLEX_CLAIM token and modifying each Plex Media Server Docker container. I’m using Plex-Media-Server (official) docker container found in Unraid Community Applications (Network type: Bridge).

I had a straightforward and trouble-free experience resetting my Plex password and signing-in Plex servers and Plex clients. I maintain 3 Unraid servers with one instance of official Plex docker container on each. I successfully reset Plex password and had my three Plex Media Servers sign in to my Plex account by updating a new PLEX_CLAIM value in the Plex docker container config. All good. Indeed, it was straightforward enough to encourage me to change Plex password routinely (say, every 2-3 months) as a basic security measure.

I refer you to my post here: Search of SMB shares not working (MacOS client) This this solution improved my experience on macOS working with files on Unraid. I too experienced much frustration shifting away from AFP to SMB as the experience seemed much slower. However, with the right configuration changes (both client-side and server-side) I discovered SMB can be as good, if not superior, to AFP. I hope it helps you out.

macOS Finder SMB connections to three Unraid (Unraid OS plus) servers on local network (Uraid 6.10-rc3 and Uraid 6.10-rc4) have been rock-solid reliable for me. Several days testing with numerous transfers of 10s folders, 100s files, 2-40 GB total (mostly MP4 files) at a time.

I have experience significant performance improvement using macOS Finder connecting to Unraid SMB shares by applying configuration changes detailed here and (most importantly) here. I hope this helps.

Thanks for reporting on your experience Hoopster. Am interested if your experience supports IPMI while Plex docker container makes use of 2288G Quick Sync Video for hardware transcoding. Reading through this thread suggests it should work but will be interested to learn about this for your build (if indeed use case aligns). Thanks.

I notice you are connecting from macOS FInder. Suggestion here and here (same thread) might help.

Thanks for the thanks. The Unraid "Samba extra configuration" change has been well worthwhile but the real "gold nugget" in the KB450114 – MacOS Samba Optimization article is the section "SMB Signing (MacOS 10.11.4 and Before)". I highlight it here because it has been just soooo good for me. This client-side (ie on macOS) configuration change is key for speeding up SMB operations on macOS Finder connecting to Unraid. EDIT. Probably disregard the suggestion in this post "Since the release of OS X 10.11.5, Apple’s SMB Signing has been enabled by default."

You can check the file exists and its contents typing the following command into manOS Terminal: less /etc/nsmb.conf And it should work fine with any new-ish macOS. I'm running macOS 12.1

Sorry to read problem not yet solved. Did you also apply the SMB Signing (MacOS 10.11.4 and Before) tip on the 45Drives page? Well worth doing on the macOS computer to improve SMB performance. These commands typed in using Terminal on macOS. echo "[default]" >> /etc/nsmb.conf echo "signing_required=no" >> /etc/nsmb.conf …and restart macOS for changes to take effect.

I refer you to my post here: Search of SMB shares not working (MacOS client) This this solution improved my experience on macOS working with files on Unraid. I too experienced much frustration shifting away from AFP to SMB as the experience seemed much slower. However, with the right configuration changes (both client-side and server-side) I discovered SMB can be as good, if not superior, to AFP. I hope it helps you out.

6.5.54 Early Release available 8 hours ago. Note this is Early Release. I expect the General Release/Official (stable) will be available soon-ish. I can’t comment on vulnerability mentioned. I’ve installed it on my Unifi Dream Machine.

I'm sorry. It seems I misunderstood the problem. I am curious and will follow this thread to learn more.

Known problem. See this.

I too for a long time was very frustrated with very slow SMB connections between macOS and Unraid. I had several (somewhat unsuccessful attempts) at reading Samba documentation and adding various parameter combinations. Then I stumbled across a solution that provides excellent (much faster!) result. See here… My Unraid "Samba extra configuration" optimised (and working well) accessing Unraid shares from macOS Monterey 12.0.1

There are bugs in samba version 4.15.0 included in Unraid 6.10.0-rc2 impacting SMB connections from macOS. Bugs noted in samba version 4.15.1 release notes. I have reverted to 6.10.0-rc1 and wait (with calm patience) for a future release of Unraid containing newer samba version. See this post for a bit more info on my experience optimizing Unraid samba for macOS: Unraid 6.10.0-rc1 and Unraid 6.9.2 both seem to provide me with reliable SMB connections for macOS (including Monterey 12.0.1)

Below I include my Unraid (Version: 6.10.0-rc1) "Samba extra configuration". This configuration is working well for me accessing Unraid shares from macOS Monterey 12.0.1 I expect these configuration parameters will work okay for Unraid 6.9.2. The "veto" commands speed-up performance to macOS by disabling Finder features (labels/tags, folder/directory views, custom icons etc.) so you might like to include or exclude these lines per your requirements. Note, there are problems with samba version 4.15.0 in Unraid 6.10.0-rc2 causing unexpected dropped SMB connections… (behavior like this should be anticipated in pre-release) but fixes expected in future releases. This configuration is based on a Samba configuration recommended for macOS users from 45Drives here: KB450114 – MacOS Samba Optimization. #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end [global] vfs objects = catia fruit streams_xattr fruit:nfs_aces = no fruit:zero_file_id = yes fruit:metadata = stream fruit:encoding = native spotlight backend = tracker [data01] path = /mnt/user/data01 veto files = /._*/.DS_Store/ delete veto files = yes spotlight = yes My Unraid share is "data01". Give attention to modifying the configuration for your particular shares (and other requirements). I hope providing this might help others to troubleshoot and optimize SMB for macOS.

I notice Samba 4.15.1 (release notes) contains fixes for macOS. Most grateful if this could be rolled into the next Unraid build to hopefully resolve SMB connection problems. Thanks.

I think resolved my earlier reported problem of unreliable SMB connections from macOS Monterey 12.0.1 to Unraid 6.10.0-rc2. Removing several user-added parameters (ie added by me several months back) from "Samba extra configuration" seems resolve my problem and I now have reliable SMB connections between macOS Monterey 12.0.1 and Unraid 6.10.0-rc2 (samba: version 4.15.0). My "Samba extra configuration": #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end [global] spotlight backend = tracker [data03] path = /mnt/user/data03 spotlight = yes My configuration adds SMB share point "data03" with support for macOS spotlight search. Unraid 6.10.0-rc2 now working very well for me – thanks for great work! EDIT: I posted success too soon. This (intermittent) problem is not resolved.