Copy files internally via ssh allowed?

  • Hi all,


    I'm new to OMV, did build an own NAS machine and the setup and first steps are done. Big thanks to the developers and all supporters, great work!


    Here's one beginner question I'd like to clearify: Let's say I've attached 2 HDD's via SATA in the NAS running OMV and would like to transfer files internally in OMV. (without shared folders). Can I safely ssh as root to the NAS and copy files in the ssh session from 1 HDD to another (using cp command or maybe midnight commander)? Or does that "interfere" somehow with OMV's right's management or something?


    Thanks in advance!

  • Can I safely ssh as root to the NAS and copy files in the ssh session from 1 HDD to another (using cp command or maybe midnight commander)?


    If source and destination are shared to SMB or AFP clients and use mismatching share settings for both then you'll introduce problems for sure. Which sort of troubles always depends on mismatch of settings used. Possibilities: encoding troubles, different representation of metadata, permissions and ACLs.


    As long as you work with defaults the risk is rather low.

  • If source and destination are shared to SMB or AFP clients and use mismatching share settings for both then you'll introduce problems for sure. Which sort of troubles always depends on mismatch of settings used. Possibilities: encoding troubles, different representation of metadata, permissions and ACLs.


    As long as you work with defaults the risk is rather low.

    I understand, thanks!

  • I have done that before just ssh into your server cd /srv and just move files from one hdd to the other, now after that you can create sharedfolders and just move the files inside it. In regards to safety I am not sure what safety, this is a linux os, what you can do on debian you can do on OMV when you ssh to the server.

  • The cp command is pretty good.. but as tkaiser (basically) said. I would run it as a user... not as root.


    Sorry, misunderstanding. I was talking about different things since we're talking about the NAS use case here.


    • Encodings: Clients (Windows, macOS, Linux, other Unices) might have a different idea about encodings compared to the server side (the filesharing daemon and the filesystem). Filesharing daemons like Samba or Netatalk know about client and server side encodings and translate if necessary. Windows might use UTF-16/UCS-2 while the server is set to UTF-8 precomposed. MacOS wants to use UTF-8 decomposed instead so again a mapping usually happens. If you have different share settings a move or copy directly on the server will end in encoding mess.
    • Filesystem metadata: Windows uses so called 'Alternate Data Streams' (ADS), macOS used Resource Forks that are now part of Extended Attributes. When transferring files via SMB or AFP then filesharing daemons on the server again have to translate client features into server features (usual POSIX filesystems used by OMV provide neither support for ADS nor for Resource Forks or macOS' own Extended Attributes). How these client attributes are stored solely depends on either share or daemon settings. If you have a mismatch between different shares and copy stuff on the server you'll loose all of this metadata for sure.
    • Permission concepts: Client OS might have different permissions concepts compared to Linux. Filesharing Daemons (with appropriate settings) take care of this when dealing with client accesses (mapping access restrictions to the way it's possible in Linux, sometimes even faking some modes). If you access your data on the server these mechanisms are not in place --> permission and ACL troubles afterwards highly likely.




    I bet none of 'usual NAS users' are aware of any of these three issues (since my day job includes helping customers to recover from such mess -- and the customers are the IT departments of sometimes even large companies) but of course users constantly run into this mess. Just check the forums here and anywhere else -- but usually the culprit will not be identified but people will report that brutal workarounds like chmod -R, deleting all ACLs or forcing stupid ASCII mode by eliminating all special chars and umlauts in all files and directory names 'solved the problem'.


    TL;DR: Don't fiddle around with files directly in the filesystem of a NAS. Always let the client do the job since only then all the 'translation layers' and mappings will work. You're not affected by the above issues if you're living +30 years in the past when all we had was plain ASCII and filesystem metadata was unknown... the 'good old days' of CP/M, DOS, etc.

    • Offizieller Beitrag

    Can't say I've had the first two issues in the past, but I've cp'd something as root (quite a few times), which caused a particular file to have a completely different set of permissions than the other files in a particular directory, and something not working correctly. Then it's a PITA to solve as it's not typically something you think about.

  • Hi all, and thanks again for the detailled answers!



    If you plan on doing this a lot.. you might look at rsync. You can do this with the click of a button


    Just wanted to tell for anybody looking to do similair things: I finally did this internal copying with a rsync job. Indeed pretty easy to set up and run, even if you just do it once.
    You don't need to use the console this way, if you don't want.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!