szim-stack

Hello I have noticed a weird issue. The ZFS Master section in Main tab is blank for minutes when I am connected via local ip to unraid server. When I use my tailscale connection it's there instantly?

Hello I’m running Unraid as a central NAS for a mixed environment: Kubuntu 24.04 (CIFS mounts via fstab) macOS clients (Finder access) Windows 11 clients (Explorer access) All access is via SMB only (no NFS), internal trusted VLAN, no AD/domain. The data share currently has: valid users = user1, user2, user3 write list = user1, user2, user3 VFS: catia fruit streams_xattr recycle Recycle bin enabled On Linux, mounts use: vers=3.1.1 authenticated SMB users noserverino noperm systemd automount Everything works well. I’m considering simplifying ownership by explicitly adding in the SMB extra configuration, as i noticed this is what the "new permission" tool does: force user = nobody force group = users The goal would be to: Keep all files on the array consistently owned by nobody:users Avoid mixed ownership Stay aligned with Unraid’s “Docker Safe New Permissions” behaviour However, since there are multiple actual users accessing the same share from Linux/macOS/Windows, I’m unsure whether forcing nobody:users is sensible, or whether it’s better practice to preserve real SMB user ownership. In a multi-user mixed-client setup like this, is forcing nobody:users generally recommended, or does that remove useful permission separation? Would this cause issues with time machine backups from multiple users. Appreciate any advice or real-world experience.

I only tried NFS as I was having the same issue with SMB and was hoping NFS would be more stable on linux. I'm happy to switch back to SMB if there is something that could be done there that would allow me to keep the cache -> array setup. Interestingly this is issue with two of my shares. However; The smaller share (0.5Gb 87 files 31 subfolder) it happens rarely. The larger one (320Gb, 6052 files, 1252 subfolders) happens all the time. Incase this could be causing issues? My Nas is one VLAN and my computers another. Both VLANs are configured in UniFi as: Internal networks In the same firewall zone (“Internal” zone) Inter-VLAN routing enabled No explicit deny rules between them Then again my macbook via smb inter VLAN has no issues.

Hello, I am experiencing repeated “Stale file handle” errors when accessing Unraid shares from a Linux client over NFS. ls: cannot access '/mnt/shared_documents': Stale file handle Client: Kubuntu 24.04 Kernel 6.14 NFSv4.2 Stable network (ping remains normal) Unraid: Shares exported from /mnt/user Shares set to Primary Cache -> Secondary Array Default disk spin-down: 15 minutes fstab entry: 10.0.20.100:/mnt/user/shared_documents /mnt/shared_documents nfs rw,_netdev,noatime,nfsvers=4.2,hard,noresvport,timeo=600,retrans=5 0 0 (Behaviour is the same for other shares mounted in the same way.) Behaviour observed: After boot, the share works normally. If left idle long enough for the disk to spin down, the next access returns: “Stale file handle” Ping to the NAS remains normal. Remounting the share immediately restores access. This occurs even if no files were modified. The same behaviour was observed when using SMB instead of NFS. #//10.0.20.100/shared_documents /mnt/shared_documents cifs username=XXX,password=XXX,vers=3.1.1,uid=1000,gid=1000,file_mode=0664,dir_mode=0775,iocharset=utf8,serverino,users,nofail,_netdev,sec=ntlmssp,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=600 0 0 It appears the issue occurs specifically after disk spin-down, suggesting file handle invalidation when the underlying disk wakes while exporting via /mnt/user (FUSE layer). Disabling spin-down appears to prevent the issue. I am also testing mounting the underlying /mnt/diskX path directly. My aim is to retain spin-down (archival usage) while maintaining a stable mount from Linux. Is this expected behaviour when exporting /mnt/user via NFS (and SMB) with spin-down enabled? Would mounting /mnt/diskX directly be the recommended approach for Linux clients? Many thanks for any guidance.

I’m seeing an SMB performance issue between macOS 15 (Tahoe) and Unraid. Symptoms: Read speeds from Unraid → macOS: ~180 MB/s Write speeds from macOS → Unraid: ~2 MB/s Network (2.5 GbE) and cache SSD are fast (iperf 1.5 Gb/s, local write 350 MB/s). Findings: Unraid testparm -s confirms: client signing = No server signing = No /etc/nsmb.conf on macOS contains: [default] signing_required=no Yet smbutil statshares -a on macOS still shows: SMB_CURR_SIGN_ALGORITHM = AES_128_GMAC It seems macOS 15 (Tahoe) ignores both client and server settings and enforces signing anyway when the server advertises SMB 3.1.1 capabilities. Could this signing be write SMB writes are extremely slow? Unraid is set to cache > array. If so any idea how to improve write speeds over SMB from mac

And using something like "unassigned devices" app I found in the app store?

Hello, When i connect a SSD via USB to the sever (formatted as ExFat) it appears as an unassigned drive but with no option to mount it? I simply want to copy files from it to a specific share. Whats the best way to do this? Thanks

Thank you both. Been doing some reading to try and understand this more. So if the share is 'exclusive' i.e. resides only on a single physcial storage, and the shares "primary storage" setting is set to "cache" and "secondary storage" to "None" Unraid will anyhow automacticlly map to /mnt/cache/ and bypass FUSE layer which is where these potential performace increase would comes from?

Great thanks. Could you elobrate slightly, what would be the advatanges of using the pool name?

I'm setting up docker for first time on Unraid and would like it run on the NVMe I used for the cache pool. Would I specify this in the path: Docker vDisk location: /mnt/cache/system/docker/docker.img Default appdata storage location: /mnt/cache/appdata/ Or use the default: Docker vDisk location: /mnt/user/system/docker/docker.img Default appdata storage location: /mnt/user/appdata/ and speficify primary storage as "cache" in the share settings

Fair enough, good to know. 250GB just seemed like a lot. (Have 3x 12TB drive 2x parity) For future reference how would I however reformat a drive to the same files system it currently is for a clean start? Considering "erase" remains greyed out?

So I am new to Unraid. I choose XFS for the array, clicked start. 20 mins later decided I actually wanted XFS encrypted. Clicked cancel chaged to XFS encrypted clicked start. 12 hours later everything works, array shows up as XFS encrypted however 250GB is used. I reckon this is from the intial XFS format? So i'd like to erase everthing and start again with a clean formatting off XFS encrypted. Yet the Erase button is greyed out? Any ideas?