Hi folks,

I think I have this down to a permissions problem, but I can't isolate & fix it. Would appreciate any suggestions...


For all user accounts, my desktop system uses a remote-mounted home directory via NFS. Attempts to log in as a user merely cause a bit of screen flickering followed by a return to X's login prompt. A terribly helpful "permission denied" entry exists in the user's .xsession-errors file, with a reference to a commented out line in ~/.fluxbox/startup.

Now if I create a local home directory for the user, the login is successful.

Comparing the remote home to the local home, it appears that fluxbox is unable to create ~/.fluxbox/init, keys, menu, and slitlist when the remote home is mounted.

The default files for init, keys, and menu are all owner, group, and world-readable; the user does not appear to have any problem manipulating files in their home directory from a terminal.

Any ideas? This is driving me crazy!

It still looks like some permission problem; do this test to figure out what's happening:


-- THIS IS ONLY FOR TESTING PURPOSES; THIS METHOD IS INSECURE --

On the server side:
-------------------
1. enable rw,no_root_squash in /etc/exports
2. create a test user
3. chmod -R 1777 the directory to be exported containing the test user's home

And which one is that commented out line in ~/.fluxbox/startup?

With the above set up, I receive the same behavior as reported in my first post.

Out of curiosity, what purpose does setting the sticky bit serve?



I think I may be misinterpreting the log file, and it's actually referring to a line in /usr/X11R6/bin/startfluxbox. The reason why I say this is that when working with the test user account, the message in .xsession-errors refers to a line number which would be well past EOF in ~/.fluxbox/startup.

Anyhow...

The nature of the errors captured by .xsession-errors are identical for either the test user or a legit user, but they refer to different locations in startfluxbox.

For the legit user, it indicates line 27. For the test user, it indicates line 89. Interestingly enough, each line is exec "$startup".

Not much; just a workaround for no_root_squash, disallowing other users to delete files which they don't own (which would happen otherwise on the nfs mounted dir no matter of the permissions - one reason no_root_squash it's insecure).

- Have a look at your /etc/fstab; maybe between the options for the nfs dirs is also "noexec"?

- Do a simple test: once a user homedir is mounted, create a simple shell script to echo something (make it executable) and try to execute it; see what happens.

- I encountered the same problem, but in my case it wasn't about nfs mounted homedirs, but a grsec kernel - the TPE was blocking any execution in the home directories (including ~/.fluxbox/startup).

hth - till soon

It took me a while to get back to this, but the above comment sent me in the right direction.

I am mounting the remote directory via autofs, and had the -user option enabled in the map file without realizing that -user also implies -noexec. D'oh!

Thanks for your help!