On my helios64 I had similar issues. At the end it was a faulty battery that interfered with the shutdown process. Since then I am running the nas without any UPS and it runs flawlessly again.
As I am accessing also the same shares with both protocols it's kind of easy to rename the AFP shares through the config-file in order to make it clearer for both admins and regular users
Thanks I will do memtest this morning, turns out it's not a PSU issue
One more thing: Do you have a USP Battery set up? I had a lot of random reboots recently and it turned out that the USP battery was the culprit. Once I got rid of it everything worked as expected again.
Any particular reason for using AFP? Even Apple recommends SMB...
For me it is way faster than SMB in combination with my setups (helios64 and HC1), especially when it comes to transfer a lot of small files.
There are several threads here on how to adjust the SMB settings accordingly but I always got back to AFP for getting more speed. But, of course, it might be completely different on your setup so I think everyone has to do a little bit of trial and error in order find the right protocol.
Yes, above method works flawlessly (since quite a while ;))
Mine have been sitting unplugged for months. The 2.5GBe port was horribly unstable.
Interesting. I have no issues neither with 1GBs nor 2.5GBs ports... I do believe I got one of the last shipments (but I am unaware if they changed anything with these ports btw).
Yep, I would also say you have to consult the kobol-forum. I remember some threads about the fan issue which I never had. Here is one thread for example (https://forum.armbian.com/topi…3-fan-not-working-at-all/) there might be others, too.
ryecoaaron I do hope it's gonna be a sloooooooow death although it is inevitable as Kobol pulled the plug. But I love that unit very much and I do believe that I will have fun with it for another long period.
Apple owns samba. You would think it would be better. Did you ever try nfs?
Yep, I also tried nfs which was about the same as samba speedwise... For the moment I am happy as I don't want to do trial an error with modifying samba settings. To me it is just strange that it is such a huge difference - at least in my setup.
Very old thread, but I just wanted to say how pleased I am to went back from SMB to AFP protocol. It might be really deprecated anytime soon, but meanwhile I am so happy with fast access to me NAS (Helios64). It's double the speed that I get with OMV6 and Samba shares. I just don't get it why netatalk is being abandoned for a protocol that does not work entirely well in the macOS universe...
I'm waiting for it too but you can install and use the package manually.
Decryption is also possible via the SSH console.
Or do an automated decrypt with a temporarily inserted USB stick. Work's flawlessly and no need to use within OMV. When I do restart my server outside of the office via VPN, then I decrypt the drives manually within the ssh terminal. A bit more typing but again: work's without issues.
Well, because of your post... I decided there was no choice but to kidnap Aaron. He is now locked in my basement and soon I will begin pumping him full of Starbucks and Methamphetamine. I can't guarantee his work will be accurate.. but it will done.
Serious.. cut the guy some slack. He's got a real job to you know. I think the progress he's made is pretty freaking amazing considering most of these plugins were a complete rewrite.
And of course you can make a donation to your (and his!) liking.
Thanks for the reply!
Ok, I need to dive into how that would work.
I went down the same route and I have to say it is fairly easy setting it up outside of OMV. Encryption and decryption is easy either with the commandline after boot or also an automated decryption with an usb stick.
If we helped, click here
This link is not working for me... shows a 404 page...
Yet: I also would like to contribute and would be glad if I can find somewhere valid credentials where I can do a PayPal or whatever payment in order to give a little bit back. I know votdev and ryecoaaron (and others) are putting a lot of effort into the development and are not asking for anything (which is very kind and humble) but I do believe that a post / link where regular users like me could just make a little donation would facilitate the whole process
So: could somebody help me out?
Edit: Found this page in the meantime: https://www.openmediavault.org/?page_id=1149
Is that the correct link for donations and does everybody who is involved in this beautiful project get something out of this?
+1 with an error that the File name is too long (and I am not using capital characters) while restart the mergerfs Pool.
It's no big thing at the moment as I am running MergerFS in fstab anyway without the plugin but just wanted to give it a go...Code
ID: restart_pool_mergerfs Function: module.run Result: False Comment: An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/salt/state.py", line 2171, in call ret = self.states[cdata["full"]]( File "/usr/lib/python3/dist-packages/salt/loader.py", line 1235, in __call__ return self.loader.run(run_func, *args, **kwargs) File "/usr/lib/python3/dist-packages/salt/loader.py", line 2268, in run return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs) File "/usr/lib/python3/dist-packages/salt/loader.py", line 2283, in _run_as return _func_or_method(*args, **kwargs) File "/usr/lib/python3/dist-packages/salt/loader.py", line 2316, in wrapper return f(*args, **kwargs) File "/usr/lib/python3/dist-packages/salt/utils/decorators/__init__.py", line 746, in _decorate return self._call_function(kwargs) File "/usr/lib/python3/dist-packages/salt/utils/decorators/__init__.py", line 377, in _call_function six.reraise(*sys.exc_info()) File "/usr/lib/python3/dist-packages/salt/ext/six.py", line 693, in reraise raise value File "/usr/lib/python3/dist-packages/salt/utils/decorators/__init__.py", line 360, in _call_function return self._function(*args, **kwargs) File "/usr/lib/python3/dist-packages/salt/states/module.py", line 427, in run func_ret = _call_function( File "/usr/lib/python3/dist-packages/salt/states/module.py", line 473, in _call_function mret = salt.utils.functools.call_function(__salt__[name], *func_args, **func_kwargs) File "/usr/lib/python3/dist-packages/salt/utils/functools.py", line 159, in call_function return salt_function(*function_args, **function_kwargs) File "/usr/lib/python3/dist-packages/salt/loader.py", line 1235, in __call__ return self.loader.run(run_func, *args, **kwargs) File "/usr/lib/python3/dist-packages/salt/loader.py", line 2268, in run return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs) File "/usr/lib/python3/dist-packages/salt/loader.py", line 2283, in _run_as return _func_or_method(*args, **kwargs) File "/usr/lib/python3/dist-packages/salt/modules/systemd_service.py", line 956, in restart raise CommandExecutionError(_strip_scope(ret["stderr"])) salt.exceptions.CommandExecutionError: Failed to restart srv-mergerfs-pool.mount: Unit srv-mergerfs-pool.mount failed to load properly: File name too long. See system logs and 'systemctl status srv-mergerfs-pool.mount' for details.
Did you follow the directions described here for gmail? https://openmediavault.readthe…/notifications.html#gmail
Thanks for the hint. Interestingly it works now after rebooting the machine.
Yet: I do have the SMTP port 465 enabled instead of the 587. The rest is about the same...
I did indeed miss the RC flag, but the problem remains the same. I flipped through the Changelog but could not identify any changes that were made with the notification system.
And yes, I was setting it up with a gmail account but could also give a different address a try.
As OMV6 ist still in Alpha I did not want to open a new thread,
BUT: I cannot get notifications working on the OMV6 instance. I have put exactly the same info as in OMV5 but even the testmail is not sending...
The Scheduled Jobs are working fine but I just would love to get an email what has been done and if it was successful or not
Is there some reason why are not using UUID= instead of /dev/sdx in your crypttab file?
Good point, maybe I was a little lazy. I will change it to UUID and give it a go once I am back in the office.
Sorry for refreshing that "very old" thread again but I am struggeling with one thing:
I would like to unlock more than 1 disk on startup with an USB stick. In my case I have 5 disks. It does indeed unlock the drives successfully but then the usb drive interfers with the names and mountpoints.
My drives are sda - sde and after having them decrypted they should map on sda-crypt - sde-crypt accordingly.
On boot the fstab is not working the devicelist "in a row" so it is likely that the usb stick occupies /dev/sdc and then it messes up with the additional mountpoints etc. so that for example mergerfs does not load properly either.
Is there a nice and decent way to get this solved? A delay maybe? Or can I make the usb stick recognised by the system as always sdf for example?