Beiträge von senappa

    Found out the issue, and I'll leave it here for posterity for anyone else who's run into an issue like this.


    Basically my default local user account on Win10PC1 was username1, and I had a user with the same name on 'access rights management', and this seemed to have caused some issue.


    I deleted the username1 account unser the access rights management, and no longer have this issue above.

    NTFS drives are not properly supported by Debian. I highly suggest to use just one of the file systems offered by OMV.

    In this case the NTFS drives are the ones that are all okay between the clients - it's the sole EXT4 drive (sharedisk1) that's has this odd symptom...

    Hi, I have an weird (I think) permissions issue I noticed when coming across editing some text files. Here's the symptom.


    My setup:
    - NASBOX with OMV 4.1.23-1 with with 4 drives -- shareddisk1/2/3/4.
    - multiple Windows 10 clients - Win10PC1/2/3... running Win 10 1903 Pro and Home versions.


    Symptom (Recreation of Steps):
    - I create a sample1.txt to shareddisk1 from Win10PC1.
    - I can open, copy, move, delete the sample.txt from Win10PC2, Win10PC3, and on, BUT
    - I cannot edit the sample1.txt from Win10PC2/3 -- I get a permissions error message.


    However, if I do the change scenarios slightly -- create a sample2.txt from Win10PC1 on shareddisk2/3/4, I have no problems editing the same file on Win10PC2/3.
    In addition, if I create another sample3.txt from Win10PC2/3 to sharedisk1, I can edit that same file from Win10PC1 ?( .


    Confusing enough? :S


    Steps I've tried to resolve:
    - On Win10 PCs, I have:
    * made sure the all the network is on same workgroup
    * enabled Function Discovery Provider, Function Discovery Provider Host, SSDP, and UPnP Device Host
    * enabled all SMB1.0/CIFS File Sharing support and SMB Direct features
    * clients are all on Private Network
    * turned on network discovery
    * turned on file and printer sharing
    * turned off password protected sharing


    - On the OMV box, I have:
    * under SMB/CIFS shared folder options - "acl allow execute always = yes" on the extra options.


    All the shareddisks are setup/shared in the same way EXCEPT that sharedisk1 is EXT4 file system, and others are NTFS. Perhaps this is the cause of something (ACL options maybe??) But I don't know what else to try at this point.


    Any help would be appreciated:

    Looks pretty easy. Have you done any other dockers?

    I've managed to get emby working without issues using docker... (thanks to your excellent videos! And not just docker, but my whole setup so far, actually :thumbup: )


    I haven't been brave enough to try it out on the primary NAS box yet, but seeing as I haven't found other resources on this just yet, I might have to procure some old laptop and create a little test box to try out...

    Hi all,


    I'm pretty new to the NAS world, and after climbing the learning curve a bit (multiple reinstalls, etc), I've finally have been able to get it working well, and have started to go a bit deeper (like now using it as a media server with emby, etc...)


    One thing I'd like to accomplish is to see if I get the the OMV directly link with OneDrive -- I've seen some workarounds, but none quite fits what I'd like to accomplish. These are:


    - Live syncing to/from designated folders in my NAS drive (no scheduled tasks)
    - Would like to avoid a intermediate steps if possible (e.g. using another syncing tool between another PC client and NAS)
    - Sync using OneDrive - Business account to be specific.. I get 1TB through my alma mater for free and I'd like to utilize this if possible.


    Closest I've seen are duplicati plug-in, and using workaround like explained in links below:
    https://www.epinionated.net/us…o-sync-nas-with-onedrive/
    http://forum.openmediavault.or…hlight=onedrive#post98103


    But they all don't quite check off my would-like lists, so wondering if there's anything out there.


    Thanks in advance for any responses.