Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: crusader on August 07, 2007, 02:28:39 PM
-
Every time someone accesses data on a specific file ibay directories over windows client and changes some things within a certain file, the permission or the owner changes from root:share to the user which changed something. Which leaves other users unable to open the file again or change anything there. Is there some way to force a specific user or group in this case root:share for every file change in this ibay? I've set this ibay to group everyone and read, write for group. As far as I know there is no specific option to give every user permission to read and write so there must be some way to force the correct group permission to stay and be written while creating a new file object.
I'm using my SME 7.2 System as a Windows Domain Controller.
-
crusader
the permission or the owner changes from root:share to the user which changed something.
I've set this ibay to group everyone and read, write for group.
Add your Users to the Group that owns the ibay.
ownership of
root:shared
is wrong, it should be
user:group
or
user:shared
-
crusader
[Add your Users to the Group that owns the ibay.
ownership of
root:shared
is wrong, it should be
user:group
or
user:shared
The users are all already in group shared, and the ibay itself comes with the root:shared configuration if this is wrong why is it configured automatically by the server-manager?
-
crusader
the ibay itself comes with the root:shared configuration
You said in your first post that the file gets changed and has root:shared permissions, are you referring to the ibay or to the file in the ibay ?
My ibays names have root:root ownership
the /files and /html folders have root:groupname ownership
the files in the /files and /html folders have user:groupname ownership
If your files have root:something ownership then you have probably (incorrectly) copied those files onto your server when logged in as root, and therefore given them root user ownership.
All files should usually have user:group ownership, so that the user who created them can access them and the users who are members of the group can access them in the ibays they are allowed to access.
-
Ok, let's try again, I hope I can explain it more clearly to you this time:
I have created an ibay which permission is:
bayname: <bayname>
description: <description>
group: everyone
user access via file shareing or ftp: write group, Read everyone (tried write group, read group too)
public access via web or anonymous ftp: no
dynamic content enable: no
my ibay has following permissions and ownerships on shell level:
ibay itself: root:root, permission 755
cgi-bin, files, html: root:shared, permission drwxrwsr-x
within the files folder: root:shared, permission 770
every time someone changes a file within this ibay, for example over samba connection (windows network file level), it changes the owner to <username>:<usernamegroup>
I've even tried now to add the users to the shared group within the /etc/group file but no change at all
How can I solve this problem.
-
crusader
I set up an ibay exactly as you describe and when I copy files from my workstation to the mapped ibay /files folder they are given ownership/permissions of
user:shared 764
Try this to reset all defaults (assuming you have not added any custom templates to tweak ibay settings)
signal-event post-upgrade
reboot
-
This didn't changed anything.
I have the same problem as before. I the shared group a real group? In my /etc/groups shard has no member.
There has to be some way I can solve this problem. I don't think I'm the only one haveing this issue. In window this is a standard procedure, and I thought sme does try to implement most of the funktion a standard domain controller provides.
-
crusader
First of all the behaviour you are seeing is not generally correct, I have demonstrated that to you by creating the same scenario you quoted and my files are given ownership of user:shared, rather than user:group
every time someone changes a file within this ibay, for example over samba connection (windows network file level), it changes the owner to <username>:<usernamegroup>
What is usernamegroup ???
The only possibilities (in this scenario) are shared or group (the name of a valid group that owns the ibay).
The users are all already in group shared
Earlier you said this. How do you know that, what shared group are you referring to, did you somehow forcibly create a shared group ?
There should be no group called shared in the Groups panel of server manager as it is a reserved system account.
Is the shared group a real group? In my /etc/groups shard has no member.
shared is a special system group that all users are automatically members of and you should not be modifying it at all.
It should be in /etc/group
and in /home/e-smith/db/accounts
Type these at the command prompt and tell us what the output is
grep shared /etc/group
db accounts show shared
Are you having this problem with only one particular ibay, if so what is the real name of the ibay, what is the group owner real name, and what is the read/write settings. ?
Please tell us (honestly) what changes you have made to this server.
Have you edited config files directly, if so what did you do ?
-
grep shared /etc/group
shared:x:500:www, admin, public, backup.admin, phprojekt, htunc, gblaha, ehallermayer, jschiefer, mcengiz, mnishida, tobermaier, skavuncu, fcloos, wmaier, cwolf, nthanner, mpangaro, personal, info, ja, it, tr, de, en, cobrasoft, compshare, cts, datenbanken, information, japan, kunden, lieferanten, organisation, produkte, share, software, turkey, vertrieb, vorstandcomp, bewerber, dev-projekt
db accounts show shared
shared=system
Visible=internal
No this problem does not concern only one user, it's definitly a problem of all users which I had in the old sme contribsserver version before.
Real name of the ibay's concerned are:
cobrasoft
datenbanken
kunden
vertrieb
...
group owners name? I don't know as far as I know the group owner is the same as the groups name, but I may be wrong. It is all standard sme setting as generated while creating groups and ibays
I definitly did not make any changes in the servers config or template files. It's all as it was after installing.
-
crusader
Those settings look OK.
it's definitly a problem of all users which I had in the old sme contribsserver version before. It's all as it was after installing.
What is the history of this server ?
Is it a fresh install of sme7.0 or 7.1 or 7.2 ?
Was it upgraded from sme6.x ?
Did you do a backup & restore from an earlier version or did you dod fresh install & manually enter all users and settings etc ?
-
I have tried your exact scenario on 7.2 and this is what my server does:
Save file from Paul's desktop to ibay:
paul/shared
Edit file from Steven's desktop and save:
steven/shared
What kind of files are you having problems with, MS Office documents by any chance?
-
MS Office dokuments and Cobrasoft database files. For some reasons the database files like System.ldb or Benutzer.db changes permission and owner to <username>:<username> when the user is changeing some data within the crm tool like adding some new contact data.
-
crusader
Those settings look OK.
What is the history of this server ?
Is it a fresh install of sme7.0 or 7.1 or 7.2 ?
Was it upgraded from sme6.x ?
Did you do a backup & restore from an earlier version or did you dod fresh install & manually enter all users and settings etc ?
I newly installed the 7.2 system. Created every ibay and user again, after that I copied with scp command the files from the old server and changed the owner to root:shared like the file they were in there before.
-
MS Office dokuments and Cobrasoft database files. For some reasons the database files like System.ldb or Benutzer.db changes permission and owner to <username>:<username> when the user is changeing some data within the crm tool like adding some new contact data.
Office documents :-(
Do you have oplocks enabled or disabled?
Show output of:
config show smb
-
oplocks are enabled
-
I've searched for oplocks now but how could it be that this option could influence the user changing behaviour of the samba system, especially the fact that only <user>:<usergroup> would be changed and not only <user>:shared ?
-
I've searched for oplocks now but how could it be that this option could influence the user changing behaviour of the samba system, especially the fact that only <user>:<usergroup> would be changed and not only <user>:shared ?
OpLocks caches the file to the client's local machine and when the client is done, it writes the file back. If another user requests the same file at the same time then the client is forced to write the file backe before it is finished. OpLocks is quite complex and if it doesn't work properly with the types of files you are accessing then it wouldn't surprise me if the client wrote the file back with the wrong user/group/permissions.
Did you try to disable it? Samba says you should if you are sharing database type files (which you have stated that you do)
A quote from here: http://samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html
Unless your system supports kernel oplocks, you should disable oplocks if you are accessing the same files from both UNIX/Linux and SMB clients. Regardless, oplocks should always be disabled if you are sharing a database file (e.g., Microsoft Access) between multiple clients, because any break the first client receives will affect synchronization of the entire file (not just the single record), which will result in a noticeable performance impairment and, more likely, problems accessing the database in the first place. Notably, Microsoft Outlook's personal folders (*.pst) react quite badly to oplocks. If in doubt, disable oplocks and tune your system from that point.
OpLocks doesn't always work correctly. I suggest that you disable oplocks and test again. It won't hurt anything to disable it as OpLocks is intended to enhance performance.config setprop smb OpLocks disabled
expand-template /etc/samba/smb.conf
/etc/rc7.d/S91smb restart
-
crusader
Just out of interest did you disable oplocks and did that resolve the ownership issues you were having ?
-
wow, i have this same problem, i think. clean install 7.3. created users and group w/ users as member. crewated ibay for the group write, readable by everyone.
i mount the ibay in fstab from ubuntu wit dir&file_mode=0775 but anything copied or created is done so as 755, producing errors in apps like f-spot.
any ideas why this could be? why can't i create files/folders with perms 775 when mounted as such?
many thanks,
--matt
ps... line from fstab (and if umounted and mounted from ui, same result)
//smeserver/media /mnt/media cifs uid=smematt,gid=smemattsharegroup,user,iocharset=utf8,user=smematt,password=thepassword,file_mode=0775,dir_mode=0775 0 0
-
...after a little more pondering, just wanted to add that I saw this mentioned, though not resolved, on nabble. same behavior -- f-spot, go to import photos with target on a cifs mounted volume on sme (that is, ubuntu desktop running f-spot with photos to be stored on sme ibay mounted with cifs).
The error on any attempt at import is "import error.... access to the path... is denied." seems that f-spot is creating directories /year/month/day/photo.jpg, but the directories aren't created fast enough?
just tried by adding dirsync into the mount line in fstab, same error. any ideas?
Thanks!
--matt