D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Hate computers. Hate systemd. [Was Re: Hate computers. Hate HP. Hate USB.

 

On 22/12/2021 13:41, Julian Hall wrote:
> On 03/12/2021 19:16, comrade meowski wrote:
>> On 01/12/2021 13:23, Julian Hall wrote:
>>
>>>> Backed up files are owned by current user but unsure if that's just because the
>>>> current user has mounted the USB drive.
>>>>
>>>> Tried the chown command when share mounted. Every single file 'Operation not
>>>> permitted'.
>>>>
>>>> Can/should I copy the backed up files as it seems to think it owns them?
>>>>
>>>> BTW I discovered yesterday that Samba works, so although I'd prefer a native NFS
>>>> solution I may end up using Samba.
>>>>
>>>> Julian
>>>>
>>> Final attempt before I give up and use Samba. I don't /want/ to but at least it
>>> works.
>>>
>>> 1. Boot Live Distro.
>>> 2. Format main partition Ext4 using gparted.
>>> 3. Copy system backup onto main partition.
>>> 4. Pray.
>>> 5. Reboot.
>>>
>>> NB. As an Atheist step 4 may not work :)
>>>
>>> Worst case scenario I reinstall 19.3 and see if that wants to work now.
>>>
>>> Julian
>>>
>>
>> Right circling back to this, the problem that just won't die.
>
> <snip>
>
> Agreed so I give up. NFS refuses to work so regrerfully Samba it is - only that
> won't work either..
>
> In brief the same NAS (Synology DS216j) supports SMB and NFS. Currently I'm trying
> to get Samba working via the fstab. I have a .smbcredentials file in /home/julian
> but the content of that file is questionable.
>
> What //exactly// is supposed to be in that file? For example is it supposed to read
> 'username=thewordusername' or 'username=youractualusername'? Convention is the
> latter for security, but no forum explains if this is different - you're supposed
> to know. Current content is:
>
> username=myactualusername
> password=myactualpassword
> domain=myactualdomain [all in lowercase. Is it case sensitive?]
>
> At the moment I get 'bad UNC'  when I try 'sudo mount -a' in a terminal. It
> complained once that 'usedrid=username' was a bad option so I put it back to
> 'username=julian' in the fstab.
>
> fstab entry:
>
> 192.168.1.3:/volume1/DEMETER /media/julian/DEMETER   cifs
> credentials=/home/julian/.smbcredentials,uid=julian,gid=julian 0 0
>
> Kind regards,
>
> Julian
>
>>
>> If you want my honest opinion it hasn't changed from the first thing I said about
>> this, many years back. I would reclaim the disks from the Synology NAS and throw
>> it away immediately. The NAS is and always has been the problem: it's very old,
>> very crappy and has nothing to offer. It's also not working properly any more.
>> There is nothing wrong with your Mint box or the NFS client setup.
>>
>> I accept you're unlikely to want to follow my advice, so where do you want to go
>> from here? It's going to be a lot of work with some potentially highly destructive
>> and invasive testing from here on in and only really worth it if you A: just want
>> to get to the bottom of it for personal satisfaction or B: value your own time
>> very little. In a normal support scenario with a bill payable at the end this
>> would simply not be worth pursuing.
>>
>> So expecting that you'll likely want to both save money and go with option A: for
>> above (and I can't blame you for that) the next thing to do is:
>>
>> Create a brand new Virtual Machine, different Linux flavour. Use that to triple
>> check the NFS setup with the NAS. It's not your client setup, but it's worth
>> checking... again. I suppose.
>>
>> Next: I'd backup the NAS which in itself might be a problem as that's probably
>> your backup system itself. This leads to the usual dreaded "how do I backup the
>> backup" problem which you're going to have to figure out yourself. Either way the
>> NAS needs wiping completely and then reconfiguring (properly) and the data
>> repopulated.
>>
>> The Synology - which is a bag of crap anyway - isn't really very good at doing
>> it's job so how the shares are populated, their permissions and a bunch of other
>> technical stuff that can only be done via the Synology control panel is where
>> things have gone wrong. It's where you'd fix it going forward as well. It's also
>> the bit that changes from cheap crappy Synology consumer NAS to cheap crappy
>> Synology consumer NAS and although I've seen a million of these things I haven't
>> seen yours and can't directly help you with it. It's not going to help that the
>> average low end consumer/SOHO plasticky Synology NAS box wasn't really fir for
>> purpose in the first place and that one is now many, many years into it's life: I
>> imagine it's by now unsupported too so even if you nuke it and reflash it with the
>> last firmware (which you should do) it's still going to be just as unfit for
>> purpose... with more security bugs. No thanks.
>>
>> So that is how I would proceed I'm afraid. There is a middle ground I guess: after
>> testing with a fresh VM but before nuking it completely it would be worth backing
>> the data up first and then just try nuking all the permissions NAS-side. It would
>> be worth experimenting a bit first on a setup that can be sacrificed to dangerous
>> tests like recursive permission resets safe in the knowledge that you're backed up
>> and about to rebuild it anyway. Should give you an idea of what's going to work
>> once the data is repopulated after resetting the NAS.
>>
>> There is no point in monkeying about with it from the NFS client perspective any
>> more - there's nothing wrong with that end and nothing we've done is solving the
>> problem. It's the NFS server.
>>
>> This bit of information has long since faded into the past at this point so can I
>> just ask again: what is the total capacity of the NAS? And how much data is on it
>> anyway? I have a funny feeling that all this time is being wasted over a crappy
>> little box that has a mere 1Tb available. You could have bought a 2Tb HDD for
>> ~£50, stuck it in the Linux PC and moved all the data to it when this problem
>> began and come out miles ahead. It would have better in every possible way too.
>>
>>
>>
>>
>>
>>
>>
I think at this point I would be yeeting that thing out the window, and building a
new 'box' from scratch for the time/energy its costing you .. And you'd have
something more reliable, consistent and upgradable, secure and more all in the 
package ..

I'm rather sad these people went to the wall .. https://kobol.io/ . I wanted that
64-bit box (albeit without the full kit, just the motherboard/cpu/etc.

Still, with a sleek mATX case like the
https://www.amazon.co.uk/gp/product/B015IYLSFS/ (which I bought) a couple of disks, a
modest CPU/motherboard (I've used integrated ones without issue for this purpose) and
you're cooking. That said, if you want to go serious-NAS and put 4x 3.5" disks in -
DON'T buy that case, the drive bays are a bit quirky.

</my 2cents>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

-- 
The Mailing List for the Devon & Cornwall LUG
https://mailman.dcglug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq