OMV keeps loosing write permissions after a couple hours.

    • OMV 4.x
    • Resolved
    • OMV keeps loosing write permissions after a couple hours.

      Ok, I am one step on dropping this program in the "its shit" bin.

      I have several shared folders and despite my ultra best efforts in setting user permissions the software will NOT let me save/alter files in a folder share unless I go into the ACL of a shared folder and toggle recursive permission. The problem is this is only temporary as within several hours I lose all write permissions and have to go in and do it again. I have to do this to any and every shared folder I want to write data too. Coming back the next day requires me to log back into the web console and toggle recursive permission all over again. This is NOT between reboots.

      I upload via ftp under a created username (only have one) and at this point in attempt to figure out why write permissions are dropping I have elevated the permissions of the account to damn near root status. Ideas anyone?
    • Then just reinstall and see if the problem goes away. You don't have much to loose. Then install one thing at a time and see when the problems reappear.

      I assume that you wiped the data drive during install and that you ONLY use Linux filesystems? ext4?

      And why do you have several shared folders? Is that really necessary? Also why use ACL?
      OMV 4, 7 x ODROID HC2, 1 x ODROID HC1, 3 x 12TB, 2 x 8TB, 1 x 4TB, 1 x 2TB SSHD, 1 x 500GB SSD, GbE, WiFi mesh
    • mainly I dont want to reinstall now because if for some reason the software is incapable of re-establishing the existing folders then it would take a ton of time to move data around (first to external sources...and then back onto it at a cringe inducing 5mbytes a second. This is another existing problem for this device).

      The drive was purchased solely for this project and it is formatted as ext4.

      Multiple folders for multiple types. One is backup files, music, movies, ect. And I dont want programs accessing one type of media to be confused by unrelated stuff (like BS video files in my backup folder getting picked up by plex/dlna looking in movies). One share is not public, too.

      As for ACL, how can you NOT use ACL? You would have zero permissions then.
    • JeffMD wrote:

      As for ACL, how can you NOT use ACL? You would have zero permissions then.
      This is a misconception. I don't use ACLs and I don't use OMV to set permissions on anything. I set permissions and ownership in the shell. And I have no permission/ownership problems with anything.
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • There's two types of supported permissions:

      - Basic Linux permissions are based on Owner - Group - Others
      This is in the lower half of the capture below

      - Extended permissions (ACL's) set read, write, or no access based on name / group. This is in the upper right hand corner of the capture.




      Extended permissions were not native to Linux early on. They're an add-on, with settings stored in a files extended attributes.

      Without getting inti specific's, the two are not fully compatible. One can actually cancel the other. (The two, together, require a functional Boolean "AND" to get write access.)

      The easiest and most predictable results will come from using Basic permissions only. If you don't check boxes in the upper right, you'll have basic permissions.
      _______________________________________________________________________________

      JeffMD wrote:

      The problem is this is only temporary as within several hours I lose all write permissions and have to go in and do it again. I have to do this to any and every shared folder I want to write data too. Coming back the next day requires me to log back into the web console and toggle recursive permission all over again. This is NOT between reboots.
      This sounds like you're importing or over writing (refreshing) files from a foreign host. And note that a "foreign host" can be a Docker that's not configured correctly.
      ((Remember, a Docker is a full-on but bare bones Linux installation. The root account, in the Docker, is not the root account in the host. Getting Volumes and Bind Mounts configured correctly, in the Docker, is half of the battle.))

      When files from a foreign source are written to the local host, they're given permissions based on the default create mask for the root user which is, typically, root:root. This applies to Rsync operations and, I imagine, ftp copies as well.
      ______________________________________________________________________________

      JeffMD wrote:

      mainly I dont want to reinstall now because if for some reason the software is incapable of re-establishing the existing folder
      This is not a problem, assuming the drive was formatted by Linux. (In OMV) After a rebuild, go to shared folders, click the add button, name the shared folder, select the device/drive where the old folder exists, then in "Path" click on the folder icon and navigate to the old folder. Oh, and set the right permissions where you'll notice that Basic permissions are provided. (Not ACL's.)

      But if you're worried about problems, back up your boot drive before the rebuild. This is the prudent course of action, in any case.

      The post was edited 2 times, last by crashtest: edit ().

    • flmax, I think I understand what you mean by docker now (it sounded like a plugin manager). This is a SBC device and the image for it boots directly with the web interface active, and the admin logon there is separate from the root logon in shell. So file permissions I am trying to enforce via admin/personal user are being overwritten by root because root is not properly notified. Unfortunately it is difficulty for me to know what root is and isn't seeing. I had the check boxes in the upper half set (user Jeff had everything from root, ftp, and many other programs used by OMV as checked) to no avail. I attempted to go all out open permissions using the bottom part too (aside form the recursive check box) but to no help.

      the check boxes never changed, permissions set in this window stayed, but the next time I came to upload something to a share, any share, it would be denied until I came in and checked recursive permissions. I think im just going to close the door on this renegade SBC. I kind of saw the OMV videos and thought hey, this should be a drop in the bucket, but now I see OMV is like the only nas software for it unless I want to attempt running others on the ambian linux for it.
    • JeffMD wrote:

      flmax, I think I understand what you mean by docker now (it sounded like a plugin manager).
      Dockers are not plugin's. They're a type of VM that is cut down and designed for one specific server or task (usually). They're also on their own internal network (172.x.x.x) for management purposes. That doesn't mean that they won't work fine and last a long time, etc., but setting them up does require attention to detail. (And referring to the guidance provided by the Docker author, on hub.docker.com/ , is a good idea as well.)

      JeffMD wrote:

      This is a SBC device and the image for it boots directly with the web interface active, and the admin logon there is separate from the root logon in shell.
      Functionally, SBC images are almost the same as X64 installations, with a kernel that will run on Arm platforms and other tweaks. The difference is, since the hardware is known (a given), SBC images are (mostly) preinstalled. While it might seem like they're "installing" they are, in fact, updating packages during the "power-on" first boot.

      JeffMD wrote:

      So file permissions I am trying to enforce via admin/personal user are being overwritten by root because root is not properly notified.
      The admin user, used to access the GUI, is just for logging into the GUI. Actions executed within the GUI are done by the root user. When you make permission changes in the screen above, they are authorized/enforced by the root user. (Otherwise they wouldn't take at all.) And as others have indicated and I personally recommend, don't use ACL's (in the upper right hand corner of the capture above).
      ________________________________________________________________________________________________________

      Realize that I'm way short of the actual details of what you're trying to do and permissions issues can become abstract, real quick. (And it doesn't matter what platform we're talking about either, Mac's, Linux, Windows, etc., when it comes moving files around among networked foreign hosts. All will overwrite preexisting permissions on foreign files, with those native to the receiving host.)
      I still think something is mis-configured where files are being manipulated, converted, updated, copied, moved (in some way) where newer versions are saved, which results in over writing the permissions you've set. There must have some automated background process that's doing this - it can't happen on it's own.

      JeffMD wrote:

      I think im just going to close the door on this renegade SBC.

      Since it will operate in a manner that's very close to an X64 platform, I wouldn't pull the plug on the Renegade. It will operate fine as a NAS, for storing your files and making them available on the network.
      If you're trying to set up a media server, maybe what you need to do is "simplify" your processes. Make some determinations on what you want, prioritize them, and set them up one at a time. Myself, I prefer a bit more manual control.

      If you want to take a closer look at what's happening on your NAS (permissions wise), take a look at WinSCP and consider installing it on a Windows host. It has a graphical Explorer like interface. When right clicking on a file in WinSCP and selecting "properties", you'll get a look at permissions assigned files/folders. (But be careful not to change anything on the boot drive, without backup, or knowing the effects.)
    • flmax, I was using winscp as my ftp client as well as to run some command shell ops (mainly the benchmarking programs to trouble shoot my strange speed bottleneck). I am not sure if viewing file permissions would have helped. Currently I am flipping all the files around and making the usb data drive ntfs, but I may give the scb one more chance and this time I won't touch the top part. I just searched and it looks like there should be little trouble using the drive ntfs formated. I'm not asking for anything much from OMV, this is simply a file server for OTHER media servers and central file access.
    • I hate open ended threads so an update. After a whole mess of behind the scenes things and alternative attempts at re purposing other devices as a nas I ended up giving the renegade another try with OMV. This time I made sure I stayed clear of ACL (Only once, transmission needed a flag). %90 of my issues did not show up this time around and I've been pretty happy with how its working out. It seems to handle a dlna (music share, a plex server is my dedicated video sharer) and I even decided to throw transmission on to it with no issues.

      Only one issue, transfer speeds when uploading to it eventually level out around 25Mbytes a second or 200mbit. They start out much faster but within a minute it will drop to about 25-30Mbytes a second. I know Nailing down this performance spiral is an artform of itself because of how many other devices it manifest on, but still speeds are above all necessary thresholds.

    • JeffMD wrote:

      I hate open ended threads so an update.
      Damx. I respect that. Hat's off for coming back with the rest of the story...
      If only other users would share their end experience with a problem, a multitude of others wouldn't have to learn the same lesson the hard way. This makes you a valued contributor. Please accept my sincere thanks for that.

      JeffMD wrote:

      This time I made sure I stayed clear of ACL (Only once, transmission needed a flag). %90 of my issues did not show up this time around and I've been pretty happy with how its working out.
      As you might have gleaned, in this process, permissions can get complicated. As best as I can determine (and I've read articles, from simple explanations, up to white papers on the subject) Posix ACL's are nothing more than a band-aid add-on to the existing Owner, Group, and Others, permissions. They're applied in a Boolean "AND" operation. (Not an "OR" operation, as it works in Windows.) That is to say if a group member has read and write in standard permissions, an ACL entry (by name) will be more restrictive. If the user in is a group that has write access, but is set by ACL to "read only", the most restrictive level access (read only) overrides.
      These subtleties can be useful in application, but they're way beyond what is practically useful, or even relevant, for use in a home NAS. When it comes to permissions, I couldn't stress the KISS principle enough.

      JeffMD wrote:

      Only one issue, transfer speeds when uploading to it eventually level out around 25Mbytes a second or 200mbit. They start out much faster but within a minute it will drop to about 25-30Mbytes a second.
      This is another matter altogether and there are a number of factors involved that run from the size of the files involved to the native cache size of a consumer SATA drive, which is probably what you're using. (The latter, drive cache size, creates a "faster than real life" sales gimmick to simulate faster but unsustainable drive throughput until the cache / buffer is empty.)
      I'd bring in the forum storage and throughput testing guru for an opinion but, nothing would change in your situation and, while you might learn a few things if you could sift through the exchange for something technically useful, the condescending tone would put you off. (Trust me on that. :) )

      In the bottom line, without knowing what your entire hardware picture is, 25-30Mbytes per second is livable (IMHO).

      The post was edited 4 times, last by crashtest: edits ().

    • flmaxey wrote:

      This is another matter altogether and there are a number of factors involved that run from the size of the files involved to the native cache size of a consumer SATA drive, which is probably what you're using. (The latter, drive cache size, creates a "faster than real life" sales gimmick to simulate faster but unsustainable drive throughput until the cache / buffer is empty.)


      In the bottom line, without knowing what your entire hardware picture is, 25-30Mbytes per second is livable (IMHO).
      It is a standard USB 3.0 sata drive. I have been using them for years (from 1,2,4, and now for this a single 5 gb unit). I have transferred large numbers of files between them and know 50Mbytes is the normal average, sometimes faster if one side is SSD. Also At the time of last test, both the source and destination were Ethernet wired to the same switch router. Still, I have not done any internal benchmarks since the new install so I shouldn't go running around putting out fires where they may not exist yet. :)

      Edit: Thanks to my other thread, looks like write speeds to the drive are a proper 60'000Kbytes at worst from iozone.

      The post was edited 1 time, last by JeffMD ().

    • flmaxey wrote:

      This is another matter altogether and there are a number of factors involved that run from the size of the files involved to the native cache size of a consumer SATA drive, which is probably what you're using. (The latter, drive cache size, creates a "faster than real life" sales gimmick to simulate faster but unsustainable drive throughput until the cache / buffer is empty.)
      I'd bring in the forum storage and throughput testing guru for an opinion but, nothing would change in your situation and, while you might learn a few things if you could sift through the exchange for something technically useful, the condescending tone would put you off. (Trust me on that. )
      Seriously. Why can't you stop your constant annoying babbling, silly advices and badmouthing? The issue is totally unrelated to your 'wisdom' and just a standard problem with SBC explained here.
    • I suppose you completely missed the permissions issue altogether which was the main topic of this thread? (You know, where the user was considering "closing the door" on the renegade.) Where were you for that?

      Oh, that's right, you don't do general questions, do you? :) (As you've put it yourself, "No patience".) It's either "storage throughput" or "toy hardware".

      tkaiser wrote:

      Seriously. Why can't you stop your constant annoying babbling, silly advices and badmouthing? The issue is totally unrelated to your 'wisdom' and just a standard problem with SBC explained here.

      I'd ask the same question of you, but that would be pointless.
      We on this forum, and other forums, understand your anger management issues. And as indicated in the following, apparently, you recognize it yourself.
      So what's the deal? Is it everyone else or is it really just you , that gets under your own skin?
      I've mentioned it before - you might consider getting some help.

      ________________________________________________________________________________________________

      (From the Armbian Forum)


      ________________________________________________________________________________________________

      The post was edited 1 time, last by crashtest: edit ().

    • flmaxey wrote:

      This is another matter altogether and there are a number of factors involved that run from the size of the files involved to the native cache size of a consumer SATA drive, which is probably what you're using. (The latter, drive cache size, creates a "faster than real life" sales gimmick to simulate faster but unsustainable drive throughput until the cache / buffer is empty.)
      @flmaxey are you really not able to realize what BS you constantly spread? Why can't you stop this?
    • Because I'm not spreading BS. And you're one to talk about BS?

      BS is telling users that an UPS is not necessary. That, somehow, running without an UPS is a "sign of progress". You have heard of lightening strikes, right? There's any number of AC line mishaps that can result in equipment that is not totally fried. (Dead is easy to deal with.) It's far worse dealing with intermittent issues that can result from blown gates in CMOS circuitry. In the bottom line, particularly where protecting irreplacable data is concerned, telling unsuspecting users that an UPS is not necessary is BS.
      ___________________________________________

      But don't try to make this about me - as the post in the Armbian forum above clearly indicates, this is most definitely about you. In a startlingly lucid moment, you were amazingly honest with the Admin, Igor, on the Armbian forum. You have neither the patience or the temperament to be a moderator - these are your own words.
      And we won't mention your being banned from the R-PI forum either. I'm sure that's because they were, one and all, spreading BS over there. Right? Right... :)

      Do you realize that I could put together a montage of your BS posts where you've interwoven in a hand full of facts in among your various nonsense opinions as if you're some sort of irrefutable authority... The Pope of SBC's? We're talking about dozens of posts, with dozens of users, beginners and experienced alike that, according to you, are either flat out wrong or spreading BS. I mean, really?
      If you're interested in the montage, I could get right on it and post the links to "tkaiser's best" in the off-topic section of the forum. (And these are your words - not mine.)
      ___________________________________________

      Look, I really don't care what you think I'm doing. It's just not relevant. But note that the world at large is not wrong, where you're the only one that's right. That's simply "delusional".

      The post was edited 2 times, last by crashtest ().