This must be a common issue: I’ve set up my parents’ machine running KDE 4.5 and want them to use the Gwenview import function from the Device Manager popup when transferring image files off photo CDs or other inserted media, since it’s the easiest method for them to comprehend.
All the files on their photo discs are r-xr-xr-x by default so they’re unable to rotate or modify the images once copied to their hard disk. I want to set one specific images folder on their system to automatically force any files placed there to be rw-r–r-- (and rw-rw-r-- for another shared images directory elsewhere). It seems that umask won’t work since that can only take permissions away and not add them, and I’d rather avoid getting into messy ACL configuration.
Is there a way to achieve this either generically or some hidden config in Gwenview itself? I use KRename myself for such tasks but this is way too complex for my parents to understand so I need something that works without them having to do anything.
I know the problem, exactly the same with my parents. IIRC (their PC is not on, they’re not at home) I handled it by a cron which runs a script that changes the perms. They don’t have a shared folder though. I also remember having looked for another, more elegant solution, but it’s too long ago.
Create a script which does the ‘chmod 755 path-to-imagefolder && chmod 644 path-to-imagefolder/’ for the imagefolders and 'chmod 775 path-to-shared-imagefolder && chmod 664 path-to-shared-imagefolder/’ for the shared imagefolders. Then use Systemsettings - Taskplanner to create a cronjob which does that every 2, 5 or whatever # of minutes.
Your observation of the masking function of umask is correct.
Why it works as it works is imho:
Permission bits are faked/simulated on non-Linux file systems (like the one used on the CD, but also for VFAT and other MS types) by the software drivers that interface to those file systems. Logicaly the* r* bit is amongst them because you could not even read file on the CD. The* x* bit is added because the file could contain something executable. The w bit is normaly also added at least for the owner, but not on a CD because of the nature of the device.
Copying files (by all sorts of tools) normaly tries to give it the same access bits as the original has. Of course the umask of the process is used to mask bits off when applicable.
The result of this is not what you want for reasons you explained, but they are not illogical from the Unix/Linux point of view. In general many people would not be pleasantly surprised when such a tool would add w bits without asking.
It is possible that someone has a better solution for this problem then I have, but in a similar case I created a cron run (when this is all within the realm of one user, put it in her/his crontab, else root could do this), that contains the appropriate chmod -R statements. And then let cron run this every 5 mins (or when that is not enough to stop all confusion, every minute).
EDIT: I see Knurpht posted something similar , but he is faster!
Your observations are correct. You might be able to force the write permission using Posix ACLs. Otherwise you’ll need an auxiliary script to change the permissions. Perhaps you could ask the author of gwenview for an enhancement request in future.
If you are making your own CD/DVDs you can turn on Rock Ridge mode with -R to genisoimage to capture to the original owner and permissions instead of forcing them to root and read-only. This is what I do when I backup my home directory to a DVD so that the permissions will be correct on a restore. But this won’t help you with CDs from elsewhere.
Thanks for all the swift replies. I’ve never dabbled with scripts before but from reading the suse help files I assume I simply create a file as follows:
I will run this as root but which folder do I put the script in? Will this propogate through all sub-directories?
@ken_yap
I had thought Gwenview’s import facility already had some of these advanced functions but maybe that’s in an upcoming release. In 4.5 it only has a few basic renaming tools. I’ll have a look through the developer Aurelien Gateau’s blog and see if he’s got anything planned. I’m sure it would be a popular feature.
You can put the script e.g. in /root/bin (when you are loged in as root from a terminal* /root* is the home directory of root and it has allready a bin directory). Give it a name of your liking, e.g. sharepics. Do not forget to set the x bit for the owner:
chmod u+x sharepics
There you can do
crontab -e
and add the line (move down with the down arrow, then type* o*)
*/5 * * * * /root/bin/sharepics
(after you typed this, press the Esc key and then type* :wq*)
which will run it every 5 minutes.
Yes the icon idea could work. The reason I was intending to run it as root was because I’d originally set root as the owner of the entire shared folder, but that’s no longer the case. Also, being a multi-user system, I wanted to ensure that another user would be able to edit files copied into that shared folder, but I guess if I put the script in that folder and make it executable by the group ‘users’ I can get around that problem.
When you want more users to edit the same files, both users should be in the same group and the file should be group writable.
Take care, for chmod a file the rules are a bit different. Ownership and accessbits of the directory are then also important.
In my case where files of several users go into a directory, I decided to chmod from the root crontab. But I admit that this is second choice.
On 2011-01-03 21:06, gumb wrote:
>
> Yes the icon idea could work. The reason I was intending to run it as
> root was because I’d originally set root as the owner of the entire
> shared folder, but that’s no longer the case. Also, being a multi-user
> system, I wanted to ensure that another user would be able to edit files
> copied into that shared folder, but I guess if I put the script in that
> folder and make it executable by the group ‘users’ I can get around that
> problem.
Trick: if group set ID (bit s, SETGID) is set on the directory, files
created there will inherit the group.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
A couple of notes on the script… chmod should probably use the -R to insure recursive mod of the permissions, at least this will simplify path specification. I’d personally use the icon/script to avoid having the overhead of a repetitive cron job. Also, if the files are copied in as with other ownership than the user, you could use setuid on the script to allow it to run as root… I think. I come from an HP-UX background and don’t know the in’s and out’s of Linux well.
The setgid bit semantics for directories were invented in BSD Unix (the original one from Berkeley) and eventually adopted by Unices from the other camp (SysV) because of its usefulness. The other part of the behaviour is that it causes directories created under it to inherit that bit.
Also as hinted earlier you might want to make use of Posix ACLs to force write permission in a subtree. E.g. here’s how to create a directory whose descendants always are group writable:
mkdir dir
setfacl -m d:g::rwx dir
touch dir/file
ls -l dir/file
and you will see that file has group rw permissions as opposed to the usual r if your umask is 0022.
I eventually got all this sorted a few days ago but have been preoccupied ever since because unfortunately the machine I was doing it on has completely conked out
Shortly beforehand, I did post my final edit onto the hopelessly unreliable Spideroak service but it has finally now showed up on there, so this is what I eventually came up with:
I’d made the stupid mistake of placing the script inside the main folder I was trying to change the permissions on (doh!), but the previous advice about using the sticky GID bit is useful, so it now has r-xr-s— permissions. I had to change the script to the above so that it initially removes the unnecessary execute permissions on the photos but keeps the directories accessible recursively. I then made the script a hidden file and created a shortcut to it.
In fact, I tried to be too clever by creating both a lock and unlock script but ran into problems because of the .directory hidden files in every folder created in KDE. I tried endless variations but couldn’t find a way to remove write permission on the photos and keep it on the hidden files only. I read up on all sorts of tedious dotglob info and using the find command with an -exec command after, but finally gave up. The Gwenview developer has taken my point about permissions setting on board so hopefully there might be a simpler way to do all this in future.
On 2011-01-04 23:06, ken yap wrote:
>
> The setgid bit semantics for directories were invented in BSD Unix (the
> original one from Berkeley) and eventually adopted by Unices from the
> other camp (SysV) because of its usefulness. The other part of the
> behaviour is that it causes directories created under it to inherit that
> bit.
>
> Also as hinted earlier you might want to make use of Posix ACLs to
> force write permission in a subtree. E.g. here’s how to create a
> directory whose descendants always are group writable:
This is very interesting!
Do you know of an easy documentation on this? (ACLs)
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
This gives the user support full access to all files under /home. The first command changes the access ACLs on all existing files/directories whilst the second sets up default ACLs on all directories so any new directories created will have the desired ACLs.
Access vs Default ACLs
Access ACLs are any that don’t begin with ‘default:’. They are the ACLs that are actually used in calculating if a user can access a file/directory.
Default ACLs are those that begin with ‘default:’ and can only be applied to directories. When a new sub-directory is created under a directory with a default ACL the default ACL is copied on to that directory both as a default (for any sub-directories created under that directory) and as an access ACL. Just having a default ACL set on a directory does nothing - it only has functionality during the process of creating a new sub-directory. Therefore if applying default ACLs to an existing directory structure you’ll likely want to also apply a matching set of access ACLs, as in Example1 above.
Also, not putting the solutions suggested here down but I would’ve thought the best solution is something that the OP’s parents can do themselves. Rather than a (to them) mysterious and hidden script that runs in the background.
I can think of 2 nice GUI solutions to this:
Use a proper photo management program, eg. digikam, to import the photos from the CD - has the advantage it will arrange them into albums for them too
Show the parents how to right-click on a folder, select properties and change the permissions (both the KDE and GNOME file managers have this capability)
I disagree. Ideally, yes I wish all computer users could understand a few such concepts, but eleven years’ experience with my parents using both Windows and Linux systems suggests this is never going to happen.
To them with their lesser knowledge of computers, it’s not a script, nor is it mysterious or hidden, it’s just an icon they click on to allow them to edit their photos.
It was Digikam’s rather over-complex and unintuitive dialogs for transferring photos off a camera/card that caused me to initially try and teach them how to simply use Dolphin and perform basic file management routines from there, but after more than a year of trying to drum this in it’s rather too much for them and introduces too much potential for problems to occur. I do use Digikam myself and whilst it’s a great program loaded with features, there’s a mind-boggling number to deal with (icons along the top, icons down the left side, icons down the right side, directories on the left, info and options on the right, limitless menu options, etc.). On the other hand, they feel perfectly comfortable with Gwenview’s interface and it provides all the basic functions they need, so being able to handle everything from that one program is preferable.
I think the natural flow of most average computer users’ thoughts upon wanting to copy, view and rotate an image on a photo CD is ‘put the CD in, copy the desired photo(s) to the computer, view the photo and rotate it’, and I don’t see room in there for ‘check recursive permissions settings on relevant folder(s) for owner, group and others’. It’s just not something an average user like my parents ought to know about, unless it would have other uses for things they do on their PC. They don’t use Linux because they want to know more about how their system works, they just use it because it’s what I’ve given them.
thanks for reminding.
