OMV user permissions to when accessing data via a program

1. offizieller Beitrag

    Hi,

    My problem has to do with using omv for a program file storage for Autodesk inventor data. I reckon the problem is due to me not knowing how to properly set the user permissions for my omv folders/files.


    Some background:
    I've recently started using omv for file storage (no past experience with linux) and I've gotten everything to mostly run the way I want to. I have all my data stored into the omv server, this includes the so-called standard part library files that Autodesk Inventor uses. This would be for example bolts and nuts, which I don't want to model myself for every assembly I make. The library files itself are .idcl lifes, if this makes any difference.

    In Inventor, these libraries are read-only by design, but the user can create a custom library for modification. I should be able for example copy a bolt into my own custom library, and then create a "library" part bolt with a different material for general use in multiple assemblies. This is required because the Autodesk standard part libraries don't include for example stainless steel bolts. So I copy the same actual parts that are in the standard part libraries, only changing some aspects of the parts for my own custom library.

    The problem I have is I cannot create these custom libraries in Inventor, when the standard library files are in an OMV system. There is no problem if I have my Inventor library files in my PC hard drive. But this doesn't work, when I have them in the omv PC and try to access them from there. It's accessing them in omv hd that causes restricted access (in practice only read access). The error that comes up in inventor is that I only have read rights to the database I'm trying to alter.

    I can edit, move etc. these library files in the omv hd from windows explorer, so the persmissions are apparently set correctly in that regard. It's only when trying to access the files in windows through Inventor, omv is somehow restricting them to read only.


    In OMV:
    users -> Privileges is set to read/write
    shared folders -> my data folder: privileges set to read/write

    shared folders -> ACL for my data folder: set to read/write and "extra options" set to read/write/execute

    SMB/CIFS -> shares -> my data folder -> edit: "read only" disabled, "Honor existing ACLs" set to enable, "Enable permission inheritance" set to enable


    Any help would be greatly appreciated!

    Hi,

    Thanks for the link, it was very informative.

    This is my current configuration of ACL Extra options:


    My current user has root privileges, so the "owner: root - r/w/e" should cover the execute permission as well, but it doesn't seem to help.

    I previously had the ACL User/Group permissions section also set to Read/Write but I removed trying to simplify the permissions. Doesn't seem to matter which way these are set, and according to the link they won't anyway expand the underlying folder permissions, but rather can be used to reduce them.


    Could it be that there's something in Samba permissions, that need to be set the correct way?

    • Offizieller Beitrag

    If you changed the above screen captured permissions, it's necessary to set the Recursive button to ON (green) and Apply, to insure that files and folders in the shared folder have the same permissions.

    ACL's should be off - period. ACL's will not increase access or override permissions in any way.

    The permissions in the screen captures, above, are open. Even an anonymous log on would have write access. The only thing I can think of is, have you put your username + password (the exact username and password you use to log into your windows workstation), in OMV yet? With the permissions you have, that shouldn't matter, but it's something that should be done in any case.


    Zitat von jariylij

    In Inventor, these libraries are read-only by design, but the user can create a custom library for modification. I should be able for example copy a bolt into my own custom library, and then create a "library" part bolt with a different material for general use in multiple assemblies.

    If the program itself (Autodesk) sets what you're calling a library to "read only", by design or accident, there's no way to override that within the program. For example, to test this, open the SMB share and add a notepad file to the share. Test that it's there and will open, then delete it. Adding and deleting is "write access". (But it appears you've already done this.)


    Zitat von jariylij

    I can edit, move etc. these library files in the omv hd from windows explorer, so the persmissions are apparently set correctly in that regard. It's only when trying to access the files in windows through Inventor, omv is somehow restricting them to read only.

    OMV does not restrict access based on a file type or how it's used in program. Linux doesn't work that way. When it comes to files, a user either has access or they don't.

    The only thing I can think is is "DOS attributes" in the SMB share. Edit the SMB share, set Guests allowed, scroll down to the various attributes and set "Inherit Permissions", "Inherit ACLs", "DOS attributes" and "Extended Attributes" to ON (green) and save it. See what happens.

    Ok good, so I was on the right track to disable all the ACL's at this phase to try and narrow down the problem. About the username; by workstation login do you mean the username+password that I use in the Windows login screen? I have made separate username and password in omv user control that I have input into Windows credential manager (and these username+password are different from my windows account password and username). I saw this method in some guide that I was following when setting up my omv for the first time, and it seemed to work so I didn't think about it any further. Could this cause some access problems?

    Zitat von crashtest

    If the program itself (Autodesk) sets what you're calling a library to "read only", by design or accident, there's no way to override that within the program.

    Yup, that's correct, Inventor sets these libraries into uneditable state by default, and this cannot be changed. The correct workflow for "editing" the standard part libraries is copying a portion or all the contents of a library (say, for example standard ISO 4017 bolts) into one that the user creates for oneself, and then edits that library. So in a normal case I'd have several read-only libraries and along with them some r+w libraries that I've made myself (as in Inventor permissions, not omv of course).

    I had some mechanical drawings that I needed to finish yesterday, so to get around my current restriction with omv I copied the library files in win explorer into a local hard drive, and then did my usual workflow as above to create my custom library inside Inventor. I then copied this new library back into omv hard drive, where Inventor looks for it when accessing. This works fine but obviously not ideal to copy everything back and forth and change the program search path for library files every time I need to do some library editing.
    I'll look into the DOS attributes and guest allowed options that you suggested today, and see if they help the situation.

    Zitat von crashtest

    OMV does not restrict access based on a file type or how it's used in program. Linux doesn't work that way. When it comes to files, a user either has access or they don't.

    Thanks for clarifying that. So it shouldn't be a problem with omv sort of seeing "another user" besides me with correct permissions trying to access the files when I'm accessing via Inventor. Not sure if it's possible that Inventor is in some way more sensitive to linux permissions and/or misinterprets some permissions that omv sets to the files. Goes way beyond my understanding of how linux permissions work together with win permissions and programs...

    • Offizieller Beitrag
    Zitat von jariylij

    About the username; by workstation login do you mean the username+password that I use in the Windows login screen?

    Yes. Create a user in OMV that exactly matches the Username+password that you use to log into windows, at your workstation. Since you have Others - Read/Write/Execute, it shouldn't matter. As noted before - Write is Write, but this is one of those odd situations. Don't forget to try the SMB changes previously mentioned.


    Zitat von jariylij

    Not sure if it's possible that Inventor is in some way more sensitive to linux permissions and/or misinterprets some permissions that omv sets to the files. Goes way beyond my understanding of how linux permissions work together with win permissions and programs...

    I can tell you this much; Windows permissions do not map to Linux (posix) permissions, 1 to 1. Windows has soooo many permutations of permissions it's simply ridiculous. (I had to deal with it back in the day.) Still, in any case, Read is Read and Write is Write so with wide open permissions (everyone - write) it shouldn't matter.

    To get a look at the differences, in Windows explorer at your windows wrkstation, right click on a library, select properties, and the security tab. Do the same for the SMB share of the same library on OMV.

    There's the possibility that Autodesk installed it's own system user, (lots of packages do this) where the program is looking for some special oddball permission for it's user.


    Zitat von jariylij

    This works fine but obviously not ideal to copy everything back and forth and change the program search path for library files every time I need to do some library editing.

    But, if Autodesk refuses to cooperate, this could be the beginnings of a work around. If you keep the library on the local wkstation and the library is shared to the network at the workstation, OMV can back it up. rsync can be set to pull changed files (objects) from the workstation that could be, if needed, restored to the wkstation.
    ______________________________________________________________________________

    Also, you might want to consider looking at Autodesk's forum, for a way to remove the library read only restriction. There might be a solution of this on their site (by editing a config file or something). You can't be the first to have run into this problem, in wanting to store libraries on a LAN server.

    The DOS and other attributes settings seemed to make no difference to the operation. I added a new user with my workstation/MS account credentials. It appears to work the same now.


    Although before setting them yesterday, I was copying the library files to the local machine and back, I noticed some read/write permissions sticked after transferring the libraries back to the omv drive. This included only libraries that I have created some years ago. The library I created this week is still read only.


    So apparently moving them to local drive and then back to omv somehow reset the permissions that Inventor sees (on some libraries). Now I can at least partially edit some of the libraries that I've created. I still cannot create new libraries (for this I still need to move files to local machine and create there, then move the files back to omv). But at least the functionality is now much less crippled.

    In the pic below, everything "custom" along with "Lumber" have been created by me. 2 of them now have read/write enabled (the red "not available" ones aren't a problem, they're just old obsolete ones anyway).



    I took a look at the Security tabs for the files. Interestingly, they don't seem to reflect completely the permissions Inventor sets for the user inside the program. The local drive files have generally more permissions, which makes sense in my case. What's interesting is that an editable custom library by me (top ones called Lumber.idcl in the picture below) has less permissions than an Inventor default uneditable library (bottom ones called AI2021_Inventor ISO.idcl) in both omv and local drive. I can only edit my own libraries in Inventor so I'd expect those to have the most permissions.



    So it seems to me that Inventor doesn't just take the underlying OS file permissions but rather uses its own set, which is apparently somehow related to the OS/filesystem permissions.


    Zitat von crashtest

    Also, you might want to consider looking at Autodesk's forum, for a way to remove the library read only restriction. There might be a solution of this on their site (by editing a config file or something). You can't be the first to have run into this problem, in wanting to store libraries on a LAN server.

    I went through Autodesk help forums trying to find solutions to similar problems, and there were some. But they all seem to conclude that it's the network drive permissions that have been the culprit for other users' problems in the forums.


    There was one thread where a user had the exact same problem with Inventor, and he got it to work after copying libraries to local drive and then back (several times). He could create libraries after that, which I still cannot do. He wasn't sure exaclty what was the reason it started working for him after many tries: "So for whatever reason - who knows, it appears I must figure out which of the 100,000 settings for samba share on my NAS fileserver has to set the right way". So that thread wasn't so helpful in the end.

    • Offizieller Beitrag

    I forget to ask earlier, what's the drive format of the external drive? (And) Was the drive wiped and formatted (EXT4) by OMV, in the GUI?

    ___________________________________________________________________


    I looked at your permissions and while they are different (as expected) they are "effectively" the same. As an example, Linux doesn't differentiate between write and modify. Window's "modify" allows a user to change, for example, an existing word processing document. This is a restricted form of write access, but the "modify" permission can't delete or create. As noted before, the granularity of Windows access controls is over the top. In trying to solve the problems poor Win admin's create, Windows designers ginned up access controls that only experienced Win admin's can understand.

    Zitat von jariylij

    I went through Autodesk help forums trying to find solutions to similar problems, and there were some. But they all seem to conclude that it's the network drive permissions that have been the culprit for other users' problems in the forums.

    Come on... :) That doesn't even make sense, especially if the conditions of the failure can't be replicated. The known facts of this matter are simple. As an example; notepad doesn't interact with it's output files, other than to write them to disk. Notepad writes files, can store them on the network, modify them, local or remote, and users can delete them. Notepad doesn't block write access (internally) so files can be created or modified at will, with access that's based on the users account - not what the program (notepad) is doing.

    It's clear that Autodesk is actively blocking users from writing to libraries, within the program, under certain conditions. As a knock-on effect several users are having the same problem and the fault is put on the network drive? Then "why", one might ask, do a multitude of other packages, (the vast majority), not have this problem? How about a check box or a config file change to open up this imposed restriction and let the user decide what they want to do? (This is a major reason why I like open source. A reasonable Dev would make it possible or reveal how to bypass the "feature". But, I digress..)

    I've noticed the term "database" used interchangeably with "library". While it's speculation, I can't help but wonder if Autodesk is running MySQL, MariaDB or some other relational DB as a back end, on the local machine. If that's the case, while it might be internal to the Autodesk program, a DB user is involved even if it's an anonymous logon. That adds another set of complexities, especially where the DB engine is local (wrkstation) and the DB itself is remote (the LAN server). That would explain the odd behavior.

    The drives on the local machine are NTFS, omv drives ext4. When setting up omv I used the GUI to wipe the drives (had some problems here initially but I do believe this is how I did it in the end).

    Haha yes I agree Autodesk is actively setting blocks for users. Not the first time I'm getting annoyed with that program and it's restrictions. But to clear out any possible misinterpretations: the basic workflow Autodesk suggests for people to modify these (uneditable) standart part libraries is:

    1) create your own library

    2) copy from a standard library to your own

    3) modify the newly created files in your own custom library


    If Autodesk allowed one to directly modify the default libraries, it would be simpler. But since this is the suggested workflow, that's how it is I suppose. So my problem with the permissions is that I cannot create a new library alongside these default ones, since for some reason Autodesk Inventor is saying the (network) drive they are stored on is read-only. Works fine with a local drive, so it has to be my omv/samba settings that cause Autodesk to restrict this. I can manually move/delete these library files via win explorer, so the actual permissions should be correctly set (?).

    So in the Autodesk forum threads I found with the same problem, it was usually that the network drive permissions were causing the user to be unable to create own libraries and hence follow this workflow at all.

    • Offizieller Beitrag
    Zitat von jariylij

    The drives on the local machine are NTFS, omv drives ext4. When setting up omv I used the GUI to wipe the drives (had some problems here initially but I do believe this is how I did it in the end).


    That's what I was looking for. Some users format external drives on a Windows machine (NTFS), connect them to OMV and mount them. It will work but, obviously, there may be permissions issues and the potential other problems. Also, wiping, formatting and mounting in the GUI sets up the needed DB entries for managing the drive in OMV's GUI.

    Zitat von jariylij

    So in the Autodesk forum threads I found with the same problem, it was usually that the network drive permissions were causing the user to be unable to create own libraries

    This is another question altogether. Each case would have to be examined. In your case permissions are as wide open as they can possibly be. Even anonymous users can write or delete files.

    Zitat von jariylij

    I can manually move/delete these library files via win explorer, so the actual permissions should be correctly set (?).

    Yes. You have full permissions if you can create (add) or delete files and folders VIA Windows explorer.
    ______________________________________________________________________________

    The limitation seems to be, custom libraries must be on the local hard drive. Further, I'll take it that you have a lot of time tied up in those custom drawn part objects. If you want to back them up to OMV, automatically, that's doable. If something goes wrong on the local workstation, your libraries could be restored by copying them back.

    If you're interested in doing that there's a doc that explains, roughly, how to do it. I can fill in the missing parts.

    Zitat von crashtest

    In your case permissions are as wide open as they can possibly be

    Thanks for clarifying this, as a first-time user it's rather cumbersome to be certain if everything is set correctly when there's multiple locations for permissions (ACL/samba permissions, etc), but I'm sure they'll become clearer as I get used to the whole concept of omv and linux itself.

    One thing that might have been happening is that there were some misalignmend with the permissions that are set in omv and how they are actually output/manifested. One reason for thinking this is that since at one point I created multiple users and groups to try to start with a clean slate regarding permissions, I may have created and deleted several with the same name, since I occasionally got an "user not found" error when pressing apply after changing permissions with certain users. I tried looking at the config file but couldn't find anything weird like doube-entries of the same data or similar.

    In any case, I'm now adhering to your suggestion to create the user with identical credentials to my workstation login and just use that. The problem above seems to have set itself correct now, and the error doesn't pop up anymore. I need to try to clean up the permissions and try again with the tips you suggested above.

    Zitat von crashtest

    If you want to back them up to OMV, automatically, that's doable.

    This would actually be a good option, since it would also remove the network speed bottleneck when using the data within Inventor. Are you thinking rsync or some other way of doing this? I have set up rsync doing weekly backups to an external ext4-drive, so I could probably do the same but just from local workstation to my omv drive. Rsync seems quite simple and easy to use. The only thing is that I have only found it capable to do periodical backups. I'd prefer constant syncing with the files (although not necessary in the end).

    Yesterday I started looking at the possibility of using syncthing for constant syncing (via the route docker+portainer+syncthing&SyncTrayzor). It seems like it can do exactly what I would like, but the setup is definitely more cumbersome for a first-timer than rsync. It's 80% running now but still work-in-progress so we'll see if I can get that operational.

    Zitat von crashtest

    If you're interested in doing that there's a doc that explains, roughly, how to do it

    Can you point me to the right direction regarding this doc?

    • Offizieller Beitrag

    Look as this doc, -> Remote Mount . Remote Mount mounts remote shares as if they are local file systems.

    The idea would be:
    - In OMV, Set up a shared folder and a smb share named (notionally) AutoDeskbck.
    - At the Windows Workstation, create a new user. We'll call it backup-r and give it a password. (-r annotates that this is something to do with a remote share.)

    - At the Workstation, create a network share with the folder that contains your AutoDesk custom user libraries. Give the windows user backup-r at least "read" access to the folder that contains the custom libraries.
    - At OMV, add the remote mount plugin, as the doc outlines it.

    - Set up a remote mount of the Windows share using the user backup-r and password, for access to the share. Name it something ends with -r, like AutoDeckbck-r, to annotate remote to keep things straight. When the remote mount is successful, use it to setup a shared folder named AutoDeckbck-r


    Now you have two shared folders. One is on OMV (local) and the other is the Remote Mount of the Windows Workstation share.
    When you setup Rsync, according to the plugin doc, the "source" will the be the Remote Mounted Windows Workstation Share. The destination will be the local share on OMV.


    Take a look at it and let me know if you have questions.

    I finally got a chance to tinker with my omv configuration and try this suggestion out. It works well and was easy to set up. I think I'll be using this route to keep things backed up from now on, thanks!

    The only problem I have now is that if I mount the backup folder via samba and try to access it at my workstation (this is just to verify that files are actually backed up), it gives me the following error.



    It's probably something small, I'll reconfigure the remote mount share when I have some time and see if that helps.

    Anyway, if I ssh to the remote mount folder, I can see that all the (test) files have been correctly backed up, so I can verify it works.



    Huge thanks crashtest for the support on this issue, I'd still be banging my head against the wall without your help on this. And it didn't hurt to get a crash course on linux permissions at the same time while wrestling with this problem!

    • Offizieller Beitrag

    From the Remote Mount Doc, did you add the permissions change, to Extra Options in Rsycn Job? The reason this is necessary is because you're importing files from a foreign volume. (Since they're new "to OMV" files, the default create mask comes into play.)


    Add this line to the Rsync job, in Extra Options:


    [tt]–chmod=0775 –chown=root:users[/tt]

    Then, at the shared folder, set permissions to look like the following, then hit apply:


    If your workstation logon username+password is added to OMV, as described in the Permissions Doc, you should have write access.

    Yup thanks, now it works. I recreated the whole process to get a better understanding about the whole remote mount+rsync structure. Took me a while to grasp it, but now it works just as supposed to!

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden