jmos1277

Members
  • Posts

    123
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

jmos1277's Achievements

Apprentice

Apprentice (3/14)

0

Reputation

  1. Yes! I've been following the Samba bug on the Samba-Bugzilla. I saw it was patched in 4.17.8 and have been checking unRAID release notes since then. Looking forward to unRAID v6.12.3 (hopefully). In the meantime, I put the following two commands into a shell script that I run periodically: find "$1" -type f -name "._*" | while read n ; do rm "$n"; echo "Removing " ; echo " $n" ; done ; find "$1" -type f -name ".DS_Store" | while read n ; do rm "$n"; echo "Removing " ; echo " $n" ; done
  2. I came across that when trying to determine what was going on. It wasn't clear to me if this was fixed yet. I guess that status of "Assigned" kind of implies that it is still unresolved.
  3. Thanks for the update and the suggestion. I currently have my own script that I used to run periodically. I stopped when I started using the 'veto files' option. Looks like I'll be using my script again until I can figure this out.
  4. Hmmm .... the mystery intensifies. I ran your experiment using BBEdit and attempted to write to my share directly from BBEdit's save dialog box. I received two errors, back to back ... "Names that begin with a dot "." are reserved for the system." with the option to "Use "."" I selected Use it. Then, a second error popped up: "This operation couldn't be completed, because an error occurred." Finally, I checked my sambaShare ... and the FILE was there despite the error message ... LOL!
  5. @wgstarks, what version of unRAID are you currently running? I only started having this problem when I upgraded to 6.10 (and now 6.11). My setting worked previously when running 6.9.x. I have rebooted several times as I've been experimenting. I've also started/stopped my array numerous times. Just out of curiosity, when you attempted to create the ._test file, was the error that you received a macOS Finder error or was it a Samba error? I ask because the macOS Finder will throw an error and prevent your from creating a file called ._test even on your local drive. Is it possible that the error you saw was a Finder error? The attached image illustrates the finder error. I attempted to recreate your experiment whilst side-stepping Finder ... opened up Terminal ran "touch ._test" to create the "._" file ran "cp ._test /Volumes/sambaShare" As expected, the write to my sambaShare succeeded even with my veto files setting. If things were working properly, the write should have failed. Thanks again for taking the time to run your experiments and for responding!
  6. Thanks for the reply. I just read through the thread that you referenced but still have some questions related to the 'veto files' option. Does the 'veto files' option still function properly for files other than the macOS dot files? According to the Samba v4.17 docs, veto files is still an option and should still work. Are the macOS dot files treated differently than a standard file by Samba thereby requiring the use of "Enhanced macOS interoperability"? Is it possible that this bug, "Samba v4.17rc1 BUG 15143" was not fixed in time for release of v4.17? I read through the Samba v4.17 release notes and it's not clear to me if this bug was fixed. Samba v4.17 Release Notes As a side note, I've played around with enabling "Enhanced macOS interoperability" and tried again just this afternoon after reading your post. My problem has always been that I have hundreds of files that seemingly include forbidden characters in their name ("/", "?", etc.). WIth "Enhanced macOS interoperability" enabled, those files are not even visible when browsing my Samba shares. One of these days, I will take the time to rename them. The funny thing is ... those filenames are valid on macOS and those files were all created on macOS and copied to unRAID withOUT "Enhanced macOS interoperability". I am able to see/edit them without "Enhanced macOS interoperability". However, when I enable "Enhanced macOS interoperability" those files are no longer visible. I don't know everything that's going on under the hood ... but this seems backwards to me.
  7. I recently upgraded my unRAID server and I noticed that the pesky macOS-generated dot-files have returned! I haven't changed my server Samba configuration since June 2021, but it appears some of the underlying changes in recent updates require that I do. It seems my 'veto files' setting is no longer functioning properly. My 'Settings -> SMB -> SMB Extras' entry looks like the following: [global] #prevent 'dot' files from getting created veto files = /._*/.DS_Store/ #prevent Windows from creating DOSATTRIB in extended file attributes store dos attributes = no #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end I've also attached my testparm output in hopes that someone might see something wrong in there. The testparm settings clearly shows that 'veto files' is included and set in the [global] section. However, it doesn't appear to be doing anything. Any Samba experts out there that might have an idea what changed and what I need to do to get this working again? To be clear, I'm not interested in simply hiding the dot files. I want to ensure they are never written to my server when I copy files from macOS to unRAID (or edit them). It's not clear to me if it matters (I don't think it should), but I have the "Enhanced macOS interoperability" setting in unRAID set to "No". testparm.2022.10.10.txt
  8. Ok, of course, immediately after posting my message I tried "one more thing" and may have solved my problem. Maybe someone can chime to let me know if this makes sense. I simply rearranged my settings in my SMB Extras config. I moved my: [global] veto files = /._*/.DS_Store/ to the very top of my config file and moved the include for 'unassigned devices' below that (this was previously at the top). Now, when I run testparm, the unassigned devices drives no longer have a blank 'veto files = ' line. And, more importantly, they appear to be obeying the global setting. Would rearranging my extras config affect things in this way?
  9. I'm not certain if I'm the only one ... however, I recently noticed that my 'veto files' setting is no longer functioning. I've had the following in my SMB Extras for quite some time: veto files = /._*/.DS_Store/ ... and it has worked for quite a long time to prevent those pesky macOS files from littering my unRAID server. Just recently, I noticed that my unRAID server is no longer preventing these file from getting created. I haven't changed any configuration options, but I did update to 6.9.2 not long ago. The release notes for 6.9.2 do indicate that SAMBA was updated to version 4.12.14, but I cannot say for certain that the problem only appeared after the update to 6.9.2. I have confirmed that my smb-extra.conf is getting included in my smb.conf file. My smb-extra.conf also contains my smb-settings.conf for my 'unassigned devices' plugin and those are mounting and working properly. I ran testparm -v and found that my 'veto files' setting was only getting applied to a single share from my unassigned devices plugin. I thought I was clever and added the [global] tag above the 'veto files' line in my SMB Extra config. Now when I run testparm -v it shows my 'veto files' setting in the global section of the output and a blank 'veto files = ' under my unassigned devices shares. Has anyone else had any recent issues with the 'veto files' setting? Am I doing something wrong with the veto files setting? I've attached my testparm output Any suggestions on how to root out the issue? testparm_output.txt
  10. Thanks for the suggestion .... I'll definitely enable the syslog server.
  11. I recently updated my system to 6.9.2. Today (maybe late last night), my system crashed for the first time ever. It's been running stable without incident since I built this new system back in April 2020 (my third unRAID build since 2010). I have no idea if the crash was a result of the upgrade or just pure coincidence. But, I thought I would post my system diagnostics and a screenshot of the crash just in case anyone has any thoughts or similar experiences. The attached screenshot is just a photo of my console after the crash. I wan't able to get the log off the system prior to rebooting since it was totally dead. The screenshot is the only info I have about the events leading up to the crash. I rebooted my system earlier this afternoon and it's currently running a parity check. media-diagnostics-20210413-1845.zip
  12. Has anyone come up with a better solution than this? I'd rather the default settings apply to my array so those settings automatically get applied to new drives. It's seems like a bit of a hack to use the general settings to apply temperature thresholds to a few unassigned devices. Currently, I get a warning every time I write something to my NVMe drives 😞 It would be great if we could assign temp thresholds to unassigned devices.
  13. I'd love to see a proper SAS spin down implemented too. +10 I'm in the process of upgrading my server and WAS planning to purchase some SAS drives. Not sure what to do now that I've found this thread.
  14. johnnie.black, I will definitely do non-correcting parity checks in the future. I feel like I've always done correcting parity checks in the past because the default setting under "Array Operation" of my unRAID interface always had the box checked. At least I think it did. Maybe I checked the box a long time ago and have just forgotten I have been running my unRAID box for almost seven years now!